[Insight-developers] Improving support for color in ITK

[Bradley Lowekamp]

Hello Dan,

It is good to hear that other people are trying to use ITK for color  
images. Some time I think I am about the only one doing it. Getting  
ITK to support color spaces and color management is a good size effort  
that may be well work it. There are  many things that need to be  
considered to have a robust design. I am not an expert in this area,  
but I have some experience and I have been trying to expand my  
knowledge.

Currently I have been doing all my color management outside of ITK.  
That is I am using Photoshop and Matlab to batch convert different  
color spaces, then in my programs sometime I'll load up 2 or three  
different images each with a different space to perform a task. As I  
believe you intended to suggest I load the images as itk::Images of  
vectors.


>
>
> All this has left me somewhat confused. So I guess my big question is:
> should I stay with the "simple" approach taken by VTK, which --
> although not the whole truth -- seems adequate? Or should I aim for a
> more "complete" solution, with support for non-linear color spaces
> (eg. sRGB), white point specification, etc?
>
> Brad: From a recent post to the users list, you seem knowledgeable on
> this topic. Perhaps you have some advice?
>     http://www.itk.org/pipermail/insight-users/2009-July/031394.html
>

I would think that the full color management solution would be much  
better for ITK, since we do images. But this is likely too much work  
and well beyond the needs of your application.

But this may be easier then first thought. May operating systems have  
build in color management systems. I have not programmed with these,  
but I do wonder if they could meet some of these requirements. Also,  
are there existing libraries that could meet our needs?

The biggest problem with using the "simple" approach, is that it makes  
assumptions about the incoming color space. Consider, that e-mail  
referenced above. There are two different formulations to calculate  
luminance currently in ITK. They make different assumptions about the  
RGB space, and it not at all clear what those assumptions are. In the  
end, they are just very rough approximations, and not accurate.


This first problem to address is that we don't know what color space  
an image is in. Mathieu Malaterre pointed out some specific examples  
from DICOM. But in general this is frequently embedded in image type,  
like Tiff and jpeg with sRGB or Adobe RGB(1998). I believe many of the  
CIE spaces can be embedded as well. This should be able to be done  
with the MetaData that is associated with an image. However,
	
	The Image's MetaData is currently not copied with filters.
	It could be implemented as part of the GenerateOutputInformation, and  
carried along the pipeline.


With that information you can have intelligent filters which  
manipulate color in a predictable and managed way.

So I agree that you should not create a custom pixel type for each  
color space.

Brad

> The advantage of using vectors to hold the color images is that no new
> pixel types (or traits) need to be added/maintained. The disadvantage
> is that the user now needs to be careful which color components are
> currently held by the vector. For example pixel.GetElement( 0 ) may
> return R(GB), L*(a*b*), X(YZ), or H(SV). Do you feel this is too
> confusing?
>
> Sorry for the long email. Thanks for any advice.
>
> Regards, Dan

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090728/3a14322c/attachment.htm>