Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

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.
Post Reply
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

Post by fmw42 » 2019-09-01T15:49:24-07:00

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:
Image

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
Image



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
Image

The only difference is the output format JPG vs PNG

snibgo
Posts: 12157
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

Post by snibgo » 2019-09-02T17:53:49-07:00

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.
snibgo's IM pages: im.snibgo.com

User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

Post by fmw42 » 2019-09-02T19:37:33-07:00

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.

User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

Post by magick » 2019-09-08T07:58:14-07:00

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

User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

Post by fmw42 » 2019-09-08T10:21:27-07:00

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?

User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

Post by magick » 2019-09-08T17:32:27-07:00

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.

User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Possible bug IM 7.0.8.63 Q16 Mac OSX with JPG output

Post by fmw42 » 2019-09-08T18:52:55-07:00

OK. Thanks for the clarification.

Post Reply