Bug 691856 - page rendering blurry when rotated (90° or 270°)
Summary: page rendering blurry when rotated (90° or 270°)
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: fitz (show other bugs)
Version: unspecified
Hardware: PC Windows 7
: P4 normal
Assignee: Robin Watts
URL: http://code.google.com/p/sumatrapdf/i...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-28 22:30 UTC by zeniko
Modified: 2011-01-06 12:18 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Rendering of document at 0 and 90 degrees. (127.08 KB, image/png)
2011-01-05 14:05 UTC, Sebastian Rasmussen
Details
patch2 (1.88 KB, patch)
2011-01-05 19:24 UTC, Robin Watts
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zeniko 2010-12-28 22:30:39 UTC
The document linked from the URL exposes this issue.
Comment 1 Sebastian Rasmussen 2011-01-01 23:54:08 UTC
Oh, and zeniko as also found out that was enabling Smoothscale that causes the blurry rendering of rotated images:
http://code.google.com/p/sumatrapdf/source/detail?r=2282
Comment 2 Robin Watts 2011-01-05 12:53:51 UTC
Having looked at this, the "blurriness" referred to is indeed to do with the use of smooth scaling. The choice is to use "nearest neighbour" sampling (which results in dropouts when downscaling), or to use interpolation (which produces a softer image, but one in which every source pixel plays a part at least).

In mupdf at least, the rotation does not play a part; the image interpolation is used irrespective of the rotation (0, 90, 180 or 270). I suspect the underlying sumatra PDF bug (which relates to the 'blurriness' occurring when the image is rotated only) is because they took on an earlier version of the change that only uses interpolation in the 0 or 180 degree cases.

I therefore propose closing this bug as invalid.
Comment 3 Robin Watts 2011-01-05 13:08:35 UTC
Actually, looking at the SumatraPDF repository at the revision claimed to be the cause of this, it looks like they *do* include the code to cope with the 90 and 270 degree cases. I therefore have no idea why the bug would claim that the blurriness only occurs at those rotations.

Given that it works in my testing on mupdf, I still think we should close the bug until such time as:

 1) Someone can explain why the blurriness is itself a bad thing.

or

 2) Someone can give us instructions on how to reproduce the same mismatch between rotations within muPDF itself.
Comment 4 Sebastian Rasmussen 2011-01-05 14:05:47 UTC
Created attachment 7085 [details]
Rendering of document at 0 and 90 degrees.

I managed to reproduce the problem using the code from the latest MuPDF repo. Attached is a testcase showing the difference in rendering at 0 and 90 degrees of rotation.
Comment 5 Sebastian Rasmussen 2011-01-05 14:23:11 UTC
If I apply the patch below I get a blurry rendering at all rotations.
So it is the linear interpolation that causes the blurriness and the
interpolation is not present if the image is rectilinear and not upscaled.

sebras@hostname:~/src/mupdf2.tor$ darcs diff
diff -rN -udp old-mupdf2.tor/draw/imagedraw.c new-mupdf2.tor/draw/imagedraw.c
--- old-mupdf2.tor/draw/imagedraw.c     2011-01-05 15:11:52.000000000 +0100
+++ new-mupdf2.tor/draw/imagedraw.c     2011-01-05 15:11:52.000000000 +0100
@@ -288,7 +288,7 @@ fz_paintimageimp(fz_pixmap *dst, fz_bbox
        }
 
        /* turn on interpolation for upscaled and non-rectilinear transforms */
-       dolerp = 0;
+       dolerp = 1;
        if (!fz_isrectilinear(ctm))
                dolerp = 1;
        if (sqrtf(ctm.a * ctm.a + ctm.c * ctm.c) > img->w)
Comment 6 zeniko 2011-01-05 15:10:42 UTC
The following patch seems to fix our issue:

Index: mupdf/draw/imagedraw.c
===================================================================
--- mupdf/draw/imagedraw.c      (revision 2604)
+++ mupdf/draw/imagedraw.c      (working copy)
@@ -295,6 +295,9 @@
                dolerp = 1;
        if (sqrtf(ctm.b * ctm.b + ctm.d * ctm.d) > img->h)
                dolerp = 1;
+       /* cf. http://bugs.ghostscript.com/show_bug.cgi?id=691856 */
+       if (dolerp && fz_isrectilinear(ctm) && img->w == (int)(ctm.a + ctm.b) && img->h == (int)(ctm.c + ctm.d))
+               dolerp = 0;

        bbox = fz_roundrect(fz_transformrect(ctm, fz_unitrect));
        bbox = fz_intersectbbox(bbox, scissor);
Comment 7 zeniko 2011-01-05 15:21:37 UTC
(In reply to comment #3)
> Actually, looking at the SumatraPDF repository at the revision claimed to be
> the cause of this, it looks like they *do* include the code to cope with the 90
> and 270 degree cases.

FYI: We always use the latest code available in your public repository (just adding a bunch of bug fixes and feature additions on top that haven't made it upstream yet: http://software.zeniko.ch/sumatrapdf/SumatraMuPDF.patch )

>  1) Someone can explain why the blurriness is itself a bad thing.

Adobe Reader manages to render the document less blurry, so we should be able to so as well (and apparently we indeed are).
Comment 8 Robin Watts 2011-01-05 15:26:12 UTC
Apologies. As I said in comment 3, I was wrong, and you had taken on the full patch.

With Sebastians help I have reproduced the problem locally, and it is indeed a bug in our codebase. I've found a fix (it was caused by 2 typos - my fault), and Tor has pushed the fix to the repo.

Thanks for the bug report, hopefully the fix should sort you out.

There remains a slight mismatch between the output at 0 degrees and 90 degrees, but it's orders of magnitude smaller than before. I'm looking into that now.
Comment 9 zeniko 2011-01-05 15:48:26 UTC
Your patch didn't regress any rendering in my test suite. Thanks.
Comment 10 Robin Watts 2011-01-05 19:24:36 UTC
Created attachment 7089 [details]
patch2

Patch to solve the subpixel positioning problems exhibited by this bug.

X and Y subpixel offsets were being calculated the same way, when actually they need to be different due to the way the flipping is done horizontally and vertically.
Comment 11 Robin Watts 2011-01-06 12:18:40 UTC
Tor has now recorded patch2, so closing this bug.