Legacy ImageMagick Discussions Archive

Hello All,
I know this issue in general has been discussed to death, but between the version changes and all, I cannot wrap my head around it. Can paypal you some beer change if you can help me understand a solution. I am going for image quality here, processing time is not a problem.

First Question, on Downsampling
I would like to resize images by quite a bit for proofs (think 200x300cm to A2) and would like to do so with gamma-aware resizing. The color profile is generally Adobe RGB, but not always so, and the files are almost always 16bit TIFFs. I want to keep the colorspace and the format the same for output.

Code: Select all

depth 16 -colorspace sRGB -filter Lanczos -resize **% -colorspace RGB

does something, but I am not entirely sure what, as I don't understand how -sRGB is relevant when adobe rgb is not even srgb gamma. Should be going the -gamma 0.45*** -resize ** -gamma 2.2 route instead?

also, can I use

-distort for robidoux I suppose, though it takes a million years at my image sizes, the thing I don't quite understand is that if I use distort as is

Code: Select all

in.tif -distort Resize 35.89% out.tif

*35.89 is just an approximation
It does actually work in linear space, or at least, the results are comparable to resizing in linear space, though I have not entered any flags

Second Question, on Upsampling
Basically the same but for upsampling, is there anything else to watch out for, besides use of different resampling methods for halo suppression?

much love,
d

*I'll sneak in a side question, is there a way to resize a la " -resize 48x64\> " but let imagemagick rotate images so that horizontal images don't get smaller than landscape ones? For example, throw in a folder of images of differing orientation and aspect ratio so that they fit a paper size.

I suppose you have read viewtopic.php?f=22&t=25935 , and the Luminous Landscape discussions.

If your input is Adobe RGB and you want to output the same, I suggest you don't go via sRGB. If you want to linearize, use "-gamma" or "-evaluate Pow" with 2.19921875 and 0.4547069271758437. (http://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf says 2.19921875 comes from 2+51/256.) I expect the difference between 2.19921875 and 2.2 is indetectable.

For downsampling, if you also want to sharpen, I do like this method (though I work in sRGB, not Adobe RGB). I have less experience with upsampling. I have discovered that rules of thumb in one direction do not necessarily hold in the other direction.

Yes I have, it's part of the confusion despite an imaging science minor, that's what I get for not knowing math and dealing in reproduction workflows *embarrassed*.

So you suggest I go with the following for downsampling?

Code: Select all

convert in.tif -depth 16 -evaluate Pow 2.19921875 -filter LanczosRadius -resize X -evaluate Pow 0.4547069271758437 out.tif

I don't see a difference between entering depth 16 or not, is IM just detecting it because I am working with tiffs regardless of flag?

If in.tiff is 16 bit/channel/pixel, then "-depth 16" will make no difference. "-depth 16" merely tells IM how many bits/channel/pixel to write the output.

For basic downsampling (with no sharpening), I have not found that I prefer anything over a simple "-resize". I know some people do prefer downsampling in linear space, and I respect their opinion. But for me, with my photography, I see no difference in quality.

If you want to resize in linear space then, as you say:

Code: Select all

-evaluate Pow 2.19921875 -filter YY -resize X -evaluate Pow 0.4547069271758437

For downsampling with sharpening, I do like the results from the complex method. In a nutshell, I use:

Code: Select all

      -define filter:c=0.1601886205085204 -filter Cubic -distort Resize %mSize% ^
      ^( -clone 0 -gamma 3 !FILT! -gamma 0.333333333 ^) ^
      ^( -clone 0 !FILT! ^) ^
      -delete 0 ^
      ^( -clone 1 -colorspace gray -auto-level ^) ^
      -compose over -composite

... where %FILT% is:

Code: Select all

-define convolve:scale=%shpAmount%%%^^,100 -morphology Convolve DoG:3,0,0.4981063336734057

... where %shpAmount% is zero to 100, or even 300 for very flat inputs, or for very punchy outputs.

More details on my page http://im.snibgo.com/resamphm.htm

I haven't (yet) followed up NicolasRobidoux's suggestion on the IM thread to experiment further.

EDIT: my syntax above is Windows BAT. Adjust for bash etc.

Oh hey snibgo, I did look at your script, thanks for all that work. I found the linear space sizing to matter more with film scans that have more compressed shadows that lose more detail than the typically more open shadow of digital camera captures.

I downloaded the bat but didn't know enough BAT syntax to move to unix from the whole thing, thanks for isolating that bit, do you mind posting the few lines similarly for upsampling also?

^ I'm assuming is escape and new line in BAT, so \ in bash.

pinktank wrote:^ I'm assuming is escape and new line in BAT, so \ in bash.

Yes. And in BAT, literal percent signs need doubling, eg 25% becomes 25%%.

%NAME% and !NAME! refer to BAT environment variables, similar to bash $NAME and ${NAME}.

The BAT ...

Code: Select all

%shpAmount%%%^^

... in bash would be (I think):

Code: Select all

${shpAmount}%^

Ah, film scans, yes, they would work differently. You may find that these benefit from a more extreme gamma adjustment, or even a boost to the shadows, followed by the opposite after processing.

In my script, upsampling with or without sharpening is:

Code: Select all

    ^( -clone 0 -gamma 3 !FILT! -gamma 0.333333333 ^) ^
    ^( -clone 0 !FILT! ^) ^
    -delete 0 ^
    ^( -clone 1 -colorspace gray -auto-level ^) ^
    -compose over -composite

... where !FILT! is:

Code: Select all

-define filter:blur=!deblurValue! -filter Lanczos -distort Resize %mSize%

... where !deblurValue! is the arithmetical result of (1-0.0011450938298236*%shpAmount%).

One of the Luminous Landscape threads has a script in bash. I translated it (with minor changes) to BAT.

Hm, I converted it to bash, but something has gone awry and it gives me a super bright (all white basically image), I'm sure its something silly

Code: Select all

      convert \
  \( DK_8_0045-140__W.tif \
    -define filter:c=0.1601886205085204 -filter Cubic -distort Resize 5669x8135\> \) \
      \( -clone 0 -gamma 3 -define convolve:scale=100^,100 -morphology Convolve DoG:3,0,0.4981063336734057 -gamma 0.333333333 \) \
      \( -clone 0 -define convolve:scale=100^,100 -morphology Convolve DoG:3,0,0.4981063336734057 \) \
      -delete 0 \
      \( -clone 1 -colorspace gray -auto-level \) \
      -compose over -composite DK_8_0045-140__W_bart.tif

screenshot
https://www.dropbox.com/s/24ekus3d6cl7a ... 7.png?dl=0

snibgo wrote:-define convolve:scale=%shpAmount%%%^^,100

I believe the unix equivalent is

Code: Select all

-define convolve:scale=shpAmount%^,100

so in your case

Code: Select all

-define convolve:scale=100%^,100

though I would have expected it to be

Code: Select all

-define convolve:scale=-define convolve:scale=100%^,100%

unless the first % applies to both terms? I have not used the second term (origin value) in my work and so am not an expert on that.

Do you really think that 0.4981063336734057 is noticeably better than 0.5?

good catch, let's see, Robidoux writes it as the following in his variation, but I'll go with -define convolve:scale=100%^,100 first and let you know, 2GB Tiff takes a while even on an overclocked i7 4770k..
convolve:scale=100^,100%

*edit, looks like % applies to both regardless of it's place, at least from the image results

convolve:scale=100^,100%

I would expect this to be correct according to http://www.imagemagick.org/Usage/convol ... y_addition

Legacy ImageMagick Discussions Archive

Please help with gamma-aware resizing for non-srgb 16bit output

Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output

Re: Please help with gamma-aware resizing for non-srgb 16bit output