[MGNLIMG-248] Wrong PNG image quality calculation Created: 25/Aug/22 Updated: 25/Oct/22 Resolved: 25/Oct/22 |
|
| Status: | Closed |
| Project: | Imaging |
| Component/s: | image operations |
| Affects Version/s: | 3.5.3 |
| Fix Version/s: | 3.5.5, 4.0.0 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Viet Nguyen | Assignee: | Marek Strucka |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | 0.25d | Time Spent: | 0.25d |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Issue Links: |
|
|||||||||||||||||||||||||||||||||||
| Sub-Tasks: |
|
|||||||||||||||||||||||||||||||||||
| Template: | ||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
|||||||||||||||||||||||||||||||||||
| Task DoD: |
[X]*
Doc/release notes changes? Comment present?
[X]*
Downstream builds green?
[X]*
Solution information and context easily available?
[X]*
Tests
[X]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
|||||||||||||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
|||||||||||||||||||||||||||||||||||
| Documentation update required: |
Yes
|
|||||||||||||||||||||||||||||||||||
| Date of First Response: | ||||||||||||||||||||||||||||||||||||
| Epic Link: | Support | |||||||||||||||||||||||||||||||||||
| Sprint: | DevX 21, DevX 22 | |||||||||||||||||||||||||||||||||||
| Story Points: | 2 | |||||||||||||||||||||||||||||||||||
| Team: | ||||||||||||||||||||||||||||||||||||
| Description |
Steps to reproduce
.. Logs, screenshots, gifs... Expected results
.. Justify non-trivial expectations with a link to a doc or a relevant discussion. Actual results
Workaround
Development notes
The calculation shown that just in very narrow range PNG image quality could be in used. |
| Comments |
| Comment by Marek Strucka [ 26/Sep/22 ] |
|
Discovery: The code in the master branch was taken incomplete from snippet and is missing the flag on the first line saying, that the algorithm only works when the image is of TYPE_INT_ARGB, otherwise it throws an exception. Therefore, when trying with different png images, we got images that increase in size as a result (images being TYPE_INT_ARGB_PRE and TYPE_INT_RGB [this one showed decrease in size at highest compression]). When different compression library https://github.com/depsypher/pngtastic was used, the same results were observed. The code with the flag as well as the pngtastic code is to be seen on branch. We would need to restrict the input from user to either only PNGs of the mentioned type (seems difficult to manage as frontend input validation) or we have to state, that the compression for PNGs works only for the mentioned case as of now.
|
| Comment by Christopher Zimmermann [ 26/Sep/22 ] |
|
THanks for the analysis mstrucka. I think the best approach is to update the Imaging documentation to indicate that PNGs are only compressed if they are type TYPE_INT_ARGB. I don't think the frontend needs to be changed at all. I don't see a good approach on the frontend that would be worth the complexity and confusion it would likely cause to authors. (cc: jsimak ) |
| Comment by Christopher Zimmermann [ 26/Sep/22 ] |
|
And in the code - add that check in for that format. |
| Comment by Marek Strucka [ 30/Sep/22 ] |
if(bi.getType() != BufferedImage.TYPE_INT_ARGB) throw new PngjException("This method expects BufferedImage.TYPE_INT_ARGB" ); this is the missing if check on line 105 |
| Comment by Jaroslav Simak [ 19/Oct/22 ] |
|
Reopened: We will map the quality settings 0-100 to 9-0 (highest quality). |