Bug 310651 - DjVu documents blurry at non-unit-fractional zoom levels
Summary: DjVu documents blurry at non-unit-fractional zoom levels
Status: RESOLVED UPSTREAM
Alias: None
Product: okular
Classification: Applications
Component: DjVu backend (show other bugs)
Version: 0.15.80
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-25 14:49 UTC by Jaan Vajakas
Modified: 2013-03-12 18:34 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaan Vajakas 2012-11-25 14:49:04 UTC
DjVu files (and most probably other raster formats too, in case of images with sharp edges) are much sharper at zoom levels that are unit fractions or multiples on 100%, i. e. 100%/n or n*100% where n is a natural number. So I think the zoom level 33% should be replaced with something like 33.333333333% (maybe displayed to the user as 33.33% or 1/3). Similarly, 12% should be replaced with 1/8=12.5%. For consistency, 66% should probably be replaced with 2/3=66.666666667% as well, although the sharpening effect is smaller in that case.


Reproducible: Always

Steps to Reproduce:
1. Open a DjVu file containing some text.
2. Set zoom to 33% using the zoom drop-down box.
3. Type manually 33.3333333 in the zoom field and press <Enter>.
4. Close Okular.
5. Reopen the DjVu file in Okular.
Actual Results:  
After step 2, the text is quite blurry. After step 3, the text becomes much clearer (although Okular displays 33.33% as the zoom level, it seems that it actually uses 33.3333333). After step 5, Okular again displays 33.33% as the zoom level, but the text is blurry again, so it seems that Okular has rounded off the zoom level when saving the view settings.

Expected Results:  
* The zoom drop-down box should contain the value 1/3=33.33333333333% in the first place instead of 33% (and similarly 12.5% instead of 12% and 2/3=66.66666666667% instead of 66%).
* When saving the view settings, higher precision should be used for the zoom level so that the same zoom level would be restored after closing and reopening a document.

The blurriness could also be significantly mitigated by subpixel rendering (Bug #276199) which would have its own merits as well. But even with subpixel rendering, unit fractional zoom levels would give better results.
Comment 1 Albert Astals Cid 2012-12-01 12:04:11 UTC
Can you attach the djvu file you use to reproduce this issue?
Comment 2 Jaan Vajakas 2012-12-03 19:15:29 UTC
The superiority of 33.3333333333333% (compared to e. g. 33% or 33.4%) and of 12.5% (compared to e. g. 12% or 13%) is visible in most DjVu documents I have seen, e. g. in http://www.archive.org/download/flatlandaromanc01abbogoog/flatlandaromanc01abbogoog.djvu
(e. g. page 9).
In
http://www.archive.org/download/flatlandromanceo00abbouoft/flatlandromanceo00abbouoft.djvu
(e. g. page 9 again) the superiority of 33.3333333333333% is perhaps even more visible, but that of 12.5% is less noticeable.
As for 66.66666666666667%, I cannot say it is either better or worse than 66% in the documents I have tried.

Actually at first I thought that this might be a general rule of image scaling that integer factors are better, but now, looking at the libdjvulibre code I see that it comes from the bad scaling algorithm in libdjvulibre, which first scales the image down to a unit fraction of the original size and then scales down again to get the image at the requested zoom level. E. g. in order to scale to 34% it seems to first scale by a factor 1/2 and then by a factor 0.68, which gives a blurry result, but at zoom level 33.333333% it only scales the image once, by a factor of 1/3. But djvu documents at zoom level 51% do not look worse to me than at 50% which can be explained by the fact that in both cases, libdjvulibre only scales the image once.

Originally I thought that theoretically unit fractional zoom levels should be better because in that case a document containing a black pixel on a white background would always displayed on screen as a single gray pixel on white background, whereas with non-unit fractional zoom levels it could be displayed as two gray pixels (still assuming that the zoom level is less than 1). But in practice, comparing djvu files at 50% and 51% I couldn't say that 50% was any better. So now it seems to me that unit fractional zoom levels might have an advantage of better performance (or why else would libdjvulibre use them as intermediate step?) but perhaps there is no significant theoretical win in quality. But I am not an image processing expert, as you've probably understood. 

In conclusion, it seems there are three solutions to the problem of blurry display of DjVu documents at non-unit-fractional zoom level:
1) improve the scaling code in libdjvulibre,
2) implement own scaling in okular, 
3) my original suggestion (change the zoom levels in okular's dropdown box to unit fractions).

1) or 2) would of course be better solutions than only 3) because e. g.  Fit Width would still result in non-unit fractional zoom levels. With 1) or 2), a subpixel scaling feature might also be implemented. The rationale for 2) might be that okular could handle the scaling of all its supported raster formats in a unified manner, but 1) would also benefit other libdjvulibre users.
Comment 3 Albert Astals Cid 2013-03-10 21:43:21 UTC
To be honest 1) makes more sense to me. Could you contact the djvulibre developers about it? Seems weird to me they scale twice.

Thanks for the deep analysis :-)
Comment 4 Jaan Vajakas 2013-03-12 15:42:27 UTC
I filed a feature request at DjVuLibre:
https://sourceforge.net/p/djvu/feature-requests/65/
Comment 5 Albert Astals Cid 2013-03-12 18:34:29 UTC
Great, I'm going to set this as Resolved->Upstream as it is a thing to fix in upstream and we can't do more as of now.

If upstream decides to ignore you or they say that actually we are doing it wrong and should it do in a different way come here and reopen the bug.

Thanks a lot for caring about Okular :-)