vkdt dev diary, pt2

apparently already outdated :slightly_frowning_face:

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

ā€œ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?

you can draw masks, but I think itā€™s still complicated to use

1 Like

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

Would be awesome if you tried. :slightly_smiling_face:

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

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

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

1 Like

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?

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.

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.

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

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

sounds great. let me try to remember the zoo of less obvious/optional dependencies:

  • libjpeg for the i-jpg and i-jpglst modules
  • libexiv2 (optional) only inside the i-raw module. it is used to load anecdotal information (f-stop etc) to be displayed under the histogram, and can load ColorMatrix2 from dng tag as a fallback if rawspeed doesnā€™t have a matrix (camera id / iso are supplied by rawspeed to access noise profiles and colour lut etc)
  • libavformat/libavcodec (optional) inside the i-vid module, for handling of mov files and the likes (o-ffmpeg instead does something horrible to pass the output to an external ffmpeg binary)
  • libalsa (optional) for sound output
  • openmp is only used for i-mlv raw video and inside rawspeed
  • i-v4l2 (optional module) depends on video 4 linux (platform specific, no library though)
  • libfreetype (optional) for nicer font rendering. pulls in libbrotli here :frowning:
  • udisksctl (the binary) is called from the files view to mount/unmount stuff. platform dependent, but if itā€™s not there mounting/unmounting of usb will just not work (not a hard dependency)
  • glfw3 (optionally) needs custom patches like here for pentablet support.
  • libvorbis libvorbisfile libogg libmad (optional) for sound support in the (optional) i-quake module. quake will also require the blue noise texture from here to run
2 Likes

changelog:

this last feature may be a sign that in fact there are no major features missing nowā€¦ but indeed without it i keep forgetting the bindings, so in a way itā€™s necessary.

6 Likes

Ordered a new graphics card, really looking forward to try this! :slight_smile:
Iā€™ve looked at your align module. Is this actually the first non destructive implementation for multi frame noise reduction or HDR? So I have one thumbnail shown in the lighttable and if I open it in the darkroom it loads multiple Raws, blends them and then applies all processing on the blended result and shows it on the screen?

yes, thatā€™s what it does. also i use it to denoise quake in between frames. not sure itā€™s the first of anything. i suppose google implemented something likely more refined in computationally challenged hardware (telephones).

very nice, congrats. i know at current prices this really hurts. not sure i would buy one for myself (happy user of existing hardware).

1 Like

To me this asks for panorama stitching inside vkdt :smile:
But I guess starting to add those niche features at this point is the first step towards unmaintainable bloatware :smile:

no need to congratulate for buying stuff :wink:

Thankfully gpu prices are almost down to ā€œnormalā€ levels again, at least here in Portugal, I assume the rest of europe as well.

Some good news for ā€œthe year of the vkdt desktopā€. :slightly_smiling_face:

4 Likes