Summary: | page rendering blurry when rotated (90° or 270°) | ||
---|---|---|---|
Product: | MuPDF | Reporter: | zeniko |
Component: | fitz | Assignee: | Robin Watts <robin.watts> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | robin.watts, sebastian.rasmussen |
Priority: | P4 | ||
Version: | unspecified | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
URL: | http://code.google.com/p/sumatrapdf/issues/detail?id=1135 | ||
Customer: | Word Size: | --- | |
Attachments: |
Rendering of document at 0 and 90 degrees.
patch2 |
Description
zeniko
2010-12-28 22:30:39 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 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. 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. 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.
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) 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); (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). 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. Your patch didn't regress any rendering in my test suite. Thanks. 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.
Tor has now recorded patch2, so closing this bug. |