Reporter@ Thanks for the issue.

Request you to provide a sample file to reproduce this issue which will help in further triaging.

Thanks..

@susan.boorgula

I found this issue is related with ssse3 (128 bit number operation) in some computers.
May be is bugs about cpu??

Attanchment file is png image that decode failed.

Deleted: err_image_log_3.png 16.0 KB

	err_image_log_3.png 16.0 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@susan.boorgula
Use gfx png decoder, will reproduce this issue in some computers.
computer cpu is i5 6600

qingzhao2008@ Thanks for the update.

As this issue is related to libpng with ssse3 (128 bit number operation), this is out of scope of triaging at TE end.
Hence adding 'TE-NeedsTriageHelp' label and requesting someone from 'Internals>Core' team to look into this issue and help in further triaging.

Thanks..

Adding a few folks who recently worked on libpng and zlib.

Sorry for the delay, was busy with other stuff.

I can start looking into it and will report back soon.

@qingzhao2008: you mentioned that this was observed on some computers (but not others). Could you provide further information?

Another question: how did you track it down to a specific change id? In a test I disabled that patch and observed no changes in the current behavior.

An update: disabling (https://gist.github.com/Adenilson/4846c10e404d8a006f3c860944e2d08f) *all* the zlib optimizations (Adler-32, crc32, inflate_fast) the rendering results are the same, please see attached screenshots.

That being said, I can confirm a difference in rendering results when compared to FF.

It seems that upstream FF is using libpng 1.6.35 (https://github.com/mozilla/gecko-dev/blob/master/media/libpng/png.h#L4) while we are using 1.6.34 (https://cs.chromium.org/chromium/src/third_party/libpng/README?l=1).

A look into upstream libpng points to some possibly related fixes in their changelog (https://github.com/glennrp/libpng/blob/libpng16/CHANGES#L6042), with 1.6.35 released last July (3 months ago).

I also noticed that eog (Eye of Gnome) will fail to render the test image correctly, my workstation's libpng version is 1.6.34 (please see attached image). Since Ubuntu's libpng/zlib lacks any of our optimizations, I guess is safe to assume that the optimizations are not causing this rendering mismatch.

Maybe is a good time to upgrade our libpng?.

Adding a libpng OWNER in the issue.

Deleted: vanilla.png 24.8 KB

	vanilla.png 24.8 KB View Download

Deleted: disabled.png 27.2 KB

	disabled.png 27.2 KB View Download

Deleted: eog.png 17.6 KB

	eog.png 17.6 KB View Download

The image is transparent on the left so maybe Eye of Gnome is drawing a different background (a checkerboard board but the looks).

Anyho, I attached an sRGB IEC1966-2.1 color profile (standard sRGB) to the test image (attached) ...

Deleted: err_image_log_3_sRGB.png 4.5 KB

	err_image_log_3_sRGB.png 4.5 KB View Download

... and then created a test program to draw the image on a <canvas> element and extract and checksum the decoded pixels via getImageData() (test.html attached).

Note that since the <canvas> element is an sRGB surface, per spec, by default, no color correction occurs in browsers that detect that the input image is also sRGB and hence skip the application of color correction in this case (Chrome, Safari).

Deleted: image.html 669 bytes

image.html 669 bytes View Download

On a MacBook Pro 13" which does have SSSE3, my results in different browsers are:

Deleted: crbug-849145.png 128 KB

	crbug-849145.png 128 KB View Download

I verified that the SSSE3 optimization was being used in #17 in Chrome.

Firefox (at the bottom) does not spot that the image and the <canvas> have the same color profile, and applies an sRGB -> sRGB color transform, which adds some distortion.  Chrome and Safari (top two) agree on the image checksum.

I also disabled the SSSE3 optimization (per #11) and repeated the test, and the output is identical to the result shown in #17.

Some computers might have broken SSSE3 but I not seeing any evidence of that here, other than in the issue title).  I'm not seeing broken or incompatible rendering of the given PNG image.

@Noel: Really interesting.

So I guess we can mark it as not-a-bug/won't fix?

> So I guess we can mark it as not-a-bug/won't fix?

Heading that way: we are really in "NeedFeedback" given your questions in #10.

We have a test case now (#16) and it would be very exciting if it could be used to provide evidence of CPU with broken SSSE3 implementations.

*** UI Mass triage ***

adding labels for expert review.