"mixed in" color about scrimage HOT 29 CLOSED

Hi,

Thanks for the bug reporting.

Which version of scrimage are you using? Are you using the version on maven, or did you clone the git?

from scrimage.

Hi,
thanks for the answer.

I'm using 1.4.1 from maven.

from scrimage.

Also, I tryed to use Scalr inseated of ScrImage and problem has disappeared. So, I think this is bug in library.

from scrimage.

FWIW, I get the same thing occasionally, though in my case the images were green. I didn't create an issue because I was never able to reliably reproduce. Next time it happens, I will try and grab as much info as I can and attach to this ticket.

from scrimage.

Do you always write out in the same format - eg do you always write JPEG? I think the bug might be in a reader or writer rather than anything else.

from scrimage.

As for me, I've only ever written JPEG. Never tried anything else.

from scrimage.

me too only JPEG. I will return back SrcImage to my project and will set output format to PNG to test. Will let you know about results.

from scrimage.

I just did the tests with PNG under Jetty. At least one time resulting image was wrong. Images were converted with next code:

val im = scrimage.Image(image.data.is).fit(dim.width.is, dim.height.is)
data(im.write(scrimage.Format.PNG))//saving to database

See attachment.

from scrimage.

I did more tests.

1. I also created png images from all my jpeg test images (total 11 images) and used this png images for uploading. Output format was PNG. I restarted Jetty 7 times (so, it were 77 tries), and also I did test with tomcat, tomcat was restarted 5 times (+55 tries). I have never faced the problem with such configuration during the test.
2. Then I changed output format back to JPEG. Input images were PNG. I did test 5 times for jetty and 5 times for tomcat (110 tries total). I have never faced problem with such configuration during the test.
3. Then I used JPEG images as input again. I faced problem at try number 25.

Results.
PNG output (with PNG input) was ok with 132 tests.
PNG input (with PNG and JPEG output) was ok with 132 + 110 = 242 tests.
JPEG output (with PNG input) was ok with 110 tests.
JPEG input (+JPEG output) has been broken at about 25th test.

So, looks like problem is in JPEG reader.

Hope, that helps.

from scrimage.

Thanks for your tests. We'll narrow the search to the JPEG reader.

from scrimage.

It seems I faced with the same problem. Fit operation on image in PNG format distorts colors. The error is reproducible. Here is the code:

Image(bytes).fit(64, 64).writer(PNG).withCompression(9).write(out)

Original image:

Produced image:

I hope this helps. Sad to say, but such an issue devalues all other advantages of this great library like performance. It was a first image I tested against. Used versions: 1.4.1 and 1.4.2

from scrimage.

I think its the JPEG reader. Are you reading these images from Jpegs?

On 1 September 2014 10:05, Andrey Zhuchkov [email protected] wrote:

It seems I faced with the same problem. Fit operation on image in PNG
format distorts colors. The error is reproducible. Here is the code:

Image(bytes).fit(64, 64).writer(PNG).withCompression(9).write(out)

Original image:
[image: image]
https://cloud.githubusercontent.com/assets/765471/4106033/dc2e5f06-31b4-11e4-8cab-3b476cf0e851.png

Produced image:
[image: image]
https://cloud.githubusercontent.com/assets/765471/4106039/ef7f54ac-31b4-11e4-8416-9e81f8fc3ef2.png

I hope this helps. Sad to say, but such an issue devalues all other
advantages of this great library like performance. It was a first image I
tested against. Used versions: 1.4.1 and 1.4.2

—
Reply to this email directly or view it on GitHub
#54 (comment).

from scrimage.

Sorry, you are right. Original image is JPEG. Not PNG.

from scrimage.

We need to replace the JPEG reader we're using. That will fix it. Although
the standard one has other errors (like it fails when meta data is a bit
odd).

On 1 September 2014 10:16, Andrey Zhuchkov [email protected] wrote:

Sorry, you are right. Original image is JPEG. Not PNG.

—
Reply to this email directly or view it on GitHub
#54 (comment).

from scrimage.

It seems that https://github.com/haraldk/TwelveMonkeys can help to avoid issues of standard JDK reader. Moreover it provides plugins to extend standard set of supported formats. Just add it to classpath:

"com.twelvemonkeys.imageio" % "imageio-jpeg" % "3.0-rc5"

However it didn't help for my image, but online EXIF viewer claims it as follows:

WARNING: No color-space metadata and no embedded color profile: Windows and Mac web browsers treat colors randomly.

Repeated export using GIMP solved the issue.

from scrimage.

Good idea to use the online EXIF viewer.

Apparently the scrimage writers doesn't save metadata with the image, which may cause problem if the image uses a non standard color profile.

Scrimage already uses readers from twelve monkeys.

from scrimage.

Yeah the twelve monkey readers are used, as they apparently get around issues the standard Java one has. But if they are having issues with the colouring, perhaps we should raise a ticket over there ?

from scrimage.

Hmmm... It looks like nowadays Oracle JDK outperforms twelvemonkeys. I didn't know that you have already attached it and that was the reason I got the same results in both cases (with 12monkeys and without them). In short, this issue is a 12monkeys fault. Posted bug is here.
Is it time to switch JPEG reader back? :) I suppose 12monkeys can be detached from dependencies and then described on wiki as an option for scrimage users.

from scrimage.

Perhaps the reader writers should be independently shippable.
On 2 Sep 2014 20:58, "Andrey Zhuchkov" [email protected] wrote:

Hmmm... It looks like nowadays Oracle JDK outperforms twelvemonkeys. I
didn't know that you have already attached it and that was the reason I got
the same results in both cases (with 12monkeys and without them). In short,
this issue is a 12monkeys fault. Posted bug is here
haraldk/TwelveMonkeys#59.
Is it time to switch JPEG reader back? :) I suppose 12monkeys can be
detached from dependencies and then described on wiki as an option for
scrimage users.

—
Reply to this email directly or view it on GitHub
#54 (comment).

from scrimage.

Hello,

TwelveMonkeys here, just chiming in to let you know that the problem has been known for some time, and is already fixed in the master branch.

I'm seriously short on time, but if you guys want to help creating a new release candidate, maybe that would be a good thing for everyone? :-)

Regards,

Harald K

from scrimage.

Hello Monkeys. Thanks for reply. How can we help?
Also, how hard would it be to take the reader out of the JAI framework and use it standalone with arrays of bytes?

from scrimage.

Hi again,

I was just thinking if you would tag/build/publish the release candidate for me, but it's maybe better if I just do it myself. Hope to find some time tonight.

JAI has a license (or, combination of licenses) that makes me just stay away from it. :-)

Apart from that, the main advantage of the JPEGImageReader from JAI ImageIO is it's native library backing (which I don't think has an OSS license at all). This native library supports only selected platforms and makes distribution and installation harder. So I'm not sure it's worth the hassle.

Not sure what you mean by:

standalone with arrays of bytes

?

But technically it sound's a like a couple of hours, trying to figure out and minimize dependencies, before integrating it to your project.

Best regards,

Harald K

from scrimage.

I just mean like using it without depending on the Java Image / Java AWT
libraries. So it can be used on headless systems and android.

On 4 September 2014 10:22, Harald Kuhr [email protected] wrote:

Hi again,

I was just thinking if you would tag/build/publish the release candidate
for me, but it's maybe better if I just do it myself. Hope to find some
time tonight.

JAI has a license (or, combination of licenses) that makes me just stay
away from it. :-)

Apart from that, the main advantage of the JPEGImageReader from JAI
ImageIO is it's native library backing (which I don't think has an OSS
license at all). This native library supports only selected platforms and
makes distribution and installation harder. So I'm not sure it's worth the
hassle.

Not sure what you mean by:

standalone with arrays of bytes

?

But technically it sound's a like a couple of hours, trying to figure out
and minimize dependencies, before integrating it to your project.

Best regards,

Harald K

—
Reply to this email directly or view it on GitHub
#54 (comment).

from scrimage.

I see.

Well, Java2D classes like BufferedImage, Raster etc can be used in a headless environment already (ie. java.awt.headless=true). However, most ImageIO plugins relies heavily on these classes (BufferedImage, Raster, DataBuffer, SampleModel, ColorModel, ColorSpace, etc), so the challenge is to create replacements for all these classes.

I'd say: Doable? Yes. Lots of work? Plenty...

Best regards,

Harald K

from scrimage.

I'm also experiencing this issue for jpeg images with custom metadata. Any updates on the status of a fix? Or anything else we can do to help?

from scrimage.

Hi,

I notice the TwelveMonkeys dependencies are still at 3.0-rc5.. Since then I've released 3.0 and 3.0.1 (plus some more release candidates).

You probably want to update the dependencies to 3.0.1, which fixes quite a few bugs.

Regards,

Harald K

from scrimage.

I did tests on the mushroom image after updating to twelve monkeys 3.0.1 and it seems to work as expected.

from scrimage.

I confirm the bug fix for the forest and the guitar images.
Thanks @haraldk !

from scrimage.

I can also confirm updating the twelve monkeys dependency to 3.0.1 fixed my issue as well. Thanks for the quick response, @haraldk.

from scrimage.