Closed N-R-K closed 1 year ago
Yeah, using the --quality
option to specify whether a lossless format's compression should be better and slower or worse and faster seems to be an outdated way of doing things from before we had webp and jxl.
Perhaps we can imitate flac
and gzip
and let the user specify a number in the command line which describes the compression level:
This would use the slowest PNG compression level:
scrot -9 test.png
This would use the fastest:
scrot -0 test.png
Or we can imitate the cwebp
encoder and not use the number as a command line option, but rather as an argument to an option:
scrot --compression 9 test.png
This has the downside that we don't seem to have a suitable letter to use as the short option. cwebp
uses z, and the letter z seems to be associated with compression (zstd, zip, 7zip, gzip, zlib, xz, etc) and that would be a good one, but it's taken.
Also, a jpg screenshot gets 4:2:0 chroma subsampling, that's bad for text and generally an outdated technique from back when codecs and encoders were more primitive, these days they give lower quantizers to chroma instead. I wonder if there's a way to tell imlib not to do chroma subsampling.
This has the downside that we don't seem to have a suitable letter to use as the short option. cwebp uses z, and the letter z seems to be associated with compression (zstd, zip, 7zip, gzip, zlib, xz, etc) and that would be a good one, but it's taken.
How about uppercase Z? It's free as of now.
Quality and compression are not inherently tied together. For example, in jxl you can specify a quality (100 for lossless) and still independently set a compression level as well.
Also for lossless formats like PNG, --quality doesn't make much sense (indeed, imlib2's PNG saver will ignore "quality" when "compression" is set).
As such, adding a separate --compression flag might be useful.