[SCIFIO] Error reading a 32-bit nrrd image via ITK

[Mark Hiner]

Hi Joe,

 I made my changes and pushed a new scifio-itk-bridge.jar. I didn't have to
change the C++ side at all, so all you should have to do is delete the
"scifio-itk-bridge-1.0.0.jar" in your local $ITK_BUILD/lib/jars, then clean
and rebuild the SCIFIO module (which should trigger a download of the
latest jar, but only if it's not already present in $ITK_BUILD/lib/jars).

 You can also manually
download<http://jenkins.imagej.net/view/SCIFIO/job/SCIFIOITKBridge/lastSuccessfulBuild/artifact/target/scifio-itk-bridge-1.0.0.jar>and
replace the jar if you don't want to rebuild everything.

 Let me know if you have any more problems, or if this fix doesn't work for
you.

Thanks,
Mark


On Wed, Oct 23, 2013 at 1:31 PM, Mark Hiner <hinerm at gmail.com> wrote:

> Hi Joe,
>
>  Just wanted to let you know I identified that this is an error with
> endianness not being handled correctly in the SCIFIO ImageIO.
>
>  I fixed it locally, but found some bugs with how indexed and RGB images
> are being handled along the way. Once I have those fixed I'll update the
> SCIFIO ImageIO module and let you know.
>
> Thank you for reporting this, and for using the SCIFIO-ITK imageIO!
>
> - Mark
>
> On Tue, Oct 15, 2013 at 3:21 PM, Joe Ping-Lin Hsiao <phsiao at cs.unc.edu>wrote:
>
>> Hi Mark,
>>
>> The output dimension is 3, which is equal to the input's dimension. I
>> also tried "-d 5". Seems to me it doesn't change anything of the output.
>> The output dimension is still 3 and the pixel values are wrong.
>>
>> Don't know if this helps. I put the following code after reader->Update()
>> to check the image's min and max pixel values:
>>
>> typedef itk::MinimumMaximumImageCalculator <ImageType>
>> ImageCalculatorFilterType;
>> ImageCalculatorFilterType::Pointer imageCalculatorFilter =
>> ImageCalculatorFilterType::New ();
>> imageCalculatorFilter->SetImage(reader->GetOutput());
>> imageCalculatorFilter->Compute();
>> cout << "max intensity " << imageCalculatorFilter->GetMaximum() << endl;
>> cout << "min intensity " << imageCalculatorFilter->GetMinimum();
>>
>> The value range is the full range of 'float' from -3.49e38 to 3.49e38,
>> which seems wrong. But if I comment out reader->SetImageIO(io), the values
>> look reasonable.
>>
>> Thanks,
>> Joe
>>
>>
>> On Tue, Oct 15, 2013 at 3:50 PM, Mark Hiner <hinerm at gmail.com> wrote:
>>
>>> Hi Joe,
>>>
>>>  Thanks for reporting this issue.
>>>
>>> reader->SetImageIO( io );
>>>>
>>>
>>>  Just so you know, this is just disabling SCIFIO I believe, and
>>> defaulting to the ITK DICOM ImageIO.
>>>
>>>  Does the output file have the correct number of total planes? If not,
>>> you might try "-d 5" just to test. The dimension order is XYCZT but XYZ are
>>> the dimensions with length more than 1. The SCIFIO plugin is supposed to
>>> account for that but it could be a bug.
>>>
>>>  Otherwise if the dimensions are correct it could be an issue with the
>>> dataset being interleaved.
>>>
>>>  I'll try to look at it soon.
>>>
>>> Thanks,
>>> Mark
>>>
>>>
>>>
>>> From: Joe Ping-Lin Hsiao <phsiao at cs.unc.edu>
>>>> To: scifio at scif.io
>>>> Cc:
>>>> Date: Tue, 15 Oct 2013 14:29:23 -0400
>>>> Subject: Error reading a 32-bit nrrd image via ITK
>>>> I am having trouble using SCIFIO in ITK to read a 32-bit .nrrd image in
>>>> my own program. The attached is a 32-bit 3-dimensional test image.
>>>>
>>>> Then I used the following command to test with the SCIFIO test program:
>>>>
>>>> SCIFIOTestDriver.exe itkSCIFIOImageIOTest sample_5.nrrd 123.ome.tiff -w
>>>> -d 3 -t float
>>>>
>>>> The output '123.ome.tiff' has wrong pixel values and looks wrong in
>>>> ImageJ.
>>>>
>>>> After I dig deeper, I found that in in 'itkSCIFIOImageIOTest.cxx', if I
>>>> comment out this line
>>>>
>>>>    reader->SetImageIO( io );
>>>>
>>>> to use ITK's default ImageIO, the output image becomes normal.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://scif.io/pipermail/scifio/attachments/20131023/58896f08/attachment-0002.html>