-
-
Notifications
You must be signed in to change notification settings - Fork 852
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
[WIP] Preserving isTrans data #764
Conversation
I'm not sure if we want to implement it this way or have a look at the already existing Palette code which should be extended to always write alpha if the hasAlpha flag is true. But please let me know :) |
Hey @devedse this all looks great! Thanks for making the effort to fix this for us. I'll pull it down for a final review but from looking on GitHub I can't see anything amiss. In the interim could you please sign the CLA? Cheers! 👍 |
I think the bitconversion could use some improvements. But its not really my speciality. |
Signed 😄 |
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.
@JimBobSquarePants @devedse I have a poor understanding of PNG, so I need some explanation to understand everything, and have some ideas for defining proper test coverage:
When a color is defined as transparent, and we decode it to Rgba32
or similar, do we set the alpha to 255 when we encounter that color? (This would make the most sense to me!)
What is then happening in the encoder? Are we converting all colors set to (*,*,*,255)
to the transparent color again?
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.
Looking good with just a couple of changes.
Anton made some valid suggestion regarding using our new gray types and better variable naming. We should also check the bit depth as well as whether the property is not null.
@antonfirsov To answer your questions regarding the tRNS chunk. When decoding either grayscale, 24bit, or 48bit color types, if the chunk is encountered we decode to When encoding we use the Does that make sense? |
Codecov Report
@@ Coverage Diff @@
## master #764 +/- ##
==========================================
+ Coverage 88.51% 88.56% +0.05%
==========================================
Files 1005 1005
Lines 42769 42846 +77
Branches 3149 3159 +10
==========================================
+ Hits 37855 37948 +93
+ Misses 4222 4203 -19
- Partials 692 695 +3
Continue to review full report at Codecov.
|
I've implemented almost all findings, please redo code review :) |
But what happens when we encounter pixels matching the value? Do we decode fully transparent pixels in those cases? |
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.
We should cover all 4 trancparency cases with tests for both decoder and encoder. Not yet sure whether we can base them on current tests or we should invent something new. (I'm still unsure whether I understand decoding/re-encoding of transparent pixels correctly.)
We set the alpha component to 0 leaving the other component data intact.
No the tRNS chunk is simply a marker. Pixels are encoded as normal. Delete the tRNS chunk and you have an opaque image. We have some test images already that might cover your needs but there's an official suite here. |
What do you mean by this? For writing test cases? |
@devedse input images for decoder tests. |
@devedse I've updated the code to check for the correct bit depth and also reduce allocations. Once we add the tests images from the collection I linked this is good to go. |
Tests added and correct behaviour confirmed. I think this is good to go now. |
Code and tests are now up to spec.
[WIP] Preserving isTrans data
Prerequisites
Description
Currently still WIP but I wanted to contribute something to the project 😄. So I'm working on fixing my own issue:
#763