Page MenuHomePhabricator

Scaling of images should take place in a linear colour space
Open, LowPublic

Description

Dispenser mentioned to me that our image scaling is working on non-linear sRGB colour space, which causes some less than ideal results on dark images

Background on issue:

For image magick, it looks like this can be addressed by just adding some command line flags (which flags unfortunately vary by version). [Except possibly not jpeg as that's shrunk by libjpeg]

Its unclear if something similar can be done in vips well still using the very efficient sequential read and not creating a giant temporary file. There is a -a option to vipsthumbnail that could maybe be used.

(If it can only be on image magick and then not for jpeg, we possibly wouldn't want to do it at all to keep things consistent. Requires more investigation anyhow)


Version: 1.24rc
Severity: normal

Details

Reference
bz66337

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:09 AM
bzimport set Reference to bz66337.
bzimport added a subscriber: Unknown Object (MLST).

Its unclear if something similar can be done in vips well still using the
very efficient sequential read and not creating a giant temporary file.
There is a -a option to vipsthumbnail that could maybe be used.

In my test, the -a option slowed things down quite a bit, and increased memory usage to beyond 400mb. :(

jcupitt wrote:

Some benchmarks:

$ time vipsthumbnail -a wtc.jpg --vips-leak
memory: high-water mark 65.98 MB
real 0m4.039s
user 0m4.003s
sys 0m0.038s
$ time vipsthumbnail wtc.jpg --vips-leak
memory: high-water mark 6.22 MB
real 0m0.307s
user 0m0.289s
sys 0m0.020s

wtc.jpg is a 10,000 x 10,000 pixel RGB image.

The main source of the slowdown is that you can't use libjpeg's very fast shrink-on-load feature, since that's calculated in Y, which is not linear. Instead, you have to decode the entire image, convert to a linear space (vipsthumbnail uses XYZ), and then shrink that.

-a is much more competitive if you use a format that doesn't support shrink-on-load, such as vanilla tif:

$ time vipsthumbnail wtc.tif --vips-leak
memory: high-water mark 44.31 MB
real 0m2.662s
user 0m0.513s
sys 0m0.119s
$ time vipsthumbnail -a wtc.tif --vips-leak
memory: high-water mark 66.62 MB
real 0m3.623s
user 0m3.547s
sys 0m0.078s

memuse should not be huge, the whole process can still be streamed.

Some image formats allow decoding in a lower resolution, for example PNG with enabled interlacing adam 7. JPEG files can probably decoded in a lower resolution by simply ignoring the DCT coefficients of the higher frequencies (simple example: use only DC values).
I assume that in the PNG case the lower-resolution result corresponds to a subsampled image, and in the JPEG case it corresponds to a linearly-downscaled image without gamma-correction.

Maybe, as a tradeoff between quality and computation time, the image could be decoded to two times the target resolution(*) (if the decoder allows it) and then gamma-correctly downscaled to the target resolution.

(*) (to be more precise: a resolution which is at least two times as big in width and height, but not bigger than the input image resolution)

AntiCompositeNumber raised the priority of this task from Low to Needs Triage.EditedMay 21 2020, 2:54 AM
AntiCompositeNumber edited projects, added Thumbor; removed Multimedia.

Thumbnailing on Wikimedia wikis is now handled by Thumbor instead of MediaWiki. This issue still occurs, as demonstrated by https://commons.wikimedia.org/wiki/File:Gamma_3x3.jpg.

The suggestion from http://www.ericbrasseur.org/gamma.html?i=1#ImageMagick is to approximate a linear conversion for sRGB by first setting the gamma to 0.454545, scaling, then setting the gamma to 2.2.

ImageMagick suggests setting the colorspace to RGB (which is treated as linear), scaling, then setting it back to sRGB.

The first method only works with sRGB, which is less than ideal. Changing the colorspace is probably not a great idea for non-sRGB images either, as ImageMagick may have undefined behavior with other color profiles. (see also). Both solutions increase the conversion time for the test image by approximately 1.5x and 2x respectively.

Lanczos is now the default filter in ImageMagick.

The situation in vips is not much better. We use vips directly, which means that configuring it to work in linear space is not easy and probably requires multiple commands and more temporary files. vipsthumbnail has a command-line switch, but may cause other problems (I haven't tested it).