[Insight-users] Managing conversion of pixel types during file read

[Zachary Pincus]

Luis,

As far as I can tell, once I have read in an image, there is no way to 
learn what the original dynamic range of the image *type* was. 
Basically, the idea is that I want to read in heterogeneous image 
types, and then compress the dynamic range of that *type*, whatever it 
is, to [0, 1].

Specifically, the steps for this are:
Read in an image that's stored on disk as k bits per pixel
Convert it to a float
Rescale the range [0, 2^k - 1] to [0, 1]

So, to use the RescaleIntensityImageFilter, I would have to have access 
to the original value for k, which as far as I can tell, only the 
ImageFileReader has.

I mostly deal with 8-bit and 16-bit (unsigned) images. If I were to 
just read them all in as 16-bit images, then I can't figure out how I 
would then tell which images started out as 8-bit images (and then I 
would use the RescaleIntensityImageFilter to rescale [0, 255] to [0, 
1]) and which images started out as 16-bit images (for which I would 
transform [0, 65536] to [0, 1]).

It's easy to find the range of an image, but finding out whether an 
image with values in the range [5, 230] (say) was originally an 8-bit 
image, or just a very dim 16-bit image, seems more difficult.

If this is possible without passing a customConvertPixelTraits class to 
the ImageFileReader, I would be most happy.

Thanks,

Zach

On Apr 15, 2004, at 9:46 AM, Luis Ibanez wrote:

>
> Hi Zach,
>
> Is there any particular reason why you don't want
> to use a RescaleIntensityImageFilter connected to
> the output of your reader ?
>
> This filter will do both the scaling and the type
> casting for you.
>
> Please let us know,
>
>
>   Thanks
>
>
>     Luis
>
>
> ---------------------
> Zachary Pincus wrote:
>
>> Hmm, after looking at DefaultConvertPixelTraits and 
>> ConvertPixelBuffer, I am not convinced that it is possible to create 
>> a input-type savvy ConvertPixelTraits.
>> While the documentation for DefaultConvertPixelTraits states:
>>> This implementaion, does a simple assignment operator, so if you are 
>>> going from from a higher bit representation to a lower bit one (int 
>>> to char), you may want to specialize and add some sort of transfer 
>>> function.
>> there does not seem to be any way to do this. For example, in the 
>> ConvertGrayToGray method of ConvertPixelBuffer, this gets called:
>> OutputConvertTraits
>>       ::SetNthComponent(0, *outputData++,
>>                         static_cast<OutputComponentType>
>>                         (*inputData));
>> Note the static_cast. So if you wanted to write a ConvertPixelTraits 
>> class that was savvy about, say, converting ints to chars (as per the 
>> documentation), you're out of luck because this conversion was 
>> already done in the static_cast in ConvertPixelBuffer. (I think.)
>> So it seems that you would really have to write a new version of 
>> ConvertPixelBuffer that was smart about transforming pixel types 
>> between each other. OK, this is a bit more of a pain than just 
>> writing a new ConvertPixelTraits, but whatever. However, even this is 
>> not possible, because it only seems possible to provide an 
>> ImageFileReader with a new version of the ConvertPixelTraits, not of 
>> the ConvertPixelBuffer class.
>> This seems to be due to the fact that this matter *should* be 
>> accomplishable through ConvertPixelTraits, but at least to my eye, it 
>> is not.
>> Am I missing something fundamental here? Or is it not currently 
>> possible to add a specialized pixel transfer function to an 
>> ImageFileReader?
>> Thanks,
>> Zach
>> On Apr 14, 2004, at 4:03 PM, Zachary Pincus wrote:
>>> Hello,
>>>
>>> My plan is to convert images I read in (initially in heterogeneous 
>>> pixel types) to floating-point pixels. I intend to rescale each 
>>> image such that the dynamic range of the image type (e.g. 8 bits, 16 
>>> bits) is compressed to the floating-point range [0, 1].
>>>
>>> That is, I don't mean to "normalize" each image I read in so that 
>>> [image.min_value, image.max_value] goes to [0, 1], but to convert 
>>> [ImageType.min_possible_value, ImageType.max_possible_value] to [0, 
>>> 1]. (If you follow my abused notation!)
>>>
>>> Is there any simple way to do this in ITK now? I could write a new 
>>> version of DefaultConvertPixelTraits for use with the FileReaders, 
>>> but (a) I don't quite know what all needs to go into this, and (b) 
>>> if there's an easy way already, I should use that.
>>>
>>> Thanks,
>>> Zach Pincus
>>>
>>>
>>> Department of Biochemistry and Program in Biomedical Informatics
>>> Stanford University School of Medicine
>>>
>>> _______________________________________________
>>> Insight-users mailing list
>>> Insight-users at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
>
>