vkdt dev diary, pt2

Software vkdt
74

nice, good to hear!

right. thanks for jumping in here. i updated the documentation with a paragraph about this now.

3 Likes
75

btw recent changelog:

  • added skin retouch wavelet module + preset (retouch.pst)
  • load presets from local directory .config/vkdt/presets as well as the shipped ones when pressing ctrl-p in darkroom mode
  • clamp the hell out of dt ucs to avoid artifacts
  • document that mkssf works with dcp profiles directly (not just dng images)
  • duplicate image in lighttable mode via shift-d
  • darkroom history (toggle with ctrl-h)
  • files view (mount/umount/copy from usb in background jobs)
  • ability to store IDT colour matrix in params (to make history robust to rawspeed changes and to allow custom presets for esoteric input colour spaces)
  • random fixes (preset creation, maker model, default params in draw, broken graphs don’t crash, validation layer stuff, fix dark tones in zone module)

and future plans include

  • automatic a/b view creation by merging graphs of certain points in processing history for better comparison
  • port job scheduler widget from usb copy to export and maybe copy/paste history and the likes
  • abstract the presets selection dialog and use it for tagging and blocks selection
  • i have some fixes for increased saturation in the colour module in the pipeline
4 Likes
76

This was the command I used to get a simple working display profile:
colprof -v -qm -ag -nc fujitsu
(quality=medium, gamma+matrix)
The profiles I had earlier, that did not work with vkdt were made with:
colprof -v -qh -as -nc fujitsu
(quality=high, shaper+matrix)

77

oh, i hadn’t thought about that. thanks for the pointer. yeah i don’t support general/sampled shaper curves at this point, just gamma.

78

Impressive list…

79

changelog:

i think i should make a release soon. there’s always still stuff i think should go into such a release, but at this point i’m thinking some minimal features and a lot of testing would be needed.

5 Likes
80

With a 9 page tutorial now also in the June edition (issue 259) of Linux Magazine (English), I guess the pressure is building up … :slight_smile:

81

apparently already outdated :slightly_frowning_face:

82

As I believe that the Linux Magazine article is a translation of a German article published in Linux User already in February/March, combined with the speed of project development, you’re right in some ways. Descriptions of the overall concept and some of the base structure and basic operations may still have value for a reader who don’t follow the development very closely, though – at least it had for me. :slight_smile:

Good anyhow to see that such an exciting projects get this kind of attention already at a fairly early stage.

1 Like
83

“Just” a Flatpak or an AppImage would be awesome. I’m not having a lot of success installing from the opensuse build system (Arch builds on Manjaro). At this point I can’t even find a single video demonstration of vkdt on YouTube. Shrouded in secrecy, for sure. :slight_smile: So eager to try it out.

BTW, does vkdt have masks for modules yet?

84

you can draw masks, but I think it’s still complicated to use

1 Like
85

If someone want to try it, I packaged vkdt for Fedora in my copr repository.
Not everything is perfect, but it installs and run :slight_smile:

https://copr.fedorainfracloud.org/coprs/oleastre/misc/package/vkdt/

Probably better to download one of the build instead of enabling the copr repository itself, becaus I also have development builds of darktable and other projects there.

And I could try to create a flatpak package, I never created one, but that can be a challenge I’d like to achieve.

1 Like
86

Would be awesome if you tried. :slightly_smiling_face:

87

in theory, would it be possible to compile vkdt for Android?

88

It looks like at least Vulkan an ImGui are available for Android:

https://developer.android.com/ndk/guides/graphics

1 Like
89

right. vulkan is probably the one single dependency (imgui is really just a small collection of c++ files that come with my source code as a submodule). there is very little sse code (and i don’t think it’s vital). not sure if rawspeed is going to build on such devices. probably? i mean you can also always build without rawspeed support (not sure if useful).

the question is probably why would you want it on android. isn’t that just run on weak devices with limited periphery and mostly with other people/big companies as your root user?

90

hah. i’d be interested to see the result too. i did very little reading on flatpak and got stuck with random rants on the internet how bloated the concept is, storing gigabytes and gigabytes of redundant libraries in a flatpak again, just because of lack of coordination with the system packages.

now vkdt does not depend on a lot of stuff in the first place, so it’s possible that flatpaks would actually not be crazy big either. as a point of reference: the make release tarball is 1.9MB big (sources). i suppose the question is whether or not to include the vulkan sdk because it’s likely tied to the system graphics driver quite a bit.

91

would you have some more information on what exactly you did and how it failed there? seems much more likely to me that you’d have a general driver/vulkan issue that would not magically go away by using another package. i mean:

$ ldd vkdt
	linux-vdso.so.1 (0x00007fff1d6a3000)
	libvulkan.so.1 => /lib/x86_64-linux-gnu/libvulkan.so.1 (0x00007f909ed62000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f909ed5c000)
	libglfw.so.3 => /lib/x86_64-linux-gnu/libglfw.so.3 (0x00007f909ecf3000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f909ebaf000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f909e994000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f909e974000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f909e951000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f909e778000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f909ef18000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f909e634000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f909e609000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f909e604000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f909e3fc000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f909e3e5000)
	libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f909e3d8000)

there’s like two real dependencies here (glfw3 + vulkan) if you don’t have the rest you’ll be in trouble anyways.

92

This just came into my mind as I realized that there is no proper/open source RAW developer for Android. I am not saying that everything should work perfectly, just the basic features.

But maybe some other/different software should be created/compiled for that purpose?

I like the hardware, the idea of a comparatively small lightweight device that uses little power.

edit: of course I am thinking for tablets, not phones in this context

93

I already looked a bit, and as I’m already accustomed to build both docker images and fedora packages, flatpak does not look like a big challenge.
Since many libraries are bundled in the flatpak, of course, the resulting image is a bit bigger than a simple rpm for example (the one I built is 3.56MB).
But fortunately Vulkan is part of one of the base runtime; so, on that side it’s easy. I’ll just have to compile a bundled version of rawspeed, imgui and maybe other libraries depending on what we want to include (ffmpeg if we want the movie support for example).
It will just take me a bit of time to make myself familiar with the syntax and ensure everything is building fine.

5 Likes