Legacy ImageMagick Discussions Archive

EWA RobidouxSharp winning over orthogonal and EWA Catrom is what I expected.

Catrom with ewa is too sharp. For me the favourite was Catrom-rgb-gamma1.3

NicolasRobidoux wrote: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.

So for jpg's '-depth 16' and png's should be '-depth 8' on the output?
I did a quick test with these settings and the output looked good.

steve___ wrote: So for jpg's '-depth 16' and png's should be '-depth 8' on the output?

JPEG's should be '-depth 8' as well, but you can omit it because JPEG only
supports 8-bit (well, the spec does define a 12-bit variety but practically no one supports it).

I could be wrong, but I don't think "-depth 16" (or any other number) at the start of the command will make any difference until the image is written to a file. All internal processing is done according to Q and HDRI; a depth number makes no difference.

snibgo wrote:I could be wrong, but I don't think "-depth 16" (or any other number) at the start of the command will make any difference until the image is written to a file. All internal processing is done according to Q and HDRI; a depth number makes no difference.

That's what I thought too, but since I was giving instructions off the top of my head, I played it safe by adding a -depth 16 at the beginning.
P.S. Steve: I'm pretty sure you can omit the -depth 16 at the beginning. But not the -depth 8 at the end, unless you are producing jpegs, in which case it being there won't hurt.

NicolasRobidoux wrote:
snibgo wrote: P.S. Steve: I'm pretty sure you can omit the -depth 16 at the beginning. But not the -depth 8 at the end, unless you are producing jpegs, in which case it being there won't hurt.

Here is a quick test with a jpg using -depth16, -depth8, no depth
outputting to both jpg and png:

https://dev.zco.mx/files/convert-depth.zip (3.4mb)

In this case '-depth8' isn't usable.

When the output is jpg, '-depth 16' and no depth are the same file.

Here are the file sizes:

Code: Select all

stat -c "%s %n" convert-depth/*.* convert-depth/orig/bw-thin_line.jpg | sort -n
207734 convert-depth/RobidouxSharp-ewa-gamma1.6-nodepth-complex-web-bw-thin_line.png
208920 convert-depth/RobidouxSharp-ewa-gamma1.6-depth8-complex-web-bw-thin_line.png
220672 convert-depth/RobidouxSharp-ewa-gamma1.6-depth16-complex-web-bw-thin_line.jpg
220672 convert-depth/RobidouxSharp-ewa-gamma1.6-nodepth-complex-web-bw-thin_line.jpg
248660 convert-depth/RobidouxSharp-ewa-gamma1.6-depth8-complex-web-bw-thin_line.jpg
1114333 convert-depth/RobidouxSharp-ewa-gamma1.6-depth16-complex-web-bw-thin_line.png
1572892 convert-depth/orig/bw-thin_line.jpg

Steve:
Pretty conclusive.
-----
This is what I remember. (Anyone: correct me if I'm wrong.)
If the input image is 8-bit and you are producing a png, you'll get an 8-bit png.
If the input image is 16-bit and you are producing a png, -depth 8 may be worthwhile.

NicolasRobidoux wrote:Steve:
Pretty conclusive.
-----
This is what I remember. (Anyone: correct me if I'm wrong.)
If the input image is 8-bit and you are producing a png, you'll get an 8-bit png.
If the input image is 16-bit and you are producing a png, -depth 8 may be worthwhile.

For the 16 to 8 bit png result, what do you mean by "worthwhile"? Why would it be better at 8-bits apart from the file size?

Has any of this been tested/compared with HDRI mode?

What was the conclusion of the "best" command line (filtering approach)?

fmw42 wrote: For the 16 to 8 bit png result, what do you mean by "worthwhile"? Why would it be better at 8-bits apart from the file size?

Steve cares about file size, and an 8-bit png is almost invariably going to be much smaller than a 16-bit one.
-----
I am still waiting for Steve's conclusion RE: what works well downsampling comics, but so far, if I understand correctly,

Code: Select all

convert \( input.png -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

is the winner (in HDRI), at least if the source png is 8-bit (otherwise, making the final png 8-bit needs to be done, to minimize file size).

In Steve's message above, he said

"For me the favourite was Catrom-rgb-gamma1.3"

but I am not sure if that was before testing with RobidouxSharp or not.

Steve, have you come to some conclusion?

NicolasRobidoux wrote:Steve:
Pretty conclusive.
-----
This is what I remember. (Anyone: correct me if I'm wrong.)
If the input image is 8-bit and you are producing a png, you'll get an 8-bit png.
If the input image is 16-bit and you are producing a png, -depth 8 may be worthwhile.

I wasn't clear. The test above is using an 8-bit jpg. The 8-bit png's
are not useable, they are distorted (at least. I was hoping to hardcore '-depth
8'. I'm not sure how important it is or what to test on in order to set
'-depth' to 8 or 16.

fmw42 wrote:In Steve's message above, he said

"For me the favourite was Catrom-rgb-gamma1.3"

but I am not sure if that was before testing with RobidouxSharp or not.

Steve, have you come to some conclusion?

The more complex RobidouxSharp command is slightly better than plain
Catrom on the two images I tested. I need to test those two more as
well I'd like to stress test the server using them. I'll do this once
it get the command/logic nailed down.

The 8-bit png's are not useable, they are distorted

In what way? Can you post one to show us what is happening and the command line you used?

Are you running Q16 or Q8 IM?

fmw42 wrote:
The 8-bit png's are not useable, they are distorted
In what way? Can you post one to show us what is happening and the command line you used?

Are you running Q16 or Q8 IM?

Here are the tests I posted earlier:
https://dev.zco.mx/files/convert-depth.zip

The command is what Nicolas posted:

Code: Select all

convert \( "$f[0]" -quiet -set colorspace sRGB -colorspace RGB \) \
    \( -clone 0 -gamma 1.666666666666666 -filter "$filter" -distort Resize $res -gamma 0.6 \) \
    \( -clone 0 -filter "$filter" -distort Resize $res \) \
    -delete 0 \
    \( -clone 1 -colorspace gray -auto-level \) \
    -compose over -composite \
    -set colorspace RGB -colorspace sRGB -depth 8 +repage \
    outfile

Code: Select all

 $ convert -version
Version: ImageMagick 6.8.8-5 Q16 x86_64

Legacy ImageMagick Discussions Archive

convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages

Re: convert - downscaling comic pages