[MGNLIMG-168] Variation with png images leads to black background instead of transparent background Created: 04/Aug/15 Updated: 15/Apr/16 Resolved: 04/Jan/16 |
|
| Status: | Closed |
| Project: | Imaging |
| Component/s: | image operations |
| Affects Version/s: | 3.2 |
| Fix Version/s: | 3.2.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Jan Schulte | Assignee: | Jaroslav Simak |
| Resolution: | Fixed | Votes: | 2 |
| Labels: | support | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 7.25h | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||
| Sprint: | Kromeriz 20, Kromeriz 25 | ||||||||||||||||||||||||||||
| Story Points: | 5 | ||||||||||||||||||||||||||||
| Description |
|
If a default variation is used via: [#assign imgItemKey = content.image!] [#if imgItemKey?has_content] [#assign myMediumRendition = damfn.getRendition(imgItemKey, "original")!] [#if myMediumRendition??] <img src="${myMediumRendition.getLink()}"/> [/#if] then the following link is generated: Problem occurs in all variations shipped w/ Magnolia not just default one. |
| Comments |
| Comment by Karel de Witte [ 23/Sep/15 ] |
|
info.magnolia.imaging.DefaultImageStreamer#serveImage flattens images that DO support transparency... |
| Comment by Magnolia International [ 23/Sep/15 ] |
|
DefaultImageStreamer#serveImage does the correct thing with regards to transparency. But if you look at the generated binary, despite the extension being .png, it is in fact a JPEG image. |
| Comment by Magnolia International [ 23/Sep/15 ] |
|
IMO the fault lies with info.magnolia.imaging.DefaultImageGenerator, which for some reason hardcodes the output format to be jpg. As a workaround, it is configurable (configured an outputFormat in the generator, see example in attached screenshot), but I'm pretty certain we used to have a mechanism to make the output format dependent on the input (at least with the STK integration). pmundt any idea ? |
| Comment by Nils Breunese [ 18/Nov/15 ] |
|
Indeed, DefaultImageGenerator has this: private static final OutputFormat defaultOutputFormat = new OutputFormat() {{ setFormatName("jpg"); }}; However, STKImageGenerator has code in its getOutputFormat method to set the output format based on the extension of the original asset. |
| Comment by Richard Gange [ 27/Dec/15 ] |
|
I tried this with the latest snapshot using a test image and it still came out black. Am I missing something? I'll attach the image I'm testing with. |
| Comment by Jaroslav Simak [ 28/Dec/15 ] |
|
Can you please also attach export of the asset from DAM app? Thanks. |
| Comment by Richard Gange [ 28/Dec/15 ] |
|
It looks like my generated image is still jpg |
| Comment by Richard Gange [ 28/Dec/15 ] |
|
It's also still happening with our social icons as well.
I have both the latest snapshots of imaging support and imaging module installed. |
| Comment by Jaroslav Simak [ 28/Dec/15 ] |
|
Ok thanks for the info, i'll have a look at it tomorrow. |
| Comment by Richard Gange [ 28/Dec/15 ] |
|
Ok, I see what is happening. The configuration looks like this:
The fix exists in the DefaultImageGenerator but generating the thumbnails and portraits goes through ImageOperationChain so it never uses the new code for determining the output format. |
| Comment by Richard Gange [ 28/Dec/15 ] |
|
Ok if I change the class property on:
So I'm not sure what to do here. Should we make this configuration change or move the overridden code for getOutputFormat to ImageOperationChain since DefaultImageGenerator extends it anyway? |
| Comment by Jan Haderka [ 29/Dec/15 ] |
|
The problem is not related to just default variation but to all variations. |
| Comment by Jaroslav Simak [ 04/Jan/16 ] |
|
I don't agree with moving code to its super class as it would make ImageOperationChain JCR dependent - we should rather create new subclass of ImageOperationChain and implement dynamic outputFormat resolving there. btw. rgange ImageOperationChain expects outputFormat to be configured via node2bean, and if you take a look at /modules/imaging/config/generators/portrait/outputFormat@formatName you'll see that it has jpg configured - that's why you see black background. Change it to png, flush imaging cache and problem should be gone. |
| Comment by Jaroslav Simak [ 04/Jan/16 ] |
|
Created followup ticket MGNLUI-3738 and linked it with this one. I am closing this ticket. |