Clarification on use of colours and depth in IM

[aigo]

Hi all,

I have been playing around with IM recently especially with the color and depth option, and interestingly have discovered some things I can't explain but are important.

1. When specifying number of colors to use in an image say 4, I have discovered that the number of colors represented on the resultant image is always more than the specified number.

2. Using the same number of depth but reducing number of colors in several images, a particular characteristic has struck out. Which is that initially, image sizes reduce with reducing number of colours then at some point (color number value) increases then continues reducing.

Any suggestions and advice will be highly appreciated.

Thanks!

Aigo

[snibgo]

Do we have to guess what commands you are using? And your version of IM?

[aigo]

Oh so sorry..

I am using convert <input image> -colors <value> -colorspace RGB -normalize -depth <depth value> <output image>.

IM version 7.0.6-0 Q16

[snibgo]

You are reducing the number of colours, then manipulating the image. When are you counting the colours? I suppose after the command is finished, after you have manipulated the image, and saved it. Presumably not as JPEG, because that will change colours?

[aigo]

no as .png..and yeah I count colours after the manipulation.

[snibgo]

Your manipulations can change the number of unique colours. "-format %k\n +write info:" counts the colours at that stage in the processing.

For example:

Code: Select all

magick rose: -format %k\n +write info: -colorspace RGB -format %k\n +write info: NULL:
3019
3019

Code: Select all

magick rose: -format %k\n +write info: -normalize -format %k\n +write info: NULL:
3019
3015

Code: Select all

magick rose: -format %k\n +write info: -colorspace RGB -normalize -format %k\n +write info: NULL:
3019
766

I wouldn't expect "-colorspace RGB -normalize" to increase the number of colors.

[aigo]

Hi snibgo, thank you so much for this suggested approach...I also noticed -depth applied just after -normalize affects (reduces) the number of colours as well. -resize actually increases the number of colours exponentially..

I just wonder if there is any scientific reason for this behaviour?

Also, is there a way I can write multiple outputs as stated above into a data structure e.g a list, for further experimentation? The method I have now is overwriting previous values.

Thanks in anticipation.
Aigo!

[snibgo]

"-depth 8" reduces precision. Pixels that have colours very similar to each other in 16-bit precision may be identical when precision is lowered. (Like "123" and "124" are different when using three [EDIT: I wrote "two" but meant "three"] significant digits, but identical when rounded to two significant digits.)

Output pixels from "-resize" are calculated as a complex mixture of input pixels. For example, if the image has only two pixels, one red and one blue, and we resize to three pixels, the middle pixel will be between red and blue.

Code: Select all

f:\web\im>%IM%convert xc:red xc:blue +append -resize "3x1^!" txt:
# ImageMagick pixel enumeration: 3,1,65535,srgb
0,0: (65535,0,0)  #FFFF00000000  red
1,0: (32768,0,32768)  #800000008000  srgb(50%,0%,50%)
2,0: (0,0,65535)  #00000000FFFF  blue

Text output goes to stdout, so you can redirect to a file or whatever you want, or save as environment variables in Windows or bash.

[aigo]

Thank you snibgo,

I truly appreciate your feedback, kindly consider the following questions:

Based on your explanation of -resize, we can also say that when an image has 100x100 pixels and is resized to 50x50, an approximation of the original image colours is performed where similar colours could end up being represented with same colour. But this contradicts the exponential increase in number of colours when an image is resized by say up to 20% of its original size.

when you say -depth '8'.. is 8 the number of bits used to represent the image or (2^8) bits.

Also, is there a way to view the size of the image incrementally like you did for the number of unique colours above, when I try it (%b) I get 0B.

Thanks in anticipation.

Aigo!

[snibgo]

I've corrected a typo in my previous post.

Any "-resize" involves mixing pixels. Any mixing of pixels will change the list of unique colours, so the number might go up or down.

If we have an 100x100 image with every pixel different, so we have 10,000 unique colours, then any resize down (ie subsampling) will reduce the number of unique colours because there can't be more colours than there are pixels.

As a test image, I often use toes.png:

This has 62211 pixels with 62206 unique colours. I've tried a few resize downs, and they all decrease the number of unique colours.

"-depth 8" refers to the number of bits per channel per pixel. If there are 3 channels (for R, G and B) we have a total of 24 bits per pixel. I mostly use "-depth 16", but some work needs "-depth 32".

"-format %b" gives the size of the file, in bytes, that was read in, for example:

Code: Select all

convert toes.png -format %b\n info:
320KB

It doesn't tell you what the size would be if you saved the image. After you have changed the image, the number isn't available.

Code: Select all

f:\web\im>%IM%convert toes.png -resize 50% -format %b\n info:
0B

But you can write the image, delete it from memory, and re-read it:

Code: Select all

f:\web\im>%IM%convert toes.png -resize 50% -write x.png +delete x.png -format %b\n info:
84.7KB

[aigo]

Hi snibgo,
Thank you so much for your clear explanations...
Aigo!

[glennrp]

Use -sample instead of -resize if you don't want to add interpolated colors.

[aigo]

Use -sample instead of -resize if you don't want to add interpolated colors.

Thanks so much..that works!

Is there any reason why resize behaves this way? Like a scientific reason?

Thanks!

Aigo