Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
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:
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.
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:
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?
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.