Page 1 of 1
Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output
Posted: 2019-09-01T15:49:24-07:00
by fmw42
I have some code below that clones an image and uses connected components on a binary version to get crop coordinates. If I output to JPG the result is wrongly grayscale. But if I output to PNG, the result is properly in color. The input is a color JPG.
Input:
This comes out grayscale JPG and should be in color:
Code: Select all
magick Unknown.jpeg \
\( +clone -fuzz 20% -fill white -opaque white -fill black +opaque white -type bilevel \
-define connected-components:mean-color=true \
-define connected-components:area-threshold=200000 \
-connected-components 8 \
-set option:cropbox "%@" +delete \) \
-crop "%[cropbox]" +repage \
Unknown_crop.jpg
This comes out properly as a color PNG:
Code: Select all
magick Unknown.jpeg \
\( +clone -fuzz 20% -fill white -opaque white -fill black +opaque white -type bilevel \
-define connected-components:mean-color=true \
-define connected-components:area-threshold=200000 \
-connected-components 8 \
-set option:cropbox "%@" +delete \) \
-crop "%[cropbox]" +repage \
Unknown_crop.png
The only difference is the output format JPG vs PNG
Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output
Posted: 2019-09-02T17:53:49-07:00
by snibgo
Inserting "+write info:" before the output, it says:
Code: Select all
Unknown.jpg JPEG 1035x1793 8-bit Bilevel sRGB 0.000u 0:00.000
I'm not sure what a
bilevel sRGB image is, but writing it to JPG removes colour.
You have "-type bilevel". The only effect this has is on the output.
If you want a bilevel output, I suggest "-colors 2 -type bilevel" immediately before the output.
Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output
Posted: 2019-09-02T19:37:33-07:00
by fmw42
Snibgo:
I do not want a bilevel output. I wanted to crop the input image without affecting the color.
The clone is converted to black and white before the -type bilevel. Adding +dither -colors 2 before -type bilevel did not change the output and should not have any bearing on making the clone into bilevel. It seems(?) that the -type bilevel setting is escaping the parenthesis and affecting the output. But it only happens for JPG and not PNG. Adding -respect-parenthesis removes/hides(?) the -set option value for the crop and I get an error message.
Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output
Posted: 2019-09-08T07:58:14-07:00
by magick
JPEG checks for grayscale images since these can be stored more efficiently in one channel. You explicitly set the type to bilevel, a grayscale variant. JPEG honors your explicit setting and stores the image as grayscale. The proper fix is to indicate your true intention with this command:
Code: Select all
magick Unknown.jpeg \
\( +clone -fuzz 20% -fill white -opaque white -fill black +opaque white -type bilevel \
-define connected-components:mean-color=true \
-define connected-components:area-threshold=200000 \
-connected-components 8 \
-set option:cropbox "%@" +delete \) \
-crop "%[cropbox]" +repage \
-type truecolor \
Unknown_crop.jpg
Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output
Posted: 2019-09-08T10:21:27-07:00
by fmw42
Sorry, I do not understand. Why is the -type bilevel "escaping" from within the parentheses so as to affect the input tricolor image? Settings have been know to "escape" in IM 6, but is not the output color type supposed to come from the first image in the command line, which is truecolor here?
Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output
Posted: 2019-09-08T17:32:27-07:00
by magick
The image you cloned is placed on the stack and utilized. Setting a type of bilevel is persisted as it is popped from the stack following the right paren, ")". The analog is colorspace. For example, if you set a CMYK image colorspace to sRGB within parens, it will persist as sRGB outside the parens.
Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output
Posted: 2019-09-08T18:52:55-07:00
by fmw42
OK. Thanks for the clarification.