[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: |
|
||||||||||||||||
| 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: | |||||||||||||||||
| Description |
|
While importing images in bulk, I find that about 20% of the (jpg) images are giving problems. 1 I uploaded the attached image to 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. 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: 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 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 |