vkdt devel diary

Starting commit a08a8f2970 (gui: introduce combo boxes) I get this error:
[ERR] roi of last module o-bc1 did not get initialised!
(i’ve cleaned up the cache).
Any advice ?

After having removed the *.o files the error has gone,e even with the last commit.
Sorry for the noise. But ‘make’ seems to miss some change, doesn’t it ?

hi, thanks for trying! i may have introduced a change that would have required a make clean (removed the dso/c code in the exposure module).

the next thing you’ll probably run into is that old .cfg files will not work correctly any more, since the colour module now does the task of white balancing/colour matrix application (was exposure before). if you want to re-use old .cfg you’ll probably want to run

sed -i -e 's/exposure:01/colour:01/g' *.cfg

on the .cfg files.

sorry for the inconvenience, until first release i think it’s probably not necessary to be backward compatible though.

2 Likes

today’s update: i implemented a kind of a-trous wavelet denoising, somewhat similar in spirit to the wavelets used in darktable. there are a few key differences:

  • this implementation is fast (takes 1.8ms on a full 16MP image on a 2080 Ti).
  • it can be applied before or after demosaicing

some initial results seem to indicate that the before demosaicing mode isn’t better than the traditional way of applying it after, on a full colour buffer (the way it’s also done in dt). i might be doing things wrong/suboptimally though, so this is hopefully subject to improve.

no denoising (iso3200 +2ev):
denoise_off

strong post demosaic denoising:
denoise_post_strong

lighter post demosaic denoising:
denoise_post

lighter pre-demosaic denoising (same settings as above):
denoise_pre

this last mode shows some weird haloing around the hand, and changes colours around quite heavily. not easy to see here but if you flip the images you do.

i was expecting the pre demosaicing mode to work better, since it is also before black point subtraction. this should make noise in dark regions match the actual colour much better (no bias due to clamping at zero). i could not yet demonstrate this on actual images though.

some technical bits if you’re interested:

  • undecimated a trous wavelets, one level is decimated if you start from bayer/xtrans
  • no anscombe, but some variance normalising wavelet transform (Fisz-like)
  • use same noise model as dt, but profiled on raw data, dt is using profiles post demosaic
  • wavelets are currently not edge-aware, but there is edge-protection code in place instead (you can tell if you look at the strong denoise image near strong edges, probably a bit heavy handed still). edge weights would be easy to incorporate though, and shouldn’t affect speed

this is currently sitting on a branch because i’m not sure yet how to incorporate it into the default processing pipeline. i’d like to have it on by default, run pre-demosaic, and do black point subtraction/black area cropping even if it doesn’t denoise. since the pre-demosaic performance isn’t great yet i’ll probably need to figure out why that is first. oh, also i think regular bayer is still broken, the images above are xtrans.

6 Likes

wow :+1:

what kind of animal is this?

Dog?

cat! had to cut away the head to keep the human next to it anonymous, too.

1 Like

That actually looks like film halation. :smiley:

today’s unscientific comparison:


i think this is a good starting point, though i’m not entirely happy with some details/sharpness/etc.

first image: one of four noisy handheld input images (iso 3200 +5ev). bottom image: result of aligning these four, merging, and using pre-demosaic denoising (see above). these are 16MP xtrans images.

now what i am happy about:
total runtime of the processing graph: 21.0 ms, time to align the 4 shots: 12.6 ms. if you run from scratch (for instance vkdt-cli) there may be a ~10ms overhead per input image for rawspeed to pick up the data from SSD.

also i like how green the trees are. i think denoising this red/purple mess after black point subtraction should result in considerable bias (but did not prepare the comparison, that would be too scientific for today).

2 Likes

Unscientific :stuck_out_tongue: assessment: the edges aren’t as sharp as I would have hoped.

heh, yes, absolutely. maybe i didn’t select the sharpest one to align to, but more likely the way i merge the aligned but mosaiced data is pretty dumb. the google paper at least had some more clever ideas that i didn’t implement yet. anyways, maybe this is the better comparison, merging into the same image as i exported in noisy:

still edges aren’t super crisp, and there is this blue “halation” problem… more work ahead :slight_smile:

1 Like

the trees agains the sky also show some halation.
Still,

60ms, maybe 70ms, for an image with an effective iso of 102400, after stacking and denoising…mindblowing!

Stlightly de-correlated RGB planes ?

hm, i have no idea. i think only the pre-demosaic denoising results in these colour fringes, so it can be a random bug. it’s very easy to get off track in these mosaic patterns i think. in fact it just appeared to me that none of the steps in the demosaicer would require black point subtraction… so i might actually try denoising post demosaic but pre-blackpoint subtraction. i suppose the edge detection inside demosaicing would lose a little contrast, which may be bad… at least for cases where there’s not quite as much noise.

Sounds like uncompressed xtrans files read from a SSD which can deliver at least 2.5 GBytes/second

I finally managed to compile vkdt 2 days ago (thanks to @hanatos) and got a chance to test it. The perf is out of this world even for a mobile workstation, I have never experienced such responsiveness before in my life, especially knowing the algos running under the hood and working freaking 36 Mpx images. Once polished and refined, that should be a true joy to use.

2 Likes

just an idea … recent GPUs/consoles have a new feature where they stream compressed data from a SSD. With the RTX IO on the nvidia card the decompression is happening in the GPU.

So maybe longterm a GPU version of rawspeed?

So now you need to learn how to do the GPU stuff to port filmic and your other toys over?

1 Like

Filmic and toys are doing GPU already, through OpenCL. I just need to learn Vulkan slang. Then I got der Hanatos to template things, so writing pixel code is a piece of cake if I don’t need to handle the pipeline infrastructure. Then, I really want to add brushes and painting-drawing in there, because there is no fast and scene-referred drawing soft around.

1 Like