Color space conversions to/from XYZ...

I have just started writing a plug-in in which I need to convert data from an RGB space to XYZ and back again. For this I am using the sPSColorSpace-%26gt;Convert16 function.



Unfortunately, it seems that the conversions to and from XYZ are not performed correctly. I do not know exactly what *is* calculated, but XYZ it's not. One of the giveaways is that the result of the conversion depends on the color space of the RGB data, including the gamma. Instead, the XYZ values should be uniquely defined, independent of the source RGB space.



I have since created a work-around, by using the sPSColorSpace-%26gt;Convert16 function to convert RGB values to Lab, and converting those to XYZ and back again with my own code. In this way, everything works as expected. However, it's unsatisfactory for two reasons: (1) a basic SDK function seems to be broken, and (2) my workaround is very slow, introducing 4(!) redundant nonlinear transforms per pixel.



Does anyone have similar or contrary experiences? And, assuming I haven't messed up, how should one go about notifying Adobe about this? Thanks in advance!



Simon
Color space conversions to/from XYZ...
%26gt; One of the giveaways is that the result of the conversion depends on the color space of the RGB data, including the gamma.

%26gt; Instead, the XYZ values should be uniquely defined, independent of the source RGB space.



No, that isn't the case. What makes you think that RGB -%26gt; XYZ is a

profile independent conversion? XYZ is a device independent color

space, not a transformation of RGB (like HSB).



Aandi Inston
Color space conversions to/from XYZ...
%26gt;XYZ is a device independent color space, not a transformation of RGB (like HSB).



That is exactly what I meant. Sorry for expressing myself poorly.



The test I did was as follows. I applied my filter as a smart filter to an RGB smart object. I then *converted* (not assigned) the RGB object to another color space using a relative colorimetric conversion. Because my filter operates in the XYZ space, the (visual) output should be unaffected by the color space conversion. Unfortunately, the output changed.



When I changed my filter to use Convert16 to convert to Lab (instead of XYZ) and back, and manually performed the Lab%26lt;-%26gt;XYZ conversion, the (visual) output was indeed independent of the source color space.



My conclusion is that XYZ as calculated by the Convert16 function *is* a 'transformation of RGB', but, you are correct, it shouldn't be. The conversion does not properly account for the source RGB space.



Simon

Anyone else? Or shall I try to file a bug report?



Simon

Bug reports are good but they are completely passive (a way of

reporting bugs, not a way to get replies or help).



My next step would be to purchase an ASN case.



Aandi Inston

Aandi, thank you for responding. I agree that bug reports are very passive - especially so with Adobe. The existence of a separate developer network probably amplifies this effect.



However, I am writing a freeware plugin, and I am doing this in my spare time. Plus, I have found a working, albeit slow, workaround. Therefore, I don't think it's worth the hassle or the money to become an ASN member.



So, a bug report will have to do. I presume the Photoshop team is at least interested in fixing this - maybe when they add 32-bit support to their color space conversion code for CS4...



Simon

Today I returned to this problem and did a few more tests. I guess I figured out what is happening.



It turns out that sPSColorSpace-%26gt;Convert16 and Convert8 throw a 'Parm' (bad parameter) error when asked to convert to or from the XYZ color space (plugIncolorServicesXYZSpace). The result is that the data remains untouched, (obviously) leading to very strange results. Converting to and from other color spaces, including HSB/HSL/Lab, works fine.



In other words, XYZ color space conversions appear to be unsupported, even though the documentation suggests otherwise. It seems strange to consciously make an exception for XYZ, especially because XYZ conversions are essentially free once Lab conversions are implemented. Could it be a bug?



Simon

OK, I recieved a response from Adobe after filing my bug report/feature request. They confirmed that XYZ conversions are currently not supported (by design), and that the SDK documentation is ambiguous in this regard and may be updated.