PetteriAimonen
16bit per channel
How feasible would it be to add 16bits per channel support ? Using from a basic TIFF for instance, and maybe DNG later on.
Several routines are already using floats and would already support it, but I have not delved enough in the code to see if there are major roadblocks, or if it would just require copy-pasta with adjusted types.
(Loading 16bits TIFF is supported, exporting a TIFF is supported as well but it outputs as 8bits per channel)
Should be possible, but takes some work.
For Task_Wavelet, it would be a matter of keeping track of the format to get the correct channel depth when converting back from float. Task_SaveImg might work as-is, or with trivial changes.
Task_Reassign (color reassignment) is the hardest part. It might be easier to have a separate 16-bit version of it, rather than having a bunch of ifs in the code. Alternatively the old version would work directly, but it takes a lot of RAM for large stacks.
Did some investigation, but 16bit is not really worth it with the current algorithm given the noise boosting that happens in shadow areas. For instance in the pcb example, shadow areas look like
while the ideal source image would be
There is even some slight banding from the color reassignment, which can be mitigated by scaling the reassigned color luminance according to the grayscale levels. The image then looks like this
This smoothes away the banding while being quite cheap computationally speaking, so could be worth adding.
The increased noise level is still there, and the halo comes from the low frequency wavelet merge, so it cannot just be filtered out. Using the fully filtered depthmap could work better in theory, in practice, I'm seeing some blur on depth transitions (I did not implement it, I only played with generated and aligned image outputs in Affinity)
I agree - the wavelet approach is quite prone to amplifying noise.
The other large category of algorithms is the "construct depthmap, blend layers accordingly". Compared to this, the wavelet approach has some advantages in handling translucent / thin objects in front of textured backgrounds, but it is unclear what is actually better for the majority of cases and whether they could be combined somehow.