[Insight-users] Image reader problem

[Bill Lorensen]

Also, it is possible that your code has a problem elsewhere that has
only surfaced after switching to the new compiler. You could be
trashing memory somewhere.

Can you post a small test program that crashes? We could try to run it
through a memory checker like valgrind.

Bill

On Mon, May 5, 2008 at 6:13 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Hi Charles,
>
> Most ITK IO classes rely on the functionalities of std::streams.
>
> If you can use
>
>     * std::ifstream
>     * std::ofstream
>
> for managing your filenames (in Unicode) then most ITK IO classes
> should work fine as well.
>
> There are however several ImageIO classes that rely on third party
> libraries, (PNG, JPEG...) and for those we may have to check type
> by type.
>
>
> Could you let us know if you can (independently of ITK) read
> and write files using std::ifstream and std::ofstream when
> the filenames contain characters requiring a unicode
> representation ?
>
>
>   Please let us know what you find,
>
>
>      Thanks
>
>
>         Luis
>
>
> -----------------------
> Charles Knox wrote:
>>
>> Thanks Bill and Niels,
>>
>> I ran itkGDCMImageIOTest in debugging mode (after hard coding in some file
>> names) and it runs fine!  I can step into ITK code and see the file names
>> being saved.  Both ITK and my software are compiled using the _MBCS option
>> (multi-byte character strings), so I don't think it's a problem with
>> multi-byte characters, although am still looking at this.
>>
>> Does ITK support Unicode or MBCS?  I don't know.
>>
>> So, as of now, I'm stumped.
>> Regards,
>> Charlie
>>
>> Bill Lorensen wrote:
>>
>>> Charles,
>>>
>>> Do the tests in Insight/Testing/Code/IO run OK?
>>>
>>> We don't have any VS 9.0 platforms in our testing suite unfortunately.
>>>
>>> Bill
>>>
>>> On Mon, May 5, 2008 at 12:37 PM, Charles Knox <knoxcharles at qwest.net>
>>> wrote:
>>>
>>>>
>>>> The function ReadDICOMImage() gets called to test for/read a DICOM image
>>>> file.
>>>> It has worked consistently for me through ITK versions 1.x through 3.4
>>>> when
>>>> compiled
>>>> with MS Visual C++ 6.0.  But now, when compiling with MS Visual Studio
>>>> v9.0
>>>> for
>>>> x86 and under Windows Vista, the debugger traps an access violation from
>>>> the
>>>> destructor ~ImageSource() (located in file itkImageSource.h).
>>>>
>>>>
>>>> -----------------------------------------------------------------------------------
>>>>
>>>> BOOL CImageData::ReadDICOMImage( CString &csFileName, IMAGEPARAMS
>>>> &iParam )
>>>> {
>>>>   // First check for a DICOM file.
>>>>   itk::GDCMImageIO::Pointer gdcmIO = itk::GDCMImageIO::New();
>>>>
>>>>   // This works but commented out to get to 'reader'
>>>>   //if (!gdcmIO->CanReadFile((LPCTSTR)csFileName)
>>>>   //    return FALSE;
>>>>
>>>>   typedef signed short                PixelType;
>>>>   // Set dimensions to 3 to have reader return z-value
>>>>   const    UINT                    Dimension = 3;
>>>>   typedef itk::Image< PixelType, Dimension >    ImageType;
>>>>   typedef itk::ImageFileReader< ImageType >    ReaderType;
>>>>
>>>>   ReaderType::Pointer reader = ReaderType::New();
>>>>
>>>>   reader->SetFileName( (LPCTSTR)csFileName);
>>>>   reader->SetImageIO( gdcmIO );
>>>>
>>>>   // Return prematurely to invoke 'reader' destructor
>>>>   // when going out of scope.
>>>>   return FALSE;
>>>>
>>>>   try {
>>>>       reader->Update();
>>>>   } catch (std::exception &err) {
>>>>       string msg = err.what();
>>>>       AfxMessageBox(msg.c_str());
>>>>       return FALSE;
>>>>   }
>>>>
>>>> ...
>>>>
>>>> ---------------------------------------------------------------------------
>>>>
>>>> Debugger stops at the destructor ~ImageSource()
>>>>
>>>> ...
>>>>   * SmartPointer to a DataObject. If a subclass of ImageSource has
>>>>  * multiple outputs of different types, then that class must provide
>>>>  * an implementation of MakeOutput(). */
>>>>  virtual DataObjectPointer MakeOutput(unsigned int idx);
>>>>
>>>> protected:
>>>>  ImageSource();
>>>>  virtual ~ImageSource() {}   <- Debugger stops here
>>>>
>>>>  /** A version of GenerateData() specific for image processing
>>>>  * filters.  This implementation will split the processing across
>>>>  * multiple threads. The buffer is allocated by this method. Then
>>>>  ...
>>>>
>>>> _______________________________________________
>>>> 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
>