convert - downscaling comic pages

[steve___]

Steve: I think you forgot to include the originals in your zip file? Or is the orig folder meant to be empty.

Sorry about that. The originals can be found here:
https://dev.zcomix.com/files/convert-orig.zip

I was away yesterday. I have input to your thoughts above. I'll
respond later today.

[steve___]

Thank you Steve.
Putting the result of your testing in my "What worked for someone" memory box.
P.S. I persist in thinking that an EWA can always be found that does better than any tensor method in a specific situation. Have you tried something like

Code: Select all

convert infile[0] -quiet -colorspace RGB -gamma 1.333333333333333 -filter RobidouxSharp -distort Resize $res -gamma .75 -colorspace sRGB +repage outfile

or

Code: Select all

convert infile[0] -quiet -colorspace RGB -gamma 1.333333333333333 -filter CatRom -distort Resize $res -gamma .75 -colorspace sRGB +repage outfile

?

Not a problem. If it wasn't for you and Fred, I'd still be in the weeds

Of the 12 filters I thought gave the best results, ewa caused 11 of them
to become slightly blurry also it increases the file size. The
exception was Catrom which became over sharpened.

The 12 filters are:
Bartlett Blackman Catrom Cosine Hamming Hann Kaiser Lanczos Lanczos2
Lanczos2Sharp LanczosSharp Welch

Since these were so close, I went with Catrom because of the smaller
file sizes. File sizes aren't a major factor, I just used it to help tip
the scales.

Here are my tests for the 12 filters:
https://dev.zcomix.com/files/convert-tests-all.zip (1.3gb)

I'll revisit my ewa notes and supply more exact information later today.

[steve___]

I also think that something like this may work well given what you have found to work well, esp. with color:

Code: Select all

convert \( input.png -depth 16 -set colorspace sRGB -colorspace RGB \) \
 \( -clone 0 -gamma 1.666666666666666 -filter RobidouxSharp -distort Resize $res -gamma 0.6 \) \
 \( -clone 0 -filter RobidouxSharp -distort Resize $res \) \
    -delete 0 \
 \( -clone 1 -colorspace gray -auto-level \) \
 -compose over -composite \
 -set colorspace RGB -colorspace sRGB \
output.png

or maybe the same with RobidouxSharp replaced by CatRom. Instead of GAMMA=5/3 and RECIPROCALOFGAMMA=3/5, you could also try other values. See http://www.luminous-landscape.com/forum ... ic=91754.0
Also, I've not addressed the issue of how best to compress for the web. This is a whole different story. I myself use highly customized calls to libjpeg-turbo after producing images that cjpeg understands. One can do much with ImageMagick, but you need to learn how JPEG compression works to get the most out of it.

re: gamma - I did test with .333333333333333, 1.333333333333333, 1.5, 2, 3, 4
with their reciprocals.

re: lossless compression - I did some brief testing with mozjpeg and it
performed better than the current libjpeg-turbo. I did notice that
convert would error while I had it installed. The error was:

Code: Select all

convert: JPEG parameter struct mismatch: library thinks size is 4760, caller expects 584 `bar.jpg' @ error/jpeg.c/JPEGErrorHandler/319.

Does IM need to be recompiled?

[NicolasRobidoux]

...
Of the 12 filters I thought gave the best results, ewa caused 11 of them
to become slightly blurry also it increases the file size. The
exception was Catrom which became over sharpened.

Try -filter RobidouxSharp -distort Resize. Maybe try -filter LanczosRadius -distort Resize if you don't mind larger files at the same JPEG compression.
Also note that the complex one IM script (that contains two -distort Resize commands to produce one output file) I put in one of my recent answers is really effective at reducing halo while keeping things defined and the colors pretty well preserved.
-----
Maybe you don't see the benefit of EWA because you are downsampling quite a bit and your material is not particularly prone to aliasing (of both the jagginess or moire kind) being offensive.
OK. Line art etc is a diferent game than digital photographs. Which is exactly why I'm thankful for your experiments.

[NicolasRobidoux]

libjpeg-turbo has an interface that clones every version of libjpeg that has been put out (at least the older ones), which I understand is what IM expects. It looks like mozjpeg is not. Mismatched API -> no go.

[NicolasRobidoux]

The only way to compare JPEG compressors (and resampling methods, for that matter) is to compare visual quality at the same file size and level of being "stripped" (see the documentation for exiftool), meaning that the same amount of metadata must be present in the images.

[NicolasRobidoux]

If you want lossless compression, don't use JPEG. Use pngs and pngcrush.
However, very high -quality (starts at about 95) is basically impossible to distinguish from lossless unless you make it your mission of seeing the difference (instead of enjoying the content).
At -quality 98 no one should complain. Anything above is a waste of JPEG. (Unless mozjpeg has done something highly nonstandard, in which case you need to ask yourself whether all browsers will support it well.)
I'm not saying that "common jpeg" is perfect as is. But it's universal and actually works amazingly well (if well used. which it is far from always).

[NicolasRobidoux]

Steve: I'm looking and commenting on this really really fast. My apologies for comments that are not always carefully phrased or even considered. I figure such are better than none.

[steve___]

Here are my tests with ewa specifically:
https://dev.zcomix.com/files/convert-ewa.zip (158mb)

A good place to look is the bike engine on panel three of 04.png

Tomorrow I'll do testing with the more complex command.

[NicolasRobidoux]

Steve:
There is something that I find quite strange when I compare, say, Catrom-rgb-gamma1.3-web-04.png with RobidouxSharp-rgb-ewa-same...
The pixel value of the background is (255,253,229) with (orthogonal) Catrom, and (255,252,217) with EWA RobidouxSharp. You can see it as more yellowed "paper" in the EWA result. With HDRI (unless there is a bug), the result within "flat color" areas should be the same within 1, almost always. Did you do something differently (other than -filter RobidouxSharp -distort Resize instead of -filter Catrom -resize)? Do/undo the gamma differently, maybe? This seems to be suggested by the different "thickness" of black lines.
Also: Maybe a "-depth 16" should be inserted early on?

[steve___]

I see a much more yellow bg with ewa+gamma1.3

Here are the commands that were run: http://sprunge.us/cJeD

I'll try testing with -depth 16'

[steve___]

'-depth 16' did not fix the bg problem when using ewa+gamma1.3 and it
doubled the file size:

Code: Select all

$ stat -c "%s %n" Catrom-rgb-ewa-gamma1.3-depth16-web-04.png ../convert-ewa/Catrom-rgb-ewa-gamma1.3-web-04.png ../convert-ewa/Catrom-rgb-web-04.png ../convert-ewa/Catrom-rgb-gamma1.3-web-04.png orig/04.png
1717440 Catrom-rgb-ewa-gamma1.3-depth16-web-04.png
795208 ../convert-ewa/Catrom-rgb-ewa-gamma1.3-web-04.png
799574 ../convert-ewa/Catrom-rgb-web-04.png
811273 ../convert-ewa/Catrom-rgb-gamma1.3-web-04.png
206710 orig/04.png

The test files are here:
https://dev.zcomix.com/files/convert-depth16.zip (395mb)

[steve___]

The more complex convert command fixed the ewa+gamma bg problem but the
file sizes are quite large. Removing '-depth 16' made no noticeable
difference (to me) and the file sizes came in line with output from
other tests.

At first look, both RobidouxSharp-ewa-gamma1.6-complex-web-04.png and
Catrom-gamma1.6-complex-web-04.png beat my current favourite
Catrom-rgb-gamma1.3-web-04.png. With RobidouxSharp being the new
winner. I need to run the complex command on more test images and
do comparisons.

I'd also like to time the more complex convert command with what I was
using.

Here are the latest test images:
https://dev.zcomix.com/files/convert-complex.zip

[NicolasRobidoux]

Put -depth 8 right before the output file name if you put a -depth 16 near the beginning. This tells IM that what you want from now on (and "from now on" means "for the output file" since it is just before the output file) is 8-bit per channel. Because you are using HDRI Q16, the result, by the time the result reaches the output file, was 16-bit by default (unless you use, say, JPEG, which is 8-bit). The reason the files turned out double the size is that what I gave you produces 16-bit pngs (2x8=16).
So, off the top of my head, you should have a -depth 16 at the beginning and a -depth 8 at the end.
However, if you are concerned about run time and memory use, compare the outputs (which you appear to have done), and if you don't notice anything different skipping the -depth commands, drop them because they likely have a significant impact unless the input files are small.
This being said, I'd rather have more accurate color preservation, but I'm not running on a server farm on a budget.

[NicolasRobidoux]

Code: Select all

convert \( input.png -depth 16 -set colorspace sRGB -colorspace RGB \) \
 \( -clone 0 -gamma 1.666666666666666 -filter RobidouxSharp -distort Resize $res -gamma 0.6 \) \
 \( -clone 0 -filter RobidouxSharp -distort Resize $res \) \
    -delete 0 \
 \( -clone 1 -colorspace gray -auto-level \) \
 -compose over -composite \
 -set colorspace RGB -colorspace sRGB -depth 8 \
output.png

Then pass it through pngcrush (unless you want to preserve metadata, in which case you probably should play with exiftool).