Could someone verify this bug that I just submitted to bugzilla? Basically the saved jpeg which views fine in internet explorer and irfanview does not view properly in GIMP 2.8.

img ref: http://www.fontplay.com/freephotos/thir ... 108-21.jpg

Bugzilla link: https://bugzilla.gnome.org/show_bug.cgi?id=677583

result as seen by GIMP:



result (hopefully looks good in your browser too):

What do you want to say?
The picture you provided is a clean colorful picture - nice
What you present here is a b/w picture.
So what's the problem?
What should one do with it?

If you open the jpeg in GIMP, you will see a poster separation line in the sky that is not there if you view the jpeg in the browser. The snapshot shows that separation line (at least on my monitor; glad that it does or there would be mud in my eye; lol) but the actually saved jpeg does not. May not be an issue with CRTs but for the 2209wa e-IPS display that I use it shows quite clearly (again, see the snaptshot capture with the red pointer showing the poster line separation).

Lyle, I can't see it on my VAIO laptop. Here's a screenshot.

win 7 64 2.8
looks fine in mine and in palemoon

The posterization is visible on the plain JPEG in my browser (Firefox) on my laptop LCD screen, and once I have downloaded the file, it also shows in Gwenview and Okular (and of course in Gimp 2.6, but no more than in the other two). It is more visible if the angle of view is above or below the perpendicular.

If you use the Pointer dialog, you'll see that the bands correspond to an increment in the RGB values. If you want to make it less visible you have to blur the transitions by using spread noise (20-30px).

I'm seeing a huge difference between when I have the same image opened up in GIMP then when opened up in either Irfanview or IE. That's the issue ofnuts. If you see no difference, then it's something with the my Windows install of GIMP. Yes, there usually is some posterization w/ monochromatic renders which can be reduced by blur or spread noise, but that is not what I'm actually trying to address. Again, the band that shows in GIMP is at least 10 times more noticeable when I open the image in GIMP then if I open it up in my browser or Irfanview.

Different gamma, or color management?

It may be color management ofnut, but I'm just using s-RGB (at least that's what I think I am using) but GIMP 2.8 seems to have varying issues so it indeed might be a color management issue in GIMP. Regardless, I will see what the bugzilla folks think. There's other issues with color management such as brush lag that looks like Hatti figured a work around, so I'm suspecting whatever they did to change color management between GIMP 2.6x and 2.8 is causing most of the headaches that exist now. Good call by the way. My gut's believing this is the case too.

Got off track and just tested this now offnuts. I changed the color management from color managed display to no color management and now it appears as it should. Will add this tidbit to the bugzilla and hope I don't get reamed again. lol

Just realized I can't do this; if I choose no color management, then aRGB images won't automatically get converted to sRGB (which is the behavior that I want). Disabling Color management, therefore, is not acceptable. Oh well.

OK; looked at my color management settings again, I changed both RGB and monitor color profiles to be sRGB and voila, no issue again (accept now brush lag is back; can't win them all. lol). Thanks again ofnuts. Strange that I had the settings like I did. Don't remember doing this. Had no issue like this in GIMP 2.6x. Oh well. Now it's back to being a feature rather then bug.