Legacy ImageMagick Discussions Archive

I knew 50% was neutral for a and b because they can be negative. But C ?? I thought C and H were simply the polar version of a and b .

I didn't expect the output for cases e and g.


convert -size 100x256 gradient:#000-#F00 d.png
convert d.png -set option:modulate:colorspace LCH -modulate 50,100 ...

I am attempting to reduce saturation in LCH colorspace, but am getting unexpected results.


convert -size 256x200 gradient:#000-#F00 -set option:modulate:colorspace HSL -modulate 100,50,100 a.png

convert -size 256x200 gradient:#000-#F00 -set option:modulate:colorspace LCH -modulate 100,50,100 b ...

Thank you snibgo for clarifying the issue. Reading through the info:, it appears that -distort also changes the colorspace.

Adding "-set colorspace RGB" after the -distort works around this problem. Interestingly, so does adding it before the -distort. It appears that distort is okay with gamma=1 ...

Here I convert a (slightly) color image to linear grayscale, resize it, and covert back to sRGB. This works great. When I replace -resize with -distort (for the purpose of adding a rotate and crop/pad, and hopefully higher quality processing), the result is darker. Does anyone know what colorspace ...

Is there a way to use an expression for crop's geometry? I've done this with -distort, -print, and filenames. Does it work anywhere else? I vaguely remember someone getting this to work for -size xc:, but I can't find the post.

convert in.jpg -crop %[fx:min(w,h)-10] x %[fx:min(w,h)-10] +5+5 out.jpg ...

The weirdest part is Lightroom tiffs work great in IM. My only problem has been -fx, and I have no hypothesis as to how this could be.

I expect a gray image, as demonstrated in the other tests. Of course I want -fx to work for a more complex case, but "0.5" is the most "neutral" operation I could conjure.

An example image:
https://drive.google.com/file/d/0Bxw3ymi4doXqeGZJVVpPNS0zcTA/

Tested using IM 6.8.8-1 and 6.8.9-8 on Windows ...

This test shows it too:
convert in.tif -format "%[mean]\n" info:-
> 28624
convert in.tif -strip -resize 200x200 -format "%[mean]\n" info:-
> 28626.4
convert in.tif -fx "0.5" -format "%[mean]\n" info:-
> 0
convert in.tif -strip -resize 200x200 -fx "0.5" -format "%[mean]\n" info:-
> 0
convert in.tif ...

convert rose: -evaluate Set 50% test_1.png
convert rose: -fx "0.5" test_2.png
convert in.tif -evaluate Set 50% test_3.png
convert in.tif -fx "0.5" test_4.png

The first three test cases result in a gray image as expected. The forth results in a black image. Has anyone encountered this before?

in ...

In conclusion, I didn't realize that -rotate used the distort:viewport setting. Handy to know.

convert -define distort:viewport=100x80-10-10 rose: -rotate 10 out_5.png

I got it working!

output image


convert ^
-size 106x106 xc:rgb(246,245,229) ^
-stroke none ^
-fill rgb(68,94,109) -draw "circle 52.5,52.5 1,52.5" ^
-fill rgb(246,245,229) -draw "rectangle 0,43 105,62" ^
-write mpr:screw +delete ^
-size 95x1 xc:rgb(76,117,142) -size 10x1 xc:rgb(246,245,229 ...

Thanks Bonzo. Alternatively, a +define distort:viewport before rotating worked.

I'm getting a white box I hadn't expected. Does anyone know why? Here I am attempting to create a tiled background, then composite an image on top. This is just enough of a larger command to demonstrate the issue.

: unexpected white box
convert -size 1x1 xc:blue ^
-filter point -virtual-pixel tile ...

Yes, Windows is weird about quotes. But they are not the problem this time.

label:@ filename reads from a file correctly (cases 1 & 4)
label:@- reads from a pipe correctly (cases 2 & 3)
label: handles newlines properly. (case 4, and as a direct string)
but when @- and newlines are mixed, nothing ...

Something about newlines when using label:@- is causing a problem. Is this expected? Does this happen only on Windows?

Test 1-4 work as expected. Tests 5 & 6 give the error:
convert.exe: unable to read blob `-': No such file or directory @ error/blob.c/FileToBlob/1055.
If -size is specified for ...