New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 594909 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 3
Type: Bug



Sign in to add a comment

Poor image quality when viewing and printing PDF documents

Reported by david.os...@gmail.com, Mar 15 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce the problem:
1. View a PDF containing images tagged with AdobeRGB in Chrome
2. Compare the display or printed result with e.g. IE

What is the expected behavior?
Image quality is poor in gradient areas, both on screen and when printing

What went wrong?
When viewing PDF:s in Google Chrome (tested with version 49.0.2623.87), many images are displayed with poor quality, resembling JPG defects, most noticably in gradient areas. Even when the PDF:s are printed on a local printer, the image quality is poor. When viewing and printing from IE (tested with IE11) using the Adobe Reader plugin, the quality is fine, and the same goes for Firefox.

After some investigation, it turns out that the same image displays fine if it is tagged with sRGB color profile, instead of the original AdobeRGB profile.

Is there a known issue with poor image quality in Chrome PDF Viewer?

I will attach files to illustrate the issue:

AdobeRGB.pdf
A PDF with an image with the AdobeRGB profile

sRGB.pdf
A PDF with the same image tagged with sRGB profile

Chrome49 - Left sRGB - Right AdobeRGB.PNG
Screenshot of the two PDF:s above viewed with Chrome 49 (sRGB to the left, AdobeRGB to the right).

Chrome49 vs IE11 - AdobeRGB.PNG
Screenshot of the AdobeRGB.pdf viewed with Chrome 49 (left) and IE11 (right)

Did this work before? N/A 

Chrome version: 49.0.2623.87  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0
 
AdobeRGB.pdf
1.8 MB Download
sRGB.pdf
1.8 MB Download
Chrome49 - Left sRGB - Right AdobeRGB.PNG
295 KB View Download
Chrome49 vs IE11 - AdobeRGB.PNG
353 KB View Download
Components: Internals>Printing
Status: Untriaged (was: Unconfirmed)
Tested this issue on Windows 7 using chrome latest stable M50-50.0.2661.94.
No major difference observed in the image quality when viewing and printing provided PDF documents in chrome.

Marking it as untriaged and adding appropriate label, so that someone from print team will look in to this issue.

Thanks!
Hello,
Please observe that you must test with images under the specific conditions explained above to trigger the problem (e.g. AdobeRGB)
Cc: caryclark@google.com
Components: Internals>Plugins>PDF
This bug still exists, an update would be welcome.
Cc: msarett@chromium.org
Labels: OS-Linux
Status: Available (was: Untriaged)
I still see this on Chrome 58 on Linux too.

Narrowing down the problem, running: pdfium_test --png AdobeRGB.pdf, the rendered has artifacts. Building pdfium_test with Skia enabled doesn't improve the rendering.

+msarett to help take a look to see if there's anything we can do on the Skia side. It could be the case that PDFium is screwing up here. In which case from Skia's perspective, it's garbage in, garbage out.

Comment 7 by msar...@google.com, Mar 2 2017

IIRC, pdfium has its own set of image decoders.  I would *guess* that there is some sort of low quality color space transformation happening in these decoders that is causing the artifacts.

That might be a good place to start.

One approach to this bug might be to switch pdfium to use Skia's image decoders, which, regardless of this bug, I think would be a positive change.  I don't know much about pdfium, but I suspect that this would be a nontrivial project.
Project Member

Comment 8 by sheriffbot@chromium.org, Apr 16 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: -msarett@chromium.org
Components: -Internals>Printing
Labels: -Pri-2 -Hotlist-Recharge-Cold Pri-3
It's happening in CPDF_ICCBasedCS::TranslateImageLine(). The sRGB PDF goes through the sRGB path, whereas the AdobeRGB PDF goes into bottom path where lcms does the transformation.
Status: Available (was: Untriaged)

Sign in to add a comment