possible bug reporting LAB colors as pixel: values

[jwtrexler]

Thank you Snibgo. I did try using your suggestion, but the -depth script would not convert the jpeg file from 8 to 16 bit. I did however convert the jpeg file to a tiff file and was able to utilize the -depth script to convert the 8 bit file to a 16 bit file. The tiff 16 bit file could then be converted to Cielab colorspace utilizing the -colorspace script and written to a txt file for importing into Excel.

As you are aware, the output of the "-colorspace lab" script provides not only the pixel x,y coordinate and respective L*, a* and b* percentage values, but also comprises other information including characters, numbers, and symbols on each line corresponding to that pixel. Rather than importing the txt file into Excel to parse and delete the excess information reported for each pixel, and subsequently utilizing Excel to convert the three color values in the IM txt file from percentage values to their respective "true" values (e.g., a L* range of 0 to 100 and an a* and b* range of -100 to +100), can you make a suggestion as to how to have ImageMagick output a text having only the pixel xy coordinates and their respective "true" L*, a* and b* values, preferably in a table format where the results can be plotted (e.g., in a histogram form to look at the variability in the three colorspace values. My goal is to utilize digital pictures camera rather than a colorimeter, which measures a small percent of total area, to monitor the consistency colored parts. Likewise, if IM cannot do the last couple steps (i.e., generate a tabulated format that can be viewed in a statistical graphics form) or you are aware of another program better suited for what I am trying to achieve, and/or you are aware of a reference that can aid me in achieving my objective, I would greatly appreciate you thoughts.

Jack

[snibgo]

Given that you want to find L*a*b* values for a patch within an image, a number of possible approaches:

1. Crop to the containing rectangle. If the required patch isn't rectangular, use alpha to define it.

2. Convert to Lab. (If you have alpha, this gives you 4 channels. Two of these are called "a". That's okay; just refer to them as R, G, B and A.)

3. Maybe you just want the mean for the LAB channels of the area. Use "-filter Box -resize 1x1!". This will ignore pixels that have alpha=0.

4. If you want all the pixel values, to throw at a spreadsheet to get std-dev etc, you could use "-format" to do the calculating. IM doesn't (as far as I know) have a mechanism to define your own "txt:" format. So you would have to use "pixel:" within "-format", and script a loop. The loop might run "convert" once per pixel (yuck!) or the script would create a single convert command with one "pixel:" per pixel. That would be fairly fast but very ugly.

5. So I don't think you can sensibly get IM to output a CSV file of L*a*b values, scaled to (0..100,-100..+100,-100..+100). Instead, you could dump the raw pixel values (0..65535) either as txt: format, or one of the ppm formats. (For ppm, "-compress none" gives you text; otherwise it is binary.) Do the scaling in a script or compiled program. If your patches are large or you want to do this often, binary ppm and a compiled program seems the way to go.


Reading between the lines of your post, perhaps you have a Macbeth colour chart or similar in a range of photos, and the goal is to ensure colour balance. Then we don't care about the individual pixels or variation within each patch; the mean of each patch is enough data. So then we have:

A. Use IM in a script to find each colour patch and find the average RGB values of each patch. Do this for a known-good reference photo, and for a second photo. With the photos as the X-Y axes, plot these graphically. (For extra bonus points, use IM to plot the graphs.)

B. The primary shift may be in colour temperature, ie red-blue, a mired shift, often modelled by multiplying red by a factor and dividing blue by the same factor. See my page on Colour Temperature (which I haven't really finished). A rich colour chart will give you plenty of samples.

C. With luck, the RGB lines are straight, and intersect at (0,0). So to make the second photo match the reference, you just need to multiply channels, but you still need to worry about clipping. (See my page.) If the situation is more complex, you might:

C1. Use linear regression to find straight-line approximations, or model the curves eg with splines, or:

C2. Match the histograms. This involves making a clut that is an inverted cumulative histogram applied to the other cumulative histogram. Fred has a script for this, called histmatch. I also have a script, on my Clut Cookbook, and was really chuffed to figure out how to invert a clut/histogram using IM without external calculations. For 16-bit cluts this sadly needs 70 GB of memory. This process is really easy to use: just crop the colour chart from each photo, throw these crops at the script, and the script gives you the clut file to transform from one to the other.

C3. I haven't done this process in L*a*b* space. I don't know if that would work better.


Sorry, this was a bit of a brain dump. Hope it is useful.