[MGNLIMG-61] some images have inverted colors when they are resized Created: 11/Dec/09  Updated: 05/Dec/14  Resolved: 15/Mar/10

Status: Closed
Project: Imaging
Component/s: image operations
Affects Version/s: 2.0.2
Fix Version/s: 2.0.3

Type: Bug Priority: Critical
Reporter: Ernst Bunders Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: vpro
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File 34348371.jpg    
Issue Links:
causality
is causing MGNLIMG-142 Replace removed JPEG classes in Java 7 Closed
supersession
is superseded by MGNLIMG-66 Re-implement MGNLIMG-61 without com.s... Closed
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:

 Description   

While importing images in bulk, I find that about 20% of the (jpg) images are giving problems.
If you view them in original size They look ok, but if you filter them through the imaging servlet it goes wrong.

1 I uploaded the attached image to
documents -> /vpro/untitled1

2 I open the dialog on //vpro/untitled1/34348371 The image thumb looks ok: url http://localhost:8080/dms/vpro/untitled1/34348371/34348371.jpg is to the full image, resizing is in page.

3 I request the image through the imaging pipeline, and the colors are inverted: http://localhost:8080/.imaging/stk/pip/content-small/dms/vpro/untitled1/34348371/document/34348371.jpg

This way the bug should be reproducible.



 Comments   
Comment by Magnolia International [ 14/Dec/09 ]

I can indeed reproduce this problem in a test with this sample image; most likely it's due to "something special" with those jpegs. Will try to investigate what that might be.

The "good" news is that this doesn't seem to be due to anything specific to the imaging module (although hopefully we can "fix" in there) - the following code shows the same problem:

        final BufferedImage test = ImageIO.read(new File("test-in.jpg"));
        ImageIO.write(test, "jpeg", new File("test-out.jpg"));
Comment by Magnolia International [ 15/Dec/09 ]

Ernst, would it be OK if we kept this image in our source repository for tests? (copyright issues maybe?)

I'd be interested to know how this image was produced. (seems it's using quantization lookup tables, unlike other test images I have)

Comment by Ernst Bunders [ 16/Dec/09 ]

I guess that's ok. I'm not entirely sure, but I think it is a still from one of our own programs.

Comment by Magnolia International [ 21/Jan/10 ]

Ernst, sorry for the delay. A couple weeks ago, I found out that one could load this type of image transparently via some com.sun... classes. (my laptop crashed in the meantime, so I lost the temporary tests I had about this)

Essentially, what I'll do is hook that into the *Loader classes. Unfortunately, there are rumors that these are less performant (and memory consuming) than the javax.imageio ones.

I haven't been able to figure out a way to load/convert this type of jpeg (huffman) - unless by passing their metadata around, which is not option within the imaging module's api. I'm still hoping to figure that out at some point though, without resorting to private Sun classes. Feel free to drop in suggestions if any.

Comment by Magnolia International [ 22/Jan/10 ]

Ernst,

I just deployed a new snapshot of the imaging module, 2.0.3-SNAPSHOT. It exposes 2 extra ways to load JPEGs. To configure it, add a subnode in the load operation(s) called imageDecoder. In this node, add a class property with either info.magnolia.imaging.operations.load.SunJPEGCodecImageDecoder or info.magnolia.imaging.operations.load.SunJPEGCodecImageDecoderAlt as a value.

Could you give this a shot and let me know how it goes ? If you have particularly large images, or loads of them, it'd be nice to get a little feedback on behaviour/performance, too.

Let me know if you need any assistance in setting this up.

Cheers,

-greg

Comment by Ernst Bunders [ 25/Jan/10 ]

hello Grégory

I will try it out tomorrow. I may need some assistance. I hope I can reach you tomorrow. But we'll se how it goes,

regards,

Ernst

Comment by Ernst Bunders [ 26/Jan/10 ]

Hello Grégory

I looked at both http://svn.magnolia-cms.com/view/enterprise/imaging/tags and http://repo.magnolia-cms.com/enterprise/info/magnolia/magnolia-module-imaging/ but am unable to discover your snapshot release. is there perhaps a snapshot repo that we don't know about.
also:
Your remarks regarding the repository configuration sound cryptic to me. Could you send me an xml export of your configuration? That should get me started quickly.

Thanks,

Ernst

Comment by Magnolia International [ 26/Jan/10 ]

http://repo.magnolia-cms.com/enterprise-snapshots/

As for the configuration - are you using the stk generator, or a custom imaging chain ? What do you have under /modules/imaging/config/generators ?

Comment by Magnolia International [ 26/Jan/10 ]

Oh sure, you're probably using only the stk/etk integration, which is why my comments above appear to make no sense. I'll have to take another approach. Let me get back to you in a couple hours with a new snapshot. Sorry again for the delay.

Comment by Ernst Bunders [ 26/Jan/10 ]

Yes, we are currently just using the stk generator. Nice and easy. Good enough for now.

regards,

Ernst

Comment by Magnolia International [ 26/Jan/10 ]

Ernst,

There's now a new snapshot (2.0.3-20100126.174539-4), with which you should be able to work. You'll need to set a property (in your own module or in a magnolia.properties file) with the following:
info.magnolia.imaging.operations.load.ImageDecoder=info.magnolia.imaging.operations.load.SunJPEGCodecImageDecoderAlt
or info.magnolia.imaging.operations.load.ImageDecoder=info.magnolia.imaging.operations.load.SunJPEGCodecImageDecoder

These are two different implementations that might have different impact on performance or memory usage... depending on load and size of your original images, they might end up behaving differently. I'd recommend starting with info.magnolia.imaging.operations.load.SunJPEGCodecImageDecoderAlt. If most of your images are jpeg, info.magnolia.imaging.operations.load.SunJPEGCodecImageDecoder might be slightly more performant, but will probably use a little more memory too. Since generated images are cached (in the "imaging" repository, before being also cached with the regular page-level cache), I wouldn't worry too much about the minimal performance impact.

If you set the property in a custom module, make sure that this module has a dependency on the standard-templating-kit, extended-templating-kit AND imaging modules, so that it's loaded last, and thus its property can override the defaults set by the previous modules.

In case of doubt, plug your debugger in info.magnolia.imaging.operations.load.AbstractLoader#doReadAndClose to see which decoder is being used.

Looking forward for your feedback,

Comment by Ernst Bunders [ 29/Jan/10 ]

hello Grégory
I'v been a bit tied up this week, some loose ends. I will get to the imaging stuff this afternoon or monday, so I guess that's when you'll hear from me.

regards,

Ernst

Comment by Ernst Bunders [ 01/Feb/10 ]

hello Grégory

I tried your new version of the imaging module, and for as far as i can see it works ok. My impression is that SunJPEGCodecImageDecoderAlt is a lot faster than SunJPEGCodecImageDecoder, as 95% of our images are jpeg's.

I had some trouble to create a build of the site with your snapshot version, because version 2.0.2 kept popping up (the blessings of transative dependencies) and somehow overruling the snapshot version. In the end i just renamed the snapshot jar to 2.0.2 (i shamefully admit).

So I guess it would be nice to have a real release, with dependencies from extended-template-kit updated.

Nice one!

Ernst

Comment by Magnolia International [ 15/Mar/10 ]

See MGNLIMG-66 for further improvements

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