Of course I am aware that vkdt works with full resolution images. That becomes apparent when zooming in goes as fluent as in a jpeg viewer. What exactly is the LOD mode? Is it a lower fixed resolution or does it make the pipeline run at screen resolution (with recalculation on zooming in)? The latter would be great for mobile devices I think but would probably come with lots of development and testing work.
Good news from further testing: with the vulkan radeon mesa driver vkdt was usable for my 42MP raws. I’d say maybe 0.2s for the pipeline to run so moving sliders is pretty fluent. I’m also running this laptop with the “power saving” configuration enabled in the BIOS, which costs ~20% performance but makes the fans stay off almost always.
Because you didn’t answer directly: is it possible that a lack of VRAM will cause vkdt to run slower or will it just refuse to do some stuff (for example on this 2GB machine I cant crop my 42MP images, it crashes vkdt)?
One more addition: panning the image using the touchscreen only works in X11 mode, not with wayland.
heya, when building the debug build, make sure you make clean before that. as in regular dt, debug or not will change the size of a few central structs (to attach debug stuff) and lead to crashes in incremental/inconsistent builds.
you direct crash sounds like the GPU that is chosen by vkdt does not have a monitor attached?
this is set here: vkdt/src/gui/render_darkroom.cc at master · hanatos/vkdt · GitHub and influences the output region. lod=1 means it is processed full res (full raw image). lod=2 means it is processed at output resolution (screen pixels). lod>2 means it is scaled even more, e.g. lod=3 is half output res (2x2 blocks in screen display). the scale applies between full res input (raw image) and full res output (screen window size).
oh yeah this sounds good.
yes because i don’t know about the driver and amd in particular. possible that they start some paging in the background that will just be slow? for my part, i just cause a friendly crash 
and don’t do anything about it.
hm okay that might be on glfw’s end. not sure i’m using the event system incorrectly? sounds implausible. more like imgui doesn’t redraw on wayland, that used to be the case in the past. is the new panning position in effect after moving sliders? if so it might just be a mouse-move redraw issue.
Yep, I just checked, I ran make clean and then after which when running the built vkdt I get the error. But when I build with just make I get strangely a vkdt that does work with the same monitor setup (1 display at monitor [0] HDMI-A-1 at 0 0)
even stranger. did you try to run directly through
gdb --args ./vkdt -d all
r
and then maybe use bt to find out where it crashes? sounds implausible that the extensions are sometimes found and sometimes not. maybe the actual error is something after initing the extensions?
RawNeRF is able to combine images taken from many different camera viewpoints to jointly denoise and reconstruct the scene.
Sounds like a mean stack with some hugin alignment to me. 
Did you see the yt video ?
I can see how this could work really good in a cellphone camera. It can take multiple continuous raw captures and then process them for the denoise. Changing the focus was really cool to see.
Yeah… A lot of the computational stuff feels like an effort to make up for having a tiny sensor that uses a high ISO all the time. I don’t need a lot of that with my large sensor camera.
these marketing department posts really trigger me.
i find it a stretch to call NeRF “google’s”. it seems to be the hip thing to do for everybody for years now. also comparing a stack of 200 images to a single raw exposed up is not an acceptable comparison. if at all you’d need to compare to (google’s) image stacking that is already implemented in pixel phones (and in vkdt). that said the raw rendition looks like it mainly profits from denoising the invisible negative values (below black point). averaging many independent samples is like a monte carlo estimator: noise levels reduce with sqrt(N)… means you’ll get diminishing returns for higher sample counts.
i suppose you can just use this code (not from google) and feed it raw images. not sure what the technical contribution of the google project was, didn’t read the paper, i suppose linear data without black point subtracted has some subtleties to consider.
that said the nv code base is a bit heavy on the vendor specific dependencies for my taste, so i think running it separately is probably a better idea.
new changelog:
- bugfixes (gamepad ui, db string lengths, supported image formats, etc)
- rate/label in dr mode too
- new bias parameter in film curve
- ui tweaks in the files view (wrt. import from card reader)
- straighten tool for image rotation
- ship bash script to create pure css html web gallery pages from exported images
Wow, it’s so blazingly fast ! I already knew I’d impressed but on my ageing gear (i5 3470 + gtx 1650) the fluidity is unbelievable compared to DT 
I’ll have to get used to manipulate the pipeline (and the block concept) for the masking process but it’s really giving me the wheel to explore it further more.
On the other hand the interface feels a lot more bare-bone and I didn’t stumbled across any convenient way to activate/deactivate a module other than removing it from the pipeline and re inserting it after, maybe I’ll have to dig a little bit more. I appreciate the many pop-up explanations.
On the technical side I had 0 problem following the git page to build and run it on my gentoo system.
Thanks for this really exciting software, hope you’ll manage to go on working on it or that you’ll manage to welcome contributors ! In the mean time I’m really looking forward to the moments I’ll manage to fit in my tight schedule to get used to using it and I hope I’ll be able to maybe transition from DT (after more than 10y of continuous amateur/hobby use and around 1800 individual edits) sometime in the future.
I think its very much a work-in-progress still in terms of the backend. The UI is barely there, but once the back-end is sound, I’m sure you’ll start to see progress on the GUI.
Yeah, I did not meant it as a criticism but more as a disguised feature request as the very first thing I really felt was missing for me. But It’s already so new and ground-breaking for me that I did not dare to formally ask for anything
feature request noted. the thing is, in a graph where a module can have multiple inputs and outputs it’s not super trivial to have a generic “switch off” button that always works. switching the module off will maybe not generate that secondary output some other branch of the graph depends on. i’ll probably introduce such a button for simple input/output chain modules only (i.e. has a main input channel and exactly one output channel).
Really weird
Starting program: /home/okke/build/vkdt/bin/vkdt -d all
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff7419640 (LWP 2716)]
[New Thread 0x7ffff6c18640 (LWP 2717)]
[New Thread 0x7ffff6417640 (LWP 2718)]
[New Thread 0x7ffff5c16640 (LWP 2719)]
[gui] glfwGetVersionString() : 3.3.8 X11 GLX EGL OSMesa clock_gettime evdev shared
[gui] monitor [0] HDMI-A-1 at 0 0
[gui] vk extension required by GLFW:
[gui] VK_KHR_surface
[gui] VK_KHR_xcb_surface
[qvk] error VK_ERROR_LAYER_NOT_PRESENT executing vkCreateInstance(&inst_create_info, NULL, &qvk.instance)!
[ERR] init vulkan failed
[ERR] failed to init gui/swapchain
[Thread 0x7ffff5c16640 (LWP 2719) exited]
[Thread 0x7ffff6417640 (LWP 2718) exited]
[Thread 0x7ffff7419640 (LWP 2716) exited]
[Thread 0x7ffff77e6740 (LWP 2713) exited]
[Thread 0x7ffff6c18640 (LWP 2717) exited]
[New process 2713]
[Inferior 1 (process 2713) exited with code 01]
(gdb) bt
No stack.
Huhu, no easy way out
I though maybe some “pass through” wires to patch in the pipeline view that would override the processing(s) (modules) in between it’s input and output nodes but still let the module(s) in between function normally, except not delivering their output where the pass through wire is patched ?
I guess with my little experience of vkdt my thinking is not yet fully relevant but still it seemed an elegant solution to me
hmm missing the validation layers? the debug build uses them, the release build doesn’t.
right. leaving the graph connections in place and just calling this bypass connection during create_nodes with the input and output connectors of the module. the node level will then have bypass semantics (without paying for intermediate buffers). probably need to think about it for half an hour how to wire it in the core so it’ll work for all modules which qualify.
Wow, that was fast, thanks !