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

Reconsidering handing of black level #39

Open
Alex-Vasile opened this issue Oct 16, 2023 · 1 comment
Open

Reconsidering handing of black level #39

Alex-Vasile opened this issue Oct 16, 2023 · 1 comment

Comments

@Alex-Vasile
Copy link
Collaborator

Alex-Vasile commented Oct 16, 2023

Currently handling of black levels for the image requires the black level be carrying around and passed to multiple functions, far downstream of the dng to texture conversion.

Option 1: have image_url_to_texture return a float32 texture with the black level already subtracted.

  • Pro: simplified pipeline, less textures, no need for extra conversion, much simpler handling of position-dependent black levels (e.g. row/column dependent)
  • Con: Certain functions will need to be re-worked since they work on the pixel intensities with the black level included. The increased memory usage of returning float32 textures can be offset by creating them much closer to when they're needed, and doing so one at a time.

The adobe DNG sdk (and likely the open source one) has functionality for querying black level for individual sub-pixels, making that portion of the implementation easier.

Option 2: carry around more information about black level

  • Pro: easier to modify into existing code
  • Con: Will increase downstream code complexity, will likely increase memory usage (especially for spatially varying black level), and will increase computation time.

Original public discussion started in #38 (comment)

@Alex-Vasile
Copy link
Collaborator Author

Further consideration, I am not sure the black level is currently being handled correctly. prepare_texture, and the code it was based on, ensures that values are above zero after the black level has been re-added:

// correct exposure
pixel_value = (pixel_value - black_level)*corr_factor + black_level;
pixel_value = max(pixel_value, 0.0f);

While this does prevent negative values in the texture returned by this function, it does not set all pixels below the black level to 0.

I was under the impression that pixels with intensities below the black level should be zeroed out. I.e. the above two lines should be replaced by:

pixel_value = max(0.0f, pixel_value - black_level)*corr_factor + black_level;

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

1 participant