[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: PNG File Screen_Shot_2015-09-23_at_19_47_25.png     PNG File black-background.png     PNG File connectors-test.png     XML File dam.test.connectors-test..png.xml     PNG File imaging-config.png     XML File imaging.portrait.dam.test.connectors-test..png.xml    
Issue Links:
Cloners
is cloned by MGNLIMG-175 black background for transparent png ... Closed
Relates
causality
relation
is related to MGNLIMG-177 CachingImageStreamer might store inco... Closed
is related to MGNLIMG-223 Use PNG as default output format for ... Open
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:
"/.imaging/default/dam/travel-demo/social-icons/google-plus.png/jcr:content.png"
This link serves a png with black background instead of transparent background.

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:

  • /modules/imaging/config/generators/portrait@class
  • /modules/imaging/config/generators/thumbnail@class
    to info.magnolia.imaging.DefaultImageGenerator then it works ok.

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.
Fix itself is correct, but doesn't belong to DefaultImageGenerator but to super class. DIG is, as it's javadoc explains, supposed to provide just most commonly used configuration for generators.

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.

Generated at Mon Feb 12 02:12:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.