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

Apple proraw DNG support #44

Open
ilia3101 opened this issue Apr 1, 2023 · 0 comments
Open

Apple proraw DNG support #44

ilia3101 opened this issue Apr 1, 2023 · 0 comments

Comments

@ilia3101
Copy link

ilia3101 commented Apr 1, 2023

Hi I would like to make a pull request for iphone pro raw DNG support (which is 3-component ljpeg, using predictor 7).

I have already implemented the decoding, very simple, but the design is not finalised. I see a few ways to proceed:

  1. Add a separate function like "proraw_decode" to decompressors.rs, just for decoding 3-component predictor 7 data.
    • Bad: It will be 80% identical to decode_ljpeg_3components.
    • Good: Specialising the implementation to proraw will help performance. As proraw is 12 bit, it is possible to do the predictor calculation within u16. But a more general implementation would need to convert to u32 which I guess would be slower (because 16 bit files might exist somewhere??).
  2. Same as first option, but a more general implementation (including u32 conversion).
  3. Write a whole set of general predictor 7 functions equivalent to the existing decode_ljpeg_(1|2|3|4)components
  4. Make predictor be a parameter of decode_ljpeg_(1|2|3|4)components, this will be slower.
  5. Combine decode_ljpeg_(1|2|3|4)components in to one generic function - like fn decode_ljpeg<const N: usize>(...), where component number is a compile time parameter. and then have separate functions for each predictor:
    - fn decode_ljpeg_predictor_1<const N: usize>(...)
    - fn decode_ljpeg_predictor_7<const N: usize>(...)
    This will generate separate code paths for different component counts, so should not lose performance compared to the current duplicate implementations (will need testing of course) all while reducing repetition. This option would require upgrading to rust 2021 for const generics though.

Please let me know what would be best as a pull request!

Also, the data seems to be BGR not RGB, but I guess that can be considered later Nevermind, that was an issue with how I was saving test files. The data is indeed RGB.

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