apparently already outdated
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.
Good anyhow to see that such an exciting projects get this kind of attention already at a fairly early stage.
ā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. 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
If someone want to try it, I packaged vkdt for Fedora in my copr repository.
Not everything is perfect, but it installs and run
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.
Would be awesome if you tried.
in theory, would it be possible to compile vkdt for Android?
It looks like at least Vulkan an ImGui are available for Android:
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.
sounds great. let me try to remember the zoo of less obvious/optional dependencies:
- libjpeg for the
i-jpg
andi-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 externalffmpeg
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
-
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
changelog:
- bugfixes
- use same filtered list for blocks, tags, and presets (allows autocompletion for tags now)
- export in background threads (same as import)
- ui adjustments
- context sensitive help overlay for gamepad input (activate with the āpsā button):
(the bottom one shows the controls for perspective correction)
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.
Ordered a new graphics card, really looking forward to try this!
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).
To me this asks for panorama stitching inside vkdt
But I guess starting to add those niche features at this point is the first step towards unmaintainable bloatware
no need to congratulate for buying stuff
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ā.