I’m not sure how @hanatos is running it, but I had experimented with this a while ago. I was able to get the full vkdt GUI app to run under termux, and was also able to get the vkdt lib to run within a native Android app so it would run the graph and pass the output image back to the Android app for display. None of this is up to date / documented / ready to use though.
i was just running a termux compile to get performance numbers. a native android version would be awesome (need to patch in some glfw replacement from the vulkan examples and dumb down the ui some).
i implement everything i need to do what i want with my images. the feature set is somewhat different to dt. vkdt has a bit of animation/keyframing/video processing stuff that darktable can’t do. on the other hand i’m not geotagging my images, for instance.
oh yes. everything is. i suppose for code that’s a feature (only deleted code is good code). i care only a bit about ui (in terms of consistency, accuracy of controls, unobtrusiveness), not at all about ux (in terms of feelings of unskilled first-time users), but i do care about workflow: being able to efficiently realise a user story. having been a suckless user for the better part of the last 15 years i suppose i’m kinda disconnected from what all of you are even talking about when they say ui/ux.
certainly true. i started this as an experimental pixel processing pipeline, replacing the grown pipeline we have in dt, that nowadays has more features than the design supports. but then i didn’t want to put back all the bloat/oldschool ui libraries either. as mentioned above, you can compile vkdt as libvkdt.so + modules and go crazy. if some of you purists want to rewrite the cpu-side graph logic in rust i suppose i wouldn’t be completely opposed to that. just a warning, this might be way more work than you would think. even though all the algorithms are in gpu/shader code and vkdt doesn’t really do anything that’s not strictly necessary, the github stats say it’s only 5.5% glsl, the rest cpu code.
If we have questions about hacking around with vkdt where would be the best place to ask?
I guess we could move the whole "let’s build another UI for vkdt discussion there too
there is a vkdt category on this website. that’s probably a better place than github issues for open ended questions and random code snippets.
Thanks, wasn’t really sure of that was the right place or the image processing library thread above (since it was talking about using vkdt as a library in some other program)
Yeah, I was talking to Jo about library-izing vkdt in order to work on a Qt UI. Got the library part in place, but I hard-stopped at Qt, ran out of the bandwidth to figure out how to put vkdt’s display into Qt-Vulkan classes.
Still would be interested in participating in such an endeavor, but it would have to be interspersed with a motley collection of other responsibilities and interests…
Just thinking out loud: unsure if this thread is entirely about RapidRaw. Split(s) in order?
Attempting to open a cr2 file on a Canon 50D fails with the following message:
wgpu error: Validation Error
full text of the message below:
Set ORT_DYLIB_PATH to: /usr/lib/RapidRAW/resources/libonnxruntime.so
AI tagging is disabled. Skipping indexing.
MESA-INTEL: warning: Haswell Vulkan support is incomplete
INFO: Demosaicing check for 'Canon EOS 50D': CFA name='GBRG', width=2, height=2, is_rgb=true
INFO: RGB Bayer-like pattern detected. Applying Bayer demosaicing.
INFO: Demosaicing check for 'Canon EOS 50D': CFA name='GBRG', width=2, height=2, is_rgb=true
INFO: RGB Bayer-like pattern detected. Applying Bayer demosaicing.
INFO: Demosaicing check for 'Canon EOS 50D': CFA name='GBRG', width=2, height=2, is_rgb=true
INFO: RGB Bayer-like pattern detected. Applying Bayer demosaicing.
DEBUG: Applying calibration with wb: [2.0787475, 1.0, 1.4867172, 1.0], xyz2cam: [[0.492, 0.0616, -0.0593], [-0.6494, 1.3965, 0.2784], [-0.1774, 0.3178, 0.7004], [0.0, 0.0, 0.0]]
DEBUG: Applying calibration with wb: [2.0478516, 1.0, 1.4716797, 1.0], xyz2cam: [[0.492, 0.0616, -0.0593], [-0.6494, 1.3965, 0.2784], [-0.1774, 0.3178, 0.7004], [0.0, 0.0, 0.0]]
DEBUG: crop: Rect{2:1, 1188x792, LTRB=[2, 1, 1190, 793]}, intermediate dim: Dim2 { w: 1192, h: 794 }, rawimage: Dim2 { w: 4832, h: 3228 }
DEBUG: Applying calibration with wb: [2.0439453, 1.0, 1.46875, 1.0], xyz2cam: [[0.492, 0.0616, -0.0593], [-0.6494, 1.3965, 0.2784], [-0.1774, 0.3178, 0.7004], [0.0, 0.0, 0.0]]
DEBUG: crop: Rect{2:1, 1188x792, LTRB=[2, 1, 1190, 793]}, intermediate dim: Dim2 { w: 1192, h: 794 }, rawimage: Dim2 { w: 4832, h: 3228 }
DEBUG: crop: Rect{2:1, 1188x792, LTRB=[2, 1, 1190, 793]}, intermediate dim: Dim2 { w: 1192, h: 794 }, rawimage: Dim2 { w: 4832, h: 3228 }
thread '<unnamed>' panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-0.19.4/src/backend/wgpu_core.rs:3006:5:
wgpu error: Validation Error
Doing some quick searches online, it seems to be driver related (and also that Intel Haswell only appears to implement Vulkan 1.0 if even that) I can’t figure out which version of Vulkan is being used here, perhaps @CyberTimon would know? If it is hardware related, and no workaround exists in wgpu to use older hardware features, then I’d say you’re out of luck unfortunately.
Looks like he put in a panorama stitcher…i’m impressed with the speed of his updates…
Anybody asked yet about Sigma X3F raw files?