1350733 - copying image data gives different result as saving image to disk

Status: NEW

(Core :: ImageLib, defect, P3)

Description

[teo8976]

Attachment: example.eml

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36

Steps to reproduce:

- Receive an email with two attached png images, see the attachment example.eml
- saved both attached files and opened them in an image editor, e.g. GIMP. Check the color of a pixel in the yellow region
- now go back to the email in Thunderbird; right click on any of the images and do "Copy Image"
- go to the image editor (e.g. GIMP) and paste the copied image to a new one. Check the color of a pixel in the yellow region 


Actual results:

the two colors are different.
This means that the image data copied with right-click "Copy Image" is not identical to the data in the attached file. 
I don't know whether the error is in decoding the image, or in copying it to the clipboard.


Expected results:

The copied and pasted image data should be IDENTICAL in both cases, to the pixel and to the bit in any pixel value. There's one and only one correct way to decode a png image. Even if some alteration of the image when DISPLAYING it in the message was justified (e.g. if it is resized), which is not the case, "copy image" should copy the actual image data.

Comment 1

[Jorg K (CEST = GMT+2)]

BWmarker#fee300Interlace.png: fee300
BWmarker#fee300.png: fee300

Copy image in TB and pasted in to GIMP:
BWmarker#fee300Interlace.png: fde200
BWmarker#fee300.png: fde200

I can confirm the bug, but I have no idea what's going on or who to ask. Let's try Neil.

Neil, have you ever seen something like this and who could we ask?

Comment 2

[Neil Deakin]

The gtk clipboard expects images as GtkPixBufs, which are not pngs, so you're not going to receive the same image when pasting. (A similar situation applies to other platforms.) There could be some issue in the encoding though which is done in widget/gtk/nsImageToPixbuf.cpp.

I know little about image encoding though so I can't provide much more info.

Comment 3

[teo8976]

> The gtk clipboard expects images as GtkPixBufs, which are not pngs

So what, once decoded the pixels should be identical. There's no lossy encoding involved anywhere.

Comment 4

[Jorg K (CEST = GMT+2)]

Thanks for your reply, Neil. My results in comment #1 are from Windows 7, the reporter seems to be on Linux (X11; Linux x86_64) and your reply sounds like it addresses Linux with "gtk", right?

(In reply to Neil Deakin from comment #2)
> I know little about image encoding though so I can't provide much more info.
So who else could we ask? I suppose the module owners/peers of widget. So let's try some.

Vladimir and/or Karl, could you shed some light onto this. Or should I NI Jim Mathies (who's usually very busy)?

Comment 5

[Jorg K (CEST = GMT+2)]

Attachment: BWmarker#fee300.png

One for the images attached to the original message.

Comment 6

[Jorg K (CEST = GMT+2)]

Oops, one *of* the images attached to the original message.

When you view it in FF, you'll notice the white background, when viewing in GIMP, you can see the transparent background.

Copying in FF and pasting to GIMP also gives yellow colour fde200 like when pasting from TB. So it's not a TB issue but an issue of the underlying Mozilla core code.

Comment 7

[Karl Tomlinson (:karlt)]

I suspect the people watching ImageLib will know most about this.

Could copying the image have the image data in the screen's colorspace, perhaps?

identify -verbose BWmarker_fee300.png says

Colorspace: sRGB

Comment 8

[Jorg K (CEST = GMT+2)]

FWIW, viewing the image with Windows Photo Viewer, the colour is fee200 (that's doing a screenshot with Greenshot and pasting it into GIMP or also using GIMP to do a screen shot). Note that viewing the image in FF gave fde200 and the original is fee300.

Comment 9

[Timothy Nikkel (:tnikkel)]

I'm guessing this is because of a color profile in the image. Try removing it from the image and then compare. Here is one page that explains how

http://www.app-v.be/citrix/how-to-remove-icc-profile-information-from-png-images-from-web-interface

Comment 10

[teo8976]

I just tried this:
- removed any color profile
- emailed the image to myself
- repeated the test

By opening the file in gimp, the yellow color is still fee300. By copying and pasting from Thunderbird, it is now fee533 

Also, with the original email the color I get is fee432, other people have reported fe4200. Even if the presence of a color profile could explain a difference between the copy-pasted image and the directly opened image, which I'm not sure, it should certainly be consistent across different platforms/machines.

Comment 11

[Jorg K (CEST = GMT+2)]

Please note that Thunderbird has nothing to do with this. It is the Mozilla core software that renders the image onto the screen. So a valid test would be to attach the "treated" image (colour profile removed) here and then view it in FF and see what you get when using "Copy Image", see comment #6.