On 07/28/2013 07:00 AM, Elle Stone wrote:
I'm going to call the image that isn't inverted "right.jpg" and the
image that is inverted (not really inverted, but certainly it's not
right) "wrong.jpg", to avoid typing really long file names.
"Right.jpg" doesn't have an embedded ICC profile. Right.jpg was
created using Gimp, according to the metadata. Upon selecting it to
open it, Gimp displays a normal-looking thumbnail that resembles
"right.jpg". Upon opening it, Gimp automatically assigns the Gimp
built-in sRGB profile and right.jpg looks like you'd expect.
"Wrong.jpg" does have an embedded ICC profile with description "sRGB
IEC61966-2.1". From the embedded profile metadata it appears to be
some version or another of the original sRGB profile created by
Hewlett-Packard and Microsoft back in 1998. That profile or versions
thereof has been used by almost all imaging software and operating
systems, until V4 profiles started creeping in.
Upon selecting wrong.jpg with Gimp to open it, the thumbnail looks
more or less like the thumbnail for right.jpg, but not exactly (the
colors are washed out, the blue looks purple, the green looks brown).
But upon actually opening it, the colors go all wrong. However, assign
the Gimp built-in sRGB profile in place of the embedded profile and
wrong.jpg now looks very similar to the right.jpg, slightly washed
out, purple instead of blue, brown instead of green, but not
According to the metadata, wrong.jpg is a Photoshop thumbnail. Was the
original image created by Photoshop? Was the thumbnail really created
using Photoshop and extracted using some software?
I've attached a spreadsheet with the embedded metadata for right.jpg,
wrong,jpg, and the argyllcms version of the original MS/HP sRGB
profile, lined up so the metadata fields match. There are very small
differences in the metadata, not enough to explain why wrong.jpg looks
wrong until the Gimp built-in sRGB profile is assigned.Attached is
also a copy of "wrong.jpg" with the argyllcms version of sRGB embedded
so you can see the color differences.
I'm going to try to extract the embedded ICC profile in wrong.jpg to
see what the tone curves look like. Ofnuts is right, the problem (or
at least one problem) is the embedded profile. And the two images
aren't the same to begin with.
On 07/28/2013 07:21 AM, Elle Stone wrote:
It turns out that the embedded profile in "wrong.jpg" does have an
incorrect tone response curve. See the attached screenshot comparing
the incorrect TRC to what it should look like. The embedded profile
compresses the original sRGB 1024-point TRC range from 0 to 65535
down to about half the original range, then drops abrubtly to 0. Very
odd. Never seen that before.
So is there some software in your toolchain of softwares that
handles your images, that is somehow embedding a corrupt version of
the original sRGB ICC profile? Is there a timestamp that might let
you know when the "inverted" images were last handled, which might
let you know what software embedded the corrupt profile?
Hi Elle & Ofnuts,
Thank you for your replies. However, I think I have wasted (at least
some of) your time because my original information was incorrect. But,
it has been a terrific learning process for me, so thank you!
a) Yes, the two example images are different; they were not supposed to
be the same. The "correct/right" one was just to generally show what
the colors were generally supposed to look like. I should have posted
copies of the exact same file (on my server vs on the hosting site), but
it turns out that would not have helped (or actually would have shown up
the real problem), because...
b) I was INCORRECT (damn, my perfect record for the year has been ruined
-- ha!) about the "wrong/negative" original TIFF being okay and the
original (on my server) JPEG being okay. They are NOT okay. However,
when I look at them using Linux file management and file viewer programs
they look okay ... that must be because those programs are only looking
at the preview and are not parsing the whole image file and/or looking
at the color profile in the image file. The preview is okay, but the
image (actually the color profile in the image file) is mucked up and
looks "wrong/negative". It did not occur to me that there there were
_three_ components involved (preview component, profile component, and
image itself). LESSON: Look at the precursor image files in Gimp, not
in file managers or file viewers.
c) Ofnuts: The "wrong/negative" image on the hosting provider is
identical to the image on my server, when viewed by the exact same tools
(and also filesize, etc.). I understand some "image hosting sites" mess
with images. However, I am using a web hosting service that just gives
me space and does not seem to mess with anything (thank goodness).
Thanks for that idea, however.
Okay... the rest of the story.
The "wrong/negative" image dates from 2004 OR EARLIER. I think it
really dates from the early-to-mid 1990s. However, all versions of it
have a 2004 timestamp due to an incorrectly handled migration between
hardware (three times between 1990 and 2004). The timestamps were not
The "wrong/negative" image was indeed created originally in the 1990s
using Photoshop running on Windows 95. The color profile embedded is
whatever Photoshop stuck on it.
I have _many thousands_ of such 1990s Photoshop-created images, but only
a handful have shown this problem.
So, if I am understanding correctly, all I have to do is remove the
profile and the image should be fine.
I _have_ successfully removed the profile and the original TIFF now
looks perfect in Gimp.
To do this on Linux, using commands from the ImageMagick package, I did:
TO SEE THE PROFILE INFO:
identify -verbose inputfilename.tif
TO REMOVE ALL PROFILES (and comments)
convert inputfilename.tif -strip outputfilename.tif
(Not sure if the convert syntax is legacy or modern, but it
worked for me).
(I could have used mogrify instead of convert. They are similar, but
mogrify does the changes in-place thus destroying the old state of the
image and with NO UNDO unless you have a backup original file. Much
more dangerous for somebody like me who is experimenting!)
So.... the "damaged image file" was actually a damaged color profile
within the image file.
In a way, that still leaves the original question; but perhaps it is a
silly question. Whether or not flipping one bit (in the profile section
of the image file) would cause this kind of damage? Or whether there
would have to be extensive changes to the profile to cause it?
My best guess about the underlying source of the cause is either
defective memory (RAM) or defective individual disk controller or
defective RAID disk controller sometime in the last 15+ years.
Unfortunately, all three problems have occurred at least once and I am
just lucky that only a few random images have been found to be damaged.
Still, the stray neutrino theory sounds better.
gimp-user-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list