Scale images.

Description

Image mummifiers need the ability to scale images if they are beyond some configurable threshold.

A user will likely want to dump a bunch of full-size, original images into the source tree without bothering to individually scale or otherwise manipulate them. But they probably don't want the full-size image being deployed to the size, primarily because of file size. Thus there needs to be some configurable threshold, probably based on file size, above which the image mummifier would automatically scale the image.

Environment

None

Activity

Show:
Garret Wilson
March 14, 2021, 2:55 PM

Reopening to reduce the default scale length to 1920, which at this point in time will probably work better for most users, based upon the tests described above and real-life usage.

Garret Wilson
February 14, 2021, 10:52 PM
Edited

As discussed in GUISE-169, here are some sample image compression sizes, assuming embedded metadata and a max scale length of 2560:

Image

Quality 0.8

Quality 0.6

Quality 0.5

Quality 0.4

ad3-1089.jpg

336KB

239KB

218KB

198KB

am4-3213.jpg

802KB

591KB

537KB

483KB

ashd1-7696.jpg

417KB

288KB

256KB

226KB

IMG_0525.jpg

528KB

339KB

300KB

265KB

IMG_0743.jpg

492KB

408KB

361KB

317KB

IMG_3527.jpg

630KB

418KB

366KB

313KB

Dropping down to a max scale length of 1920 drastically reduces the image size:

Image

2560 Quality 0.8

2560 Quality 0.6

1920 Quality 0.8

1920 Quality 0.6

ad3-1089.jpg

336KB

239KB

215KB

156KB

am4-3213.jpg

802KB

591KB

533KB

392KB

ashd1-7696.jpg

417KB

288KB

272KB

193KB

IMG_0525.jpg

528KB

339KB

347KB

239B

IMG_0743.jpg

492KB

408KB

379KB

263KB

IMG_3527.jpg

630KB

418KB

396KB

265KB

As 1080p is 1920x1080, and WUXGA is 1920x1080 (see TV resolution confusion: 1080p, 2K, UHD, 4K, 8K, and what they all mean), it might be beneficial to drop the default scale settings to a scale length of 1920 and a compression quality of 0.6. If more and more people have 4K displays, users can always change the settings (or we can raise the defaults) and regenerate the images.

Garret Wilson
December 20, 2020, 10:16 PM

Already there is some sort of a semantic overloading of scaleThresholdFileSize as a toggle for reducing photo size, with a toggle for general photo processing. Maybe we should change this to be processThresholdFileSize as a threshold for general processing. The idea is that we only want to process big images; presumably the smaller images are of a different type or role (icons? previews?) and area already "the way we want them". This processThresholdFileSize might be the most typical way to turn on image processing across the board, but may be too coarse in some cases; another way to turn processing on or off for individual images would be useful. The scaleMaxLength setting would also make more sense, as we may want to process the image but may wind up not scaling it if it is already small enough.

This new way of looking at the toggle will fit will with the realization that we probably need to update the destination metadata of the scaled images. In the current development implementation, all metadata is being stripped.

Garret Wilson
December 20, 2020, 10:12 PM

It's tempting to want to lower the default scaleMaxLength down to 1280 because that would undoubtedly bring a big savings in file space. But in worldwide desktop screen stats a width of over 1280 pixels is almost ubiquitous. And photo sites such as Flickr have lightboxes that show full screen on big monitors. So at least 2560 is probably best. Maybe another approach would be to add some facility for automatically generating preview versions of only 1024 or something. We would need to work out how we indicate whether previews are generated or not.

Garret Wilson
December 13, 2020, 11:40 PM

Wow, I'm impressed at the result! It's taking an ~8MB full-color 5467 x 3644 JPEG file and at 80% compression quality it's turning out a 2560 x 1706 file that's only ~330K. If you zoom in a lot you can see some JPEG blocky effects, but at that resolution I wouldn't expect it to be noticeable on a normal screen, and especially not on a mobile phone. This is really good—better than I expected, especially since I haven't worked with this image scaling code in well over a decade.

Fixed

Assignee

Garret Wilson

Reporter

Garret Wilson

Labels

None

Epic Link

Components

Fix versions

Priority

Major