Re: [Gimp-user] Is there a single bit that can accidentally flip an image to negative? (not Gimp specific)

[Jay Smith <jay JaySmith com>]

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
> "inverted".
>
> 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.
>
> Elle Stone

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?
>
> Elle Stone


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 
properly preserved.

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.

Jay