Scale images.

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.

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

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

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.

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.

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.

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.