possible bug with -colors or some other function IM 6.4.3-5

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 with -colors or some other function IM 6.4.3-5

Post by fmw42 »

IM 6.4.3-5 Q16 Mac OSX Tiger

I am having a problem with one method for identifying all pixels of a given color:


Consider the following histogram:
convert rose: -colors 256 -format %c histogram:info:

which has the following entry:
6: (138,168,119) #8AA877 rgb(138,168,119)

The following works:
convert rose: -colors 256 rose256.gif
color="rgb(138,168,119)"
convert rose256.gif -fx "u==$color?debug(u):1; u" null: 2>&1


But the following does not work:
color="rgb(138,168,119)"
convert rose: -colors 256 -fx "u==$color?debug(u):1; u" null: 2>&1


Am I misunderstanding something here?
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: possible bug with -colors or some other function IM 6.4.3-5

Post by magick »

GIF's are saved as 8-bit where as color reduction operates in 16-bits. To get the desired results you need to add -depth 8 to your command line, however, a patch is required. You can get it from the subversion trunk or wait a few days for the next point release.
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug with -colors or some other function IM 6.4.3-5

Post by fmw42 »

magick wrote:GIF's are saved as 9-bit where as color reduction operates in 16-bits. To get the desired results you need to add -depth 8 to your command line, however, a patch is required. You can get it from the subversion trunk or wait a few days for the next point release.

OK I can understand if -depth 8 is required (makes sense now that you mention it) as in:

convert rose: -colors 256 -depth 8 -fx "u==$color?debug(u):1; u" null: 2>&1

Thanks for the patch --- I can wait.

but for my understanding why is it not required in the generation of the histogram:

convert rose: -colors 256 -format %c histogram:info:

works without

convert rose: -colors 256 -depth 8 -format %c histogram:info:

Seems a bit inconsistent. Histogram knows it needs to be 8-bit? but what about 1024 bin histograms, they are not coming from an 8-bit image.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: possible bug with -colors or some other function IM 6.4.3-5

Post by magick »

Histogram values are scaled according to the image depth. Try setting the depth of your image to 16-bit and you should get 16-bit values.
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug with -colors or some other function IM 6.4.3-5

Post by fmw42 »

magick wrote:Histogram values are scaled according to the image depth. Try setting the depth of your image to 16-bit and you should get 16-bit values.
But why does this work without specifying -depth 8 on a Q16 system?

convert rose: -colors 256 -format %c histogram:info:

That is what seems puzzling. I can understand why the -fx command line needs -depth 8, but not why the above does not?

Sorry to belabor this. Just want to understand.

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

Re: possible bug with -colors or some other function IM 6.4.3-5

Post by magick »

The original image is 8-bits so its depth parameter is 8 and that is what the histogram uses. Internally the RGB values are 16-bits when you fire the -colors option but the image depth parameter remains at 8.
Post Reply