[Color rendering] Bug or feature? Colors get blurred (or "smoothened"?) when very small images are scaled up

[KurtPfeifle]

Here are three different screenshots of PDF viewers (composed into one image) rendering the exact same file:

1. LEFT: _PDF.js_ (v1.0.1149) running in Chrome/OSX (sorry, I currently don't get PDF.js to work in Firefox/OSX)
2. CENTER: _Adobe Reader_ (v11.0.10)
3. RIGHT: _Preview.app_ in OSX 10.9 (v.7.0 -- 826.4)

The PDF source code is written by myself in order to demonstrate a problem I've previously noticed with other (real life) files and provide a "minimal working example PDF".

The characteristics of this PDF:

1. It contains a single image (inline).
2. The image is compose of only 4 pixels with 4 different colors (width x height == 2 x 2).
3. The image is scaled up to 630x630 points on a PDF page sized 640x640 points.

As you can see, only Acrobat renders the 4 pixels as one would expect (IMHO). Or? (You may disagree with me and regard the way PDF.js renders it as a feature, not a bug...)

PDF.js deviates from Acrobat's rendering and prefers to show the 4 scaled-up pixels in a smoothened (if you regard it as a feature :-) or heavily blurred (if you regard it as a bug) way.

Preview.app also deviates from Acrobat -- albeit in a different way (you'd think that the image is ridden by heavy JPEG artifacts).

However, there are other open source PDF viewers which all render the file identical to Acrobat's way, with sharp edges between the pixels and uniform color for the four areas:

1. gs (Ghostscript
2. gv (Ghostscript-based)
3. MuPDF (own rendering engine)
4. Zathura (Poppler-based)
5. Evince (Poppler-based)
6. Chrome's built-in, native PDF viewer (dunno what is its name, maybe 'pdfium'?)
7. SumatraPDF (MuPDF-based)
8. gv (Ghostscript-based)

---

_{Hmmm... I'm looking for a way to attach my demo PDF, but I can't find it. Maybe I re-write it to use ASCII-only stream for the image data, so I can embed it inline.}

[Snuffleupagus]

Hmmm... I'm looking for a way to attach my demo PDF, but I can't find it. Maybe I re-write it to use ASCII-only stream for the image data, so I can embed it inline.

Use a file hosting service, such as: Dropbox, Google Drive, Microsoft OneDrive, or similar.

[KurtPfeifle]

Here is the PDFs source code. It should work if you copy it from the web page into a text editor and save it as a filename.pdf. (In case you have access to the markdown source and copy it from there: remove the four space characters which are at the start of each line!)

Also pay attention that your text editor does not use Windows line endings (double-byte) -- set it up to use Unix-style EOL characters.

---

_{Edit: It now occurred to me that there may be another reason that could cause a "corruption" when copying my PDF's source code into a text editor, and then saving it from there:}

• _{Some text editors have a (default) setting which removes all trailing spaces when saving a file.}
• _{This would remove the required trailing spaces in the /xref section of my file. (The standard requires that each line of the xref describing the byte offset of a PDF object MUST be exactly 20 Bytes long (including the EOL marker). So for Windows-style EOLs (double bytes), the trailing space would have to go, but for single-byte EOLs they must be present.}

%PDF-1.3

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%    Hand-written PDF file in preparation for @WeAreTroopers Conference 2015 in Heidelberg    %%%
%%%                          Copyright 2015 (c) <kurt.pfeifle@mykolab.com>                      %%%
%%%      License  "CC-BY-NC-SA v4.0"  http://creativecommons.org/licenses/cc-by-nc-sa/4.0/      %%%
%%%               This PDF uses "inline image data" (started with the `ID` operator)            %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

1 0 obj
<<
  /Pages        2 0 R
  /Type         /Catalog
>>
endobj

2 0 obj
<<
  /Count        1
  /Kids         [ 3 0 R ]
  /Type         /Pages
>>
endobj

3 0 obj
<<
  /Contents     4 0 R
  /MediaBox     [ 0 0  640 640]
  /Parent       2 0 R
  /Resources    <<
                    /ProcSet    [ /PDF /ImageC ]
                >>
  /Type         /Page
>>
endobj

4 0 obj
<<
  /Length       5 0 R
>>
stream

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
                                                                                                  %
  q                                                                                               %
        1    0    0      1    5    5    cm       % translate CTM                                  %
        0.1  0    0      0.1  0    0    cm                                                        %
  q  6300    0    0   6300    0    0    cm       % scaling CTM                                    %
      BI                                                                                          %
        /CS/RGB                                                                                   %
        /Filter/ASCIIHexDecode                                                                    %
        /W 2                                                                                      %
        /H 2                                                                                      %
        /BPC 8                                                                                    %
        ID ff00000080000000ff000000>                                                              %
      EI                                                                                          %
  Q                                                                                               %
  Q                                                                                               %
                                                                                                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

endstream
endobj

5 0 obj
1802
endobj

xref
0 6
0000000000 65535 f 
0000000611 00000 n 
0000000680 00000 n 
0000000769 00000 n 
0000000976 00000 n 
0000002839 00000 n 

trailer <<
            /Root   1 0 R
            /Size   6
        >>
startxref
2860
%%EOF

[KurtPfeifle]

@Snuffleupagus: Is the upload of the PDF to some hosting provider still needed now? (After all, the code has only 84 lines and 3081 Bytes.)

Anyway, good to know how it is supposed to work in the future. After all, I won't always have the time to create an ASCII-only PDF file for bug reports. :-)

[timvandermeij]

The PDF appears to be corrupt/invalid. If I close the PDF with Adobe Reader, it prompts to resave the file, indicating that something is wrong with the file itself.

[Snuffleupagus]

Is the upload of the PDF to some hosting provider still needed now?

In my opinion (since you asked): while not strictly necessary, it would still be nice if you could do that! Given the differences between various Operating Systems and Editors, manually creating a working PDF file with a text editor isn't always entirely straight forward.

(As a general note: The fewer "hoops" a developer/contributor have to jump through to reproduce an issue, that better its chances of getting fixed are :-)

[KurtPfeifle]

@timvandermeij:

1. Can you pinpoint at what may be wrong with the the PDF? (May be caused by you copying it from the website and your text editor not caring about the used EOL...) -- I do not rule out that there is a small flaw in my file. However, the issue I report here is not caused by this flaw. it happens also with a version Adobe Viewers are perfectly happy with...
2. Can you re-save it from Acrobat (to make sure the file is "ok") and then test what I described as the issue?

---

_{Edit: It occurred to me that there may be another reason that could cause a "corruption" when copying my PDF's source code into a text editor, and then saving it from there:}

• _{Some text editors have a (default) setting to remove all trailing spaces when saving a file.}
• _{This will remove the required trailing spaces in the /xref section of the file. (The standard requires that each line of the xref describing the byte offset of a PDF object MUST be exactly 20 Bytes long (including the EOL marker). So for Windows-style EOLs (double bytes), the trailing space has to go, but for single-byte EOLs they must be present.}

[KurtPfeifle]

@Snuffleupagus: You wrote

The fewer "hoops" a developer/contributor have to jump through to reproduce an issue, that better its chances of getting fixed are

That's right -- but it also is true the other way round ;-)

If you want users who report bugs and make the reports meaningful, you should also lower the bars and not ask them to jump through "hoops"!

What do you think about a website which in today's times...

1. ...invites and receives bug reports, but
2. ...at the same time directs its (bug report) contributors to another website to submit their example files and proof documents to, then come back here and somewhere supply the URL to the resource?!?

What makes it much worse:

1. This is supposed to be an Open Source project.
2. You direct me to proprietary, private hosting services.
3. This web page does not advice about how a bug submitter is supposed supply sample documents. I had to ask specifically. (Thanks to you that you responded!)

So:

_The fewer "hoops" a user has to jump through to submit a bug report, that better the chances of developers to get good and meaningful feedback :-)_

[KurtPfeifle]

Ok, here is the link to a binary version of a PDF exhibiting the problem I described:

• PDF saved by Acrobat Pro -- Example file is now binary! (But still exhibits the same behavior...)

@Snuffleupagus: Is there any more info you need that continues to earn the 4-Information-requested label?

@timvandermeij: happy now?

(BTW, my Acrobat Pro 11.0.10 is perfectly happy with the PDF which I created through copy'n' paste from the codeblock above! And, believe me, I also tested it before I uploaded the code, and afterwards too. The mistake must have been on your side, not taking into account my specifically given hints about the EOL conventions)

[timvandermeij]

Your PDF file works fine for me. Sorry for the noise in that case. I think it is some sort of scaling problem in PDF.js. Thanks for reporting this.

[stuartagrant]

Is this still an outstanding issue? Could this issue be closed?

[timvandermeij]

Yes, this is still an issue. There is a pull request above, but it's not complete.

[timvandermeij]

The pull request above is closed since it caused some other regressions, but if anyone wants to look into this issue, it may serve as a good starting point/inspiration.