Potential bugs/enhancements related to icc profile use

[miket]

Hi,

I'm using Perl Magick IM V7.0.5-3 Q16 x86_64.

I've been playing around with icc profiles and have come across a couple of potential bugs/enhancement requests.

I'm not sure if it's protocol here to separate out each issue (let me know if it is), but have grouped them together into this single post.

Issue 1

Converting an icc profiled RGB image to an icc profiled XYX image (using ->Profile(name=>$XYZ_profile). Works as expected. However if I further convert the resultant XYZ file to xyY (using $image->Colorspace(colorspace=>"xyY") the results are (visually) incorrect. Stripping the icc XYZ profile from the image (using $image->Profile(profile=>'');) prior to the XYZ to xyY conversion resolves the issue, so it would appear that an embedded icc profile is adversely affecting the XYZ to xyY transformation.

I'll happily provide code and the profiles I'm using if necessary.

Issue 2

When stripping out the icc profile ( $image->Profile(profile=>'');) the icc profile is properly removed, however the other icc tags embedded with the original profile (eg icc:copyright; icc:manufacturer, etc) remain in the file. Whilst this is not a significant issue, it would be much neater if the icc:* tags could be removed along with the actual profile. Alternatively is there a form of command that would effectively strip out all the icc:* tags (but RETAIN the other tags)? Although I have not verified it, my concern is that converting with a new profile which does NOT contain all the icc tags from the original profile, may result in a mix of old AND new tags if the old tags are not properly removed.

Issue 3

When using Elle Stone's nice and tidy ICC profile set (ACES & XYZ) http://ninedegreesbelow.com/photography ... files.html I'm getting very strange results when converting (with profile) from ACES to XYZ, where the resultant XYZ file has Y values of approximately half of those expected. An e-mail conversation with Elle resulted in her checking her profile with the developer at lcms. They seem confident that the profile is correct. Could it be an issue with IM?

If I take Lindbloom's "RGB16Million" file (containing all possible 16bit RGB values) and assign the ACES-elle-V4-g10 profile to the file then convert to XYZ using the XYZ-D50-Identity-elle-V4 profile, the resulting file has Y values approx 50% of the maximum.

In perl magic the commands are as follows:

Code: Select all

 $image->Profile(name=>$path."ACES-elle-V4-g10.icc");	# Apply ACES profile
    $image->Set(colorspace=>"RGB");
    $image->Profile(name=>$path.'XYZ-D50-Identity-elle-V4.icc'); # Convert to XYZ
    $image->Set(colorspace=>"XYZ");
    $image->Identify();

Identify output of the resultant image is:

Code: Select all

Channel statistics:
    Pixels: 16777216
    Channel 0:
      min: 0 (0)
      max: 127.899 (0.501564)
      mean: 61.4965 (0.241163)
      standard deviation: 36.5982 (0.143522)
      kurtosis: -1.20165
      skewness: 0.00430123
      entropy: 0.9943
    Channel 1:
      min: 0 (0)
      max: 138.265 (0.542214)
      mean: 63.7651 (0.250059)
      standard deviation: 29.9909 (0.117611)
      kurtosis: -0.808677
      skewness: 0.00537519
      entropy: 0.984357
    Channel 2:
      min: 0 (0)
      max: 105.525 (0.413825)
      mean: 52.5888 (0.206231)
      standard deviation: 30.2774 (0.118735)
      kurtosis: -1.19983
      skewness: 4.67264e-05
      entropy: 0.999351

Running a round trip ACES->XYZ->ACES does correctly give input = output.

If I use the D50_XYZ profile from the icc website I do get "correct" luminance values. (I have to set colorspace to RGB to correctly use that profile).


As ever, happy to provide any further information if necessary.

Regards

Mike

[snibgo]

Thanks for the link to the excellent http://ninedegreesbelow.com/ . I had forgotten about that site.

In my notes below, I use IM's options for the command line. Sorry, I don't use perl.


Issue 1: I suggest that colorspace conversion should be done either with profiles, or the simpler "-colorspace" command, but not both. If the two systems are mixed, care must be taken.

"-colorspace" is simple arithmetic process that ignores embedded profiles. "-profile" is more complex, involving curves etc. If the image contains an embedded profile, then "-profile" must be used for correct results. If for some reason "-colorspace" is required, then I suggest the image is stripped of the profile and "-set colorspace ZZZ" is used, to ensure the metadata says the image is sRGB or XYZ or xyY or whatever it is.

The key issue here is that "-colorspace" ignores embedded profiles. It applies arithmetic to the pixels, but leaves the embedded profile alone, so that profile will no longer correctly describe the meaning of pixel values.


Issue 2: "+profile *" removes icc profiles, but leaves icc:copyright etc tags. That's true; I hadn't noticed that (probably because I normally use "-strip", which does remove tags). I've added a suggestion to the Developers forum: viewtopic.php?f=2&t=31627.


Issue 3: Can you provide a link to Lindbloom's "RGB16Million" file?

Your statement that "the resultant XYZ file has Y values of approximately half of those expected" may be correct, but I don't know how to test it.

[miket]

Thanks Snibgo,

On Issue one - your response was my understanding as well. However I am getting DIFFERENT output results when using the perl equivalent of -colorspace when the same file has an icc profile and when it does not have an icc profile. You would expect the result to be the same, but they are not. (This took me some time to track down !!)

Issue 2 - Thanks for forwarding the suggestion. I think it would be much tidier if IM did this. (Unfortunately -strip is too sever for my particular application - i.e. gets rid of too many other tags)

Issue 3 - Link to Bruce's file is here : http://www.brucelindbloom.com/index.htm ... atrix.html I've only had the issue with Elle's XYZ profile here: https://github.com/ellelstone/elles_icc_profiles

If you use dcraw, then Elle has a fantastic commentary on the innards of that program hidden away here : http://ninedegreesbelow.com/photography ... tated.html. I found it really enlightening reading.

[snibgo]

However I am getting DIFFERENT output results when using the perl equivalent of -colorspace when the same file has an icc profile and when it does not have an icc profile. You would expect the result to be the same, but they are not.

As far as I know, "-colorspace" uses metadata that says what the current colorspace is, but ignores any profiles. For example, these two commands give the same pixel values:

Code: Select all

convert xc:rgb(10%,20%,30%) -colorspace HCL txt:
convert xc:rgb(10%,20%,30%) -profile D50_XYZ.icc -colorspace HCL txt:

Code: Select all

# ImageMagick pixel enumeration: 1,1,65535,hcl
0,0: (38229,13107,11898)  #955533332E7A  hcl(210,20%,18%)

The results would look different, because one has an embedded profile.

So, they are the same (they have the same pixel values) but they look different.



Regarding issue 3:

I meant specifically Lindbloom's "RGB16Million" file. I have now found it, at http://www.brucelindbloom.com/index.htm ... llion.html . IM can make a similar chart with all the colours:

Code: Select all

convert hald:16 h.png

I've done some experiments.I make an image with one pixel, and convert it to XYZ, first with "-colorspace" then with "-profile".

f:\web\im>c:\im\ImageMagick-6.9.5-3-Q16\convert xc:rgb(10%,20%,30%) -colorspace XYZ txt:
# ImageMagick pixel enumeration: 1,1,65535,xyz
0,0: (1913,2038,4833) #077907F612E1 xyz(3%,3%,7%)

f:\web\im>c:\im\ImageMagick-6.9.5-3-Q16\convert xc:rgb(10%,20%,30%) -profile sRGB.icc -profile XYZ-D50-Identity-elle-V4.icc txt:
# ImageMagick pixel enumeration: 1,1,65535,xyz
0,0: (750,820,1773) #02EE033406ED xyz(1%,1%,3%)


I observe that the values in all three channels are roughly halved, in the profile case compared to the "-colorspace" case.

I don't know how XYZ-D50-Identity-elle-V4.icc differs from a conventional XYZ profile.

Using another XYZ profile I have on my computer:


f:\web\im>c:\im\ImageMagick-6.9.5-3-Q16\convert xc:rgb(10%,20%,30%) -profile sRGB.icc -profile D50_XYZ.icc txt:
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (1715,1862,3723) #06B307460E8B srgb(3%,3%,6%)

The values are closer to those we get from "-colorspace".

I don't know where I got D50_XYZ.icc from. I've uploaded it to http://snibgo.com/imforums/D50_XYZ.icc .

I conclude that D50_XYZ.icc gives a similar result to "-colorspace XYZ", but Elle's "identity" icc gives values that are about 50% lower in all three XYZ channels.



I test the round-trips:

f:\web\im>c:\im\ImageMagick-6.9.5-3-Q16\convert xc:rgb(10%,20%,30%) -colorspace XYZ -colorspace sRGB txt:
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (6554,13108,19662) #199A33344CCE srgb(10%,20%,30%)

f:\web\im>c:\im\ImageMagick-6.9.5-3-Q16\convert xc:rgb(10%,20%,30%) -profile sRGB.icc -profile XYZ-D50-Identity-elle-V4.icc -profile sRGB.icc txt:
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (7079,12146,20307) #1BA72F724F53 srgb(11%,19%,31%)

f:\web\im>c:\im\ImageMagick-6.9.5-3-Q16\convert xc:rgb(10%,20%,30%) -profile sRGB.icc -profile D50_XYZ.icc -profile sRGB.icc txt:
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (7456,13557,20078) #1D2034F54E6E srgb(11%,21%,31%)

The "-colorspace" round-trip is 100% accurate. The "-profile" round-trips are approximately correct.


Re dcraw: Ah, yes, I read Elle's commentary some years ago, when I was considering ripping dcraw apart to make it do some other stuff. That was yet another project that got pushed to the back of the queue.