Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

16bit per channel #34

Open
EricGrange opened this issue Jan 4, 2023 · 3 comments
Open

16bit per channel #34

EricGrange opened this issue Jan 4, 2023 · 3 comments

Comments

@EricGrange
Copy link

EricGrange commented Jan 4, 2023

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)

@PetteriAimonen
Copy link
Owner

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.

@EricGrange
Copy link
Author

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

image

while the ideal source image would be

image

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

image

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)

@PetteriAimonen
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants