-
Notifications
You must be signed in to change notification settings - Fork 606
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
feat: add PixelWithColorType for Luma<f32> and LumaA<f32> #1846
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why not. It seems all conversion to make this work already exists and agree with the color type as indicated in the impl.
This adds My specific concern is that every additional variant we add to |
Generally, yes, but I don't think this is one of the cases that adds complexity.
I think inaction here is worse than the additional implementation. In general, real world image formats diverge quite a bit from the neat rga-pixel-matrix thinking that we try to model for the Buffer use. And the difference is only going to get larger with HDR support where (non-destructive) mixing of different color spaces is a hard requirement. We don't cope with that at all. To be frank but slightly hyperbole, if we can't support this case in IO, we may just as well deprecate the entire library now and speed up the process of phasing it out. |
My comment above was perhaps too harsh. Thanks @strasdat for making the PR, the code itself looks good, and now we just have to think through API implications. Right now, this library has major gaps when working with images that don't have a ColorType. I had thought we supported using ExtendedColorType when saving images, and converting between image formats, but apparently that was never implemented. This evening I'll try writing up a proposal I think could make the situation much better |
@fintelia, @HeroicKatora - thanks for insightful discussion and feedback. My current use-case is unblocked by #1847, so no urgency from my end. |
@@ -26,6 +26,10 @@ pub enum ColorType { | |||
/// Pixel is 16-bit RGBA | |||
Rgba16, | |||
|
|||
/// Pixel is 8-bit luminance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
8-bit -> 32-bit. And below as well
This PR merely includes these two types:
Luma<f32>
LumaA<f32>
Motivating use-case:
Single channel floating point images are pretty common, e.g. in computer vision. LumaA is mainly added for symmetry - but there are some more niche use-cases too (e.g. flow field representation).
I license past and future contributions under the dual MIT/Apache-2.0 license,
allowing licensees to choose either at their option.