Page MenuHomePhabricator

gamma settings are horribly dark, leads to subtle artifacts in all texvc output
Closed, DeclinedPublic

Assigned To
None
Authored By
bzimport
Jun 23 2011, 7:33 AM
Referenced Files
F7689: Svg-MathML.png
Nov 21 2014, 11:31 PM
F7688: specimen.latex
Nov 21 2014, 11:31 PM
F7687: gammacomp.png
Nov 21 2014, 11:31 PM
F7685: dvipng-large.png
Nov 21 2014, 11:30 PM
F7686: mathcomp2.png
Nov 21 2014, 11:30 PM

Description

Author: richard.tollerton

Description:
Comparison of four renderings of the Gradient Theorem, http://en.wikipedia.org/wiki/Gradient_theorem

Web images are invariably stored in a gamma-compressed format. If the wrong
gamma compression is applied to antialiased text, then in addition to the text
appearing too light/dark, other distortions may be apparent.

The dvipng command line in render.ml specifies --gamma 1.5. This causes an
*extreme* darkening of the rendered equation, but also causes several other
visual artifacts (enumerated below). The "ideal" gamma setting to use is
0.454545 (1/2.2), as referenced by the sRGB standard. Of course, that also
generates far lighter text, and that too must be taken into account. (I suppose
having an excessively dark gamma may aid readability on smartphones that resize
everything.)

The attached image contains four different renderings of the same equation,
available at http://en.wikipedia.org/wiki/Gradient_theorem:

  1. Straight-up copy of the png as downloaded from wikipedia. Ostensibly, this image came from texvc.
  2. Attempted reproduction of 1) using "dvipng -D 142 -T tight --strict --gamma 1.5". This appears to be a fairly good reproduction.
  3. "Ideal" rendered output: dvipng is run at 2400dpi (!), resized down to 142dpi in ImageMagick, and then gamma-compressed. Steps: a) dvipng -D 2400 -T tight --strict b) ImageMagick convert -depth 16 -define filter:filter=Box -resize 226x49 -gamma 2.2 -depth 8 (resize geometry chosen to shrink image size by 2400/142=16.9x)
  4. Reproduction of 3) using dvipng -D 142 -T tight --strict --gamma 0.454545. This looks very close to 3).

Comparing text samples 1 and 2 ("gamma 1.5") vs 3 and 4 ("gamma 0.45") on my LCD
displays, I observe the following:

  • Obviously, gamma 1.5 output is darker.
  • The bold symbols q, p, r are of comparable weight at both gamma 1.5 and 0.45, while all the other symbols are much lighter at gamma 0.45. This makes it substantially easier to perceive the boldness of these symbols at gamma 0.45.
  • Notice in gamma 1.5, the integral sign is visibly jagged down its center, even when viewing it from a distance. Similarly, the parentheses appear "chunky". These appear much smoother at gamma 0.45.

I would opine that, at the very least, developers make the gamma setting a
configurable option. But beyond that... have developers given any thought
towards lowering the gamma setting from 1.5?


Version: unspecified
Severity: minor

attachment mathcomp.png ignored as obsolete

Details

Reference
bz29544

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:30 PM
bzimport added a project: Math.
bzimport set Reference to bz29544.
bzimport added a subscriber: Unknown Object (MLST).

richard.tollerton wrote:

2400dpi equation image

For reference, here is the high res (2400dpi) version of the equation, which was resized to create 3) in the four-sample image previously attached.

Attached:

dvipng-large.png (756×3 px, 53 KB)

You're definitely right that the current rendering looks way too dark and the antialiasing looks pretty bad... but the 2.2 gamma seems much too light to me for on-screen reading, probably because many thin strokes are much thinner than one pixel at this size.

I suspect the darker gamma got picked because darkening the antialiased thin strokes effectively makes them appear "wider", making the text overall more legible.

Are there alternate font rendering settings or even alternate fonts that might be better for screen-oriented rendering?

(Of course moving forward we may also want to be thinking about better in-client rendering to aid legibility on high-resolution displays and printing directly from the wiki. There are various MathML/SVG/scary HTML roads that can be taken there, all of which will be more work than tweaking the latex settings. :)

richard.tollerton wrote:

Comparison of four renderings of the Gradient Theorem, http://en.wikipedia.org/wiki/Gradient_theorem

Includes original four samples referenced in original bug report, plus screenshot of same equation rendered in Adobe Acrobat.

Attached:

mathcomp2.png (369×706 px, 15 KB)

richard.tollerton wrote:

Comparison of dvipng output, gammas 0.5-1.5

dvipng output at gamma settings 1.5, 1.4, 1.3, 1.2, 1.1, 1.0, 0.9, 0.8, 0.7, 0.6, 0.5, plus Acrobat screencap for comparison.

Attached:

gammacomp.png (445×900 px, 19 KB)

richard.tollerton wrote:

There are a few knobs that could be tweaked on the TeX side of things, in
decreasing order of potential magnitude:

  • The weight of Computer Modern does not scale proportionally with increasing point side -- strokes are relatively thicker at smaller point sizes. In principle, this means that you might be able to get a weightier font, looking better at gamma 2.2, by reducing the point size and increasing the DPI setting. But I don't know how big of an effect this has.
  • Various outline versions of Computer Modern are tweaked slightly differently, and some versions are considered darker than others. See for instance this discussion: http://arxiv.org/help/pscm.

The only other particularly useful rendering alternative I'm aware of is
dvips+convert, which of course already appears to be implemented. I haven't
yet studied if that would generate any better of an output than dvipng does.
(dvipng also appears to be applying the inverse gamma setting from what it
should be, insofar as gamma 0.454545 *darkens* the image in any image editor.)

Besides that, yeah, something like MathJax would also solve this issue by
offloading the actual text rendering to the client.

Certainly the darker gamma setting can be justified in terms of maximum
compatibility, even if perhaps it wasn't necessarily chosen for that reason. And
while gamma 2.2 might be "the best" in terms of lowest distortion -- ie, the
closest representation of a high-resolution printout of the same equation --
given that we're talking about web pages and not printed pages, using a gamma
significantly lower than 2.2 may be quite reasonable. There are always tradeoffs
of course.


On the subject of possibly selecting a better dvipng gamma setting, I have some
new images:

  • I've replaced the original comparison image with a new one, with a 5th sample -- a screen cap of the equation PDF drawn in Adobe Acrobat. It looks great of course (it's kinda their job to look great hehe), but it also looks both much lighter than the Wikipedia rendering (#1) but much darker than my resized rendering (#3).
  • I've also uploaded a comparison of dvipng gamma settings from 0.5-1.5, along with the Acrobat rendering, to perhaps help select a new default dvipng gamma setting. Pay close attention to the integral sign between the Acrobat rendering and *any* of the dvipng renders for gamma >0.5 -- very interesting.

Great examples! :)

On my screens I'm reasonably happy with the overall visible weight of the chars around the 0.8-1.0 range but the antialiasing still looks a bit nasty on those (while definitely not as bad as at 1.5).

If we don't end up doing anything else I'd probably be inclined to go with changing the value into that range (but should try a few other renderings to make sure it doesn't get unreasonably light on other chars or smaller bits of text).

This does though remind me of bug 16719 -- right now there's not a great system in place to manage updating old renderings other than changing the hashing such that all the old files get rebuilt on next parse (which can cause a CPU spike in production; not sure if that's still a concern for deployment at present).

richard.tollerton wrote:

Rudimentary specimen LaTeX document, using most of what is allowed to be used with the Math extension.

Attached:

richard.tollerton wrote:

I tend to agree that the 0.8-1.0 range looks the best. I'd probably choose
gamma 1.0, for the simple fact that.... it's 1.

I've attached a rudimentary specimen LaTeX doc that covers most of the math
symbols documented on Wikipedia, plus a few sample formulas. From there, I
played with adjusting math fonts and sizes, to see if I could find anything
significantly better than cm at gamma 1.0. Lemme know if you want these PNGs
uploaded (they're big).

I particularly focused on sans- serifs under the hopes of killing two birds with
one stone -- I suppose that, while we're on the topic of esoteric typesetting
issues, we probably shouldn't be pairing Computer Modern with whatever default
sans-serif font is used for the rest of Wikipedia :)

The Arev font looks *particularly* nice; even at gamma 0.5, it's quite weighty,
yet has clearly distinguishable boldfaces. But it seems to have three or four
significant rendering issues (specifically: capital "I", vertical var "|",
and over/underbraces) and I'm not a big fan of the parentheses.

If you can tolerate more blurriness, and 10-100x worse performance, you can
make convert upsample the equation by 2-4x, resample with a Gaussian filter,
then apply some ridiculously dark gamma setting. The filter's blurriness
gives the gamma compression a lot of room to work in, and unsurprisingly,
all of the rendering artifacts I originally mentioned vanish.

physik wrote:

Right: Chrome showing SVG Left: Firefox showing MathML rendering

Attached:

Svg-MathML.png (853×1 px, 192 KB)

physik wrote:

I would be happy about comments concerning the new rendering mode using svg and MathML demonstrated on
http://math-test2.instance-proxy.wmflabs.org/wiki/Fourier_series

physik wrote:

It seems that this is no problem in MathML rendering mode anymore.