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,100 e ...

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.png ...

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 7 ...

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.tif ...

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) +append ...

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 case ...