Legacy ImageMagick Discussions Archive

Hi all,

my problem is the following: I have to check within 10bit DPX files if the image content had gone through an 8bit bottleneck before.

bitdepth (identify -format %z filename) will tell me that my DPX file is a 10bit container and identify -format %k filename would give me the number of unique colors within this picture. 8bit pictures should have about 1/4th of the number of unique colors compared to 10bit.

But only by using my rusty brain I can somehow say it looks like an 8bit content if the number of unique colors is below a certain level when looking on the actual image and making a guess on how many colors there probably should be...

So my initial thought was that when only 8bit content is packed into the 10bit container it would look like in the following table. In 8bit content 3 out of 4 successive codevalues should be zero and only one "real" value would be present. This of course only would be true if no "smoothing" has been applied in the 8 to 10bit pipeline.

Another thought was to use histogram:histogram.gif to plot a histogram. I hoped to find "gaps" in the plots of the 8bit images. Unfortunately both histograms for true 10bit and 8bit look exactly the same...

Any ideas would be most welcome!

Thanks, Andreas

I would probably try look though the interger color values as see what pattern the 9th and 10th significant bit forms.

That is color in the this range always has a 9 and 10 bit pattern of XX

typically XX will either be 00, or will match the highest two bits of the color.
Whcih it is depends on the algorithm used to map the color from 8 bit to 10 bit.
But if for a special range the pattern does not vary much, then you can be sure it once had a lowerer bit depth.

Dear Anthony,

thanks for the fast reply. I guess I somehow understand what you mean but can you give me a clue if this can be done with ImageMagick?

Thanks, Andreas

I think it would be best done with a program that can go though the raw (16bit) pixels of the image loaded in IM.
Perhaps like the example 'MagickCore' or 'MagickWand' page. Or even the example "pixel_fx.pl" PerlMagick demo program. Basically just about any API will have a example that can be modified to use.

On the CLI the equivalent is -fx But you don't have any 'state' to record findings, and the value are provided as normalized floating point values, where really you need access to the raw values. That is why I recommend one of the many other API's.

Thanks again Anthony will give it a try.

On a slightly different topic: when I "histogram" a 10bit (DPX) image with the resulting GIF is 256x100 pixels. I would have expected a width of 1024 having one pixel per every possible codevalue. Am I doing something wrong? Using ImageMagick 6.6.6-5 2010-12-12 Q16 http://www.imagemagick.org on Windows.

Thanks, Andreas

aberkl wrote:Thanks again Anthony will give it a try.

On a slightly different topic: when I "histogram" a 10bit (DPX) image with

Code: Select all

convert orig10bit.dpx -define histogram:unique-colors=false histogram:orig10bit.dpx_h.gif

the resulting GIF is 256x100 pixels. I would have expected a width of 1024 having one pixel per every possible codevalue. Am I doing something wrong? Using ImageMagick 6.6.6-5 2010-12-12 Q16 http://www.imagemagick.org on Windows.

Thanks, Andreas

Actually it used to be 256x200 pixels for a long time. It suddenly changed on me too!

I would like to see some image processing operators for generating histograms and other plots based on image data of any size, but that is on a long list of 'wishes, wants and desires;

But what you probably want is NOT the image, but the text comment from histogram, which should list all the colors and their counts.

Anthony,

anthony wrote:I would like to see some image processing operators for generating histograms and other plots based on image data of any size, but that is on a long list of 'wishes, wants and desires; :-(

But at least you are not alone :)

But what you probably want is NOT the image, but the text comment from histogram, which should list all the colors and their counts.

Actually I tried the text output but would still be in favour of the histogram image.


10bit original


8bit "bottlenecked" version, same histogram :(


same image but reduced to a total of 256 color, notice the dramatic gaps

I guess if all of the histograms would be full "resolution" of 1024 pixels (or whatever the depth higher than 8bit is) I could see missing codevalues in the 8bit "bottlenecked" version.

Do I understand you correctly that this is not possible? Seems not to make too many sense when running a quantum 16 not to use the higher bitdepths for the histograms. Well normally you are only interested in the overall distribution of levels and then the reduced "resolution" of the histogram doesn´t really matter...

But thanks anyway for your help and have a good one!
Andreas

I thought you were taking about reducing images from 10bit to 8bit not reducing number of colors.

The histogram distribution of colorvalues in a heavilly color reduced image really does not have a great deal of bearing. The individual values become less important that the color as a whole for each pixel.

Also part of color reduction is the dithering of the new colors to replace old colors in the image. WIth a good dithering technique the overall color of a small area of the image becomes a merger of neighbouring colors. That means actual image color is not the color of individual pixels!

What is important in a color reduction is the distribution of colors (not values) in the color space.



It is my thinking about the as to why I created a script 'hsl_named_colors" a few days ago.
See result of that script in Color Basics, Color Names.

The script purpose was not to actual get a map of all the named colors, in a restricted form of HSL colorspace, but eventually so I can get a idea of the distribution of colors in a 3-Dimensional color space. The new script will eventually be modified to create a animated rotating view of the colors of a colormap, so I can see the distribution of colors and any 'artifacts' that may be present.

That next step however needs some Vector Maths, and that would probably involve a Perl Module I wrote a few years back Perl::VectorReal to maps the location of the colors.

Anthony,

anthony wrote:I thought you were taking about reducing images from 10bit to 8bit not reducing number of colors.

no, that´s a misunderstanding. The question is: is the image content of the 10bit DPX really 10bit or only 8bit?

In the meantime I found something which might probably work for me, will have to do more tests:
If both numbers for original and 8bit-version are identical I assume that the image content of orig.dpx was nothing more than 8bit. If # of colors for orig.dpx is significantly higher than for 2test.dpx then orig.dpx is "true" 10bit.

At least when using IM only for tests it works :-)

Best, Andreas

Nice solution!

I was thinking a little too low level