[ITK] [slicer-devel] BigTIFF
Gib Bogle
g.bogle at auckland.ac.nz
Wed Sep 17 18:12:10 EDT 2014
I boldly (rashly?) did this:
itk::ImportImageContainer< itk::SizeValueType, short>::Pointer PixelContainerShort;
and it compiles. Is this OK?
________________________________________
From: Community [community-bounces at itk.org] on behalf of Gib Bogle [g.bogle at auckland.ac.nz]
Sent: Thursday, 18 September 2014 10:01 a.m.
To: Matt McCormick
Cc: community at itk.org; slicer-devel at bwh.harvard.edu; Steve Pieper
Subject: Re: [ITK] [slicer-devel] BigTIFF
Your second suggestion fixed two occurrences :)
The next error is in vtkITKTimeSeriesDatabase.cxx(66):
itk::ImportImageContainer<unsigned long, OutputImagePixelType>::Pointer PixelContainerShort;
PixelContainerShort = this->m_Filter->GetOutput()->GetPixelContainer();
________________________________________
From: Matt McCormick [matt.mccormick at kitware.com]
Sent: Thursday, 18 September 2014 9:05 a.m.
To: Gib Bogle
Cc: Bradley Lowekamp; Steve Pieper; slicer-devel at bwh.harvard.edu; community at itk.org
Subject: Re: [slicer-devel] BigTIFF
OK, thanks for the information
Does changing the content on line 161 from
itk::ImportImageContainer< unsigned long, type >::Pointer
to
image2##typeN::PixelContainer
or at least
itk::ImportImageContainer< itk::SizeValueType, type >::Pointer
fix the issue?
Thanks,
Matt
On Wed, Sep 17, 2014 at 4:32 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
> Yes Matt. That's my line 179 too. The error message is confusing because vtkITKExecuteDataFromFile is a complex macro. It does things that I do not have a good grasp of. Every occurrence of vtkITKExecuteDataFromFile gives a similar error, and there are similar macros in other files that also give the same type of error. It is all somehow related to 'unsigned __int64', and I didn't get this error before when I was building (without knowing it) with ITK_USE_64BITS_IDS off.
>
> It is not clear to me who would be best equipped to address this - ITK, VTK or Slicer experts.
>
> I appreciate your attention to it very much!
> Gib
> ________________________________________
> From: Matt McCormick [matt.mccormick at kitware.com]
> Sent: Thursday, 18 September 2014 5:06 a.m.
> To: Gib Bogle
> Cc: Bradley Lowekamp; Steve Pieper; slicer-devel at bwh.harvard.edu; community at itk.org
> Subject: Re: [slicer-devel] BigTIFF
>
>> 3>C:\Slicer\Libs\vtkITK\vtkITKArchetypeImageSeriesScalarReader.cxx(179)
>
> Is this with the latest version of Slicer?
>
> My line 179 says
>
> vtkITKExecuteDataFromFile(VTK_DOUBLE, double);
>
> Thanks,
> Matt
>
> On Wed, Sep 17, 2014 at 12:02 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>> Hi Matt,
>> I don't know what to look for to see what is causing this error in the vtkITK build. Should vtkITK know about ITK_USE_64BITS_IDS?
>> thanks
>> Gib
>> ________________________________________
>> From: Matt McCormick [matt.mccormick at kitware.com]
>> Sent: Thursday, 18 September 2014 3:55 a.m.
>> To: Gib Bogle
>> Cc: Bradley Lowekamp; Steve Pieper; slicer-devel at bwh.harvard.edu; community at itk.org
>> Subject: Re: [slicer-devel] BigTIFF
>>
>> Hi Gib,
>>
>> Getting the builds states to propagate and follow how the get set can
>> be tricky. A few pointers on where to look for the status:
>>
>> 1) CMakeCache.txt (this file contains the build settings that CMake
>> recognized from your input when you run CMake)
>> 2) ITKConfig.cmake (this file will exist in the build tree or the
>> install tree, and it contains CMake varables that may be used by other
>> projects building against ITK)
>> 3) itkConfigure.h (this is a header that has configured preprocessor
>> definitions used when building)
>>
>> HTH,
>> Matt
>>
>>
>>
>> On Wed, Sep 17, 2014 at 3:35 AM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>>> Hi Bradley, Matt and Steve,
>>>
>>> Now for the embarrassing confession. In External_ITK4.cmake I turned
>>> ITKV3_COMPATIBILITY off and ITK_USE_64BITS_IDS on as suggested, but when I
>>> finally checked what the code that is being built was using (with #if
>>> defined ...) I discovered that both ITKV3_COMPATIBILITY and
>>> ITK_USE_64BITS_IDS were off. How can this be?
>>>
>>> It's easy, all it takes is a typo:
>>> -DITK_USE_64_BITS_IDS:BOOL=ON
>>> That typo has cost me a couple of days, and caused annoyance to a few
>>> people, I suspect.
>>>
>>> Unfortunately... now Slicer's vtkITK does not build. There are very many
>>> errors like this:
>>>
>>> 3>------ Build started: Project: vtkITK, Configuration: Release x64 ------
>>> 3>Build started 17/09/2014 7:25:52 p.m..
>>> 3>InitializeBuildStatus:
>>> 3> Touching "vtkITK.dir\Release\vtkITK.unsuccessfulbuild".
>>> 3>CustomBuild:
>>> 3> Building Custom Rule C:/Slicer/Libs/vtkITK/CMakeLists.txt
>>> 3> CMake does not need to re-run because
>>> C:\s\b\Slicer-build\Libs\vtkITK\CMakeFiles\generate.stamp is up-to-date.
>>> 3>ClCompile:
>>> 3> vtkITKNumericTraits.cxx
>>> 3> vtkITKArchetypeDiffusionTensorImageReaderFile.cxx
>>> 3> vtkITKArchetypeImageSeriesReader.cxx
>>> 3> vtkITKArchetypeImageSeriesScalarReader.cxx
>>> 3> vtkITKArchetypeImageSeriesVectorReaderFile.cxx
>>> 3> vtkITKArchetypeImageSeriesVectorReaderSeries.cxx
>>> 3> vtkITKImageWriter.cxx
>>> 3> vtkITKGradientAnisotropicDiffusionImageFilter.cxx
>>> 3> vtkITKDistanceTransform.cxx
>>> 3>C:\Slicer\Libs\vtkITK\vtkITKArchetypeImageSeriesScalarReader.cxx(179):
>>> error C2679: binary '=' : no operator found which takes a right-hand operand
>>> of type 'itk::ImportImageContainer<TElementIdentifier,TElement> *' (or there
>>> is no acceptable conversion)
>>> 3> with
>>> 3> [
>>> 3> TElementIdentifier=unsigned __int64,
>>> 3> TElement=double
>>> 3> ]
>>> 3> c:\s\b\itkv4\modules\core\common\include\itkSmartPointer.h(124):
>>> could be 'itk::SmartPointer<TObjectType>
>>> &itk::SmartPointer<TObjectType>::operator =(const
>>> itk::SmartPointer<TObjectType> &)'
>>> 3> with
>>> 3> [
>>> 3> TObjectType=itk::ImportImageContainer<unsigned long,double>
>>> 3> ]
>>> 3> c:\s\b\itkv4\modules\core\common\include\itkSmartPointer.h(128):
>>> or 'itk::SmartPointer<TObjectType>
>>> &itk::SmartPointer<TObjectType>::operator
>>> =(itk::ImportImageContainer<TElementIdentifier,TElement> *)'
>>> 3> with
>>> 3> [
>>> 3> TObjectType=itk::ImportImageContainer<unsigned long,double>,
>>> 3> TElementIdentifier=unsigned long,
>>> 3> TElement=double
>>> 3> ]
>>> 3> while trying to match the argument list
>>> '(itk::SmartPointer<TObjectType>,
>>> itk::ImportImageContainer<TElementIdentifier,TElement> *)'
>>> 3> with
>>> 3> [
>>> 3> TObjectType=itk::ImportImageContainer<unsigned long,double>
>>> 3> ]
>>> 3> and
>>> 3> [
>>> 3> TElementIdentifier=unsigned __int64,
>>> 3> TElement=double
>>> 3> ]
>>>
>>> I presume these are related to the use of 64-bit integers.
>>>
>>> Over to you guys :)
>>>
>>> Gib
>>> ________________________________
>>> From: Bradley Lowekamp [blowekamp at mail.nih.gov]
>>> Sent: Tuesday, 16 September 2014 12:45 a.m.
>>> To: Steve Pieper
>>> Cc: Gib Bogle; slicer-devel at bwh.harvard.edu
>>> Subject: Re: [slicer-devel] BigTIFF
>>>
>>> Hello,
>>>
>>> For you slicer build did you also remove the ITKV3_COMPATIBILITY flag here:
>>> https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_ITKv4.cmake#L48
>>>
>>> To test for ITK big tiff compatibility, I'd recommend getting python 2.7
>>> 64-bits then installing SimpleITK (i.e pip install SimpleITK), and try to
>>> read and write files like these there. More information about getting
>>> started is here[1].
>>>
>>> You should be a able to generate a image with:
>>>
>>> import SimpleITK as sitk
>>> img = sitk.Image( [1250,1250,1250], sitk.sitkUInt8)
>>> img += 10
>>> stats = sitk.StatisticsImageFilter()
>>> stats.Execute(img)
>>> print stats
>>>
>>> This should give you basic access to ITK in python to interactively
>>> experiment with options with these large images. I have been able to load
>>> large images with the binaries of SimpleITK on windows 64-bits. I don't know
>>> if I have tried big tiff though.
>>>
>>> A simular test could be done with C++ and ITK directly, but I think
>>> SimpleITK in python may be quicker for experimentation.
>>>
>>> Brad
>>>
>>> [1] http://www.itk.org/Wiki/SimpleITK/GettingStarted
>>> [2]
>>> http://www.itk.org/SimpleITKDoxygen/html/namespaceitk_1_1simple.html#a838017f46860e8a7bc8a9ebc7f3dbfee
>>>
>>> On Sep 15, 2014, at 7:37 AM, Steve Pieper <pieper at isomics.com> wrote:
>>>
>>> Hi Gib -
>>>
>>> Are you testing only on windows? What we would often try to do for this
>>> kind of debugging is to create a small example that other people can test on
>>> their configurations. Slicer has a mechanism called a Self Test [1] to
>>> allow easy replication and debugging across multiple platforms. It's ideal
>>> if we can hone it down to something like what is described as a 'sscce' [2].
>>> The self tests will typically download some data from a public web site, run
>>> some operations, and then print something out saying if it passed or failed
>>> (or it may crash). Since it's possible to make a small data file that
>>> expands into a giant tiff image it should be pretty tractable to pose this
>>> issue in the form of a self test.
>>>
>>> Best,
>>> Steve
>>>
>>>
>>> [1]
>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Tutorials/SelfTestModule
>>>
>>> [2] http://sscce.org/
>>>
>>> On Mon, Sep 15, 2014 at 2:21 AM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>>>>
>>>> Hi J-C,
>>>>
>>>> Some more info about Slicer with big tiff files.
>>>>
>>>> 1250x1250x1250 = 1,953,125,000 bytes loads and displays correctly
>>>> 1300x1300x1300 = 2,197,000,000 bytes loads but does not display anything
>>>> 1650x1650x1650 = 4,492,125,000 bytes fails to load (crashes reading page
>>>> 72)
>>>>
>>>> All suggestions will be gratefully received.
>>>>
>>>> Cheers
>>>> Gib
>>>> ________________________________
>>>> From: Jean-Christophe Fillion-Robin [jchris.fillionr at kitware.com]
>>>> Sent: Sunday, 14 September 2014 8:32 p.m.
>>>> To: Gib Bogle
>>>> Cc: Steve Pieper; slicer-devel at bwh.harvard.edu
>>>> Subject: Re: [slicer-devel] BigTIFF
>>>>
>>>> Hi Gib,
>>>>
>>>> What do you mean by "reinstalled" ? You should not have to install Slicer
>>>> to be able to execute it from the build directory.
>>>>
>>>> After building with "Slicer_BUILD_BRAINSTOOLS" turned off the option
>>>> "ITK_USE_64_BITS_IDS" added to the ITKv4 external project, it should work
>>>> out.
>>>>
>>>> When done building, make sure to start the Slicer launcher:
>>>>
>>>> C:/path/to/project/Slicer-Superbuild/Slicer-build/Slicer.exe
>>>>
>>>> and not the Slicer executable:
>>>>
>>>>
>>>> C:/path/to/project/Slicer-Superbuild/Slicer-build/bin/Release/SlicerApp-real.exe
>>>>
>>>>
>>>> By using the launcher, you ensure that the PATH are properly setup and the
>>>> expected libraries are loaded.
>>>>
>>>>
>>>> Hth
>>>> Jc
>>>>
>>>>
>>>> On Sat, Sep 13, 2014 at 11:49 PM, Gib Bogle <g.bogle at auckland.ac.nz>
>>>> wrote:
>>>>>
>>>>> I hope I understand correctly. I added the line as shown to
>>>>> C:\Slicer\SuperBuild\External_ITKv4.cmake:
>>>>> ...
>>>>> # ZLIB
>>>>> -DITK_USE_SYSTEM_ZLIB:BOOL=ON
>>>>> -DZLIB_ROOT:PATH=${ZLIB_ROOT}
>>>>> -DZLIB_INCLUDE_DIR:PATH=${ZLIB_INCLUDE_DIR}
>>>>> -DZLIB_LIBRARY:FILEPATH=${ZLIB_LIBRARY}
>>>>> # Big TIFF
>>>>> -DITK_USE_64_BITS_IDS:BOOL=ON
>>>>> ...
>>>>>
>>>>> I then did ALL_BUILD in the root of the build directory (C:\s\b). I
>>>>> presume this is the "superbuild". I then redid ALL_BUILD in
>>>>> C:\s\b\Slicer-build, and ITKv4-build, and reinstalled. The program still
>>>>> crashes with the big tiff. Is there somewhere I can check in the project
>>>>> configuration files to see if setting ITK_USE_64_BITS_IDS actually took
>>>>> effect?
>>>>>
>>>>> Thanks
>>>>> Gib
>>>>> ________________________________
>>>>> From: Steve Pieper [pieper at isomics.com]
>>>>> Sent: Sunday, 14 September 2014 1:36 p.m.
>>>>>
>>>>> To: Gib Bogle
>>>>> Cc: slicer-devel at bwh.harvard.edu
>>>>> Subject: Re: [slicer-devel] BigTIFF
>>>>>
>>>>> Hey Gib -
>>>>>
>>>>> Sounds like progress - the ITK_USE_64_BITS_IDS should be set to ON in the
>>>>> ITK build process [1] during the superbuild. I don't think much else was
>>>>> required except turning off the IKTv3 parts.
>>>>>
>>>>> [1]
>>>>> https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_ITKv4.cmake#L32-L68
>>>>>
>>>>> -Steve
>>>>>
>>>>> p.s. I hear the ABs beat the Boks recently in a close match (we don't get
>>>>> it on TV). So the Jo'berg game should be a great rematch!
>>>>>
>>>>> On Sat, Sep 13, 2014 at 9:11 PM, Gib Bogle <g.bogle at auckland.ac.nz>
>>>>> wrote:
>>>>>>
>>>>>> You did warn me.
>>>>>>
>>>>>> Here is the list of options not ticked:
>>>>>>
>>>>>> Slicer_BUILD_BRAINSTOOLS
>>>>>> _LEGACY_CLI
>>>>>> _LandmarkRegistration
>>>>>> _TESTING_EXTENSIONS
>>>>>> _UPDATE_TRANSLATION
>>>>>> _USE_GIT_PROTOCOL
>>>>>> _OpenIGTLink
>>>>>> _PYTHONQT_WITH_OPENSSL
>>>>>> _PYTHONQT_WITH_TCL
>>>>>> _QtTesting
>>>>>> _SimpleITK
>>>>>> _VTK_DEBUG_LINKS
>>>>>> Slicer_WITH_LIBRARY_VERSION
>>>>>>
>>>>>> USE_BRAINS*
>>>>>> USE_ConvertBetweenFileFormats
>>>>>> USE_DWIConvert
>>>>>> USE_DebugImageViewer
>>>>>> USE_GTRACT
>>>>>> USE_ICCDEF
>>>>>> USE_ImageCalculator
>>>>>> USE_ReferenceAtlas
>>>>>>
>>>>>> -------
>>>>>>
>>>>>> Progress! Process Monitor showed me that the exit code was C0000139,
>>>>>> which means a DLL was not found. I then realized that I have different
>>>>>> occurrences of many of the DLLs on my disk (QT, ITK and VTK) and this
>>>>>> prompted me to look more carefully at the PATH environment variable. I just
>>>>>> tested with all the new paths at the start of the PATH string, and Slicer
>>>>>> starts successfully! I can load a tiff! But ... it still crashes when I
>>>>>> attempt to load a 4 GB tiff.
>>>>>>
>>>>>> I am now wondering (belatedly!) about the way I tried to build with big
>>>>>> tiff capability. I guessed, and added the entry ITK_USE_64BITS_IDS as
>>>>>> 'bool'. It appears ticked in Ungrouped Entries. I really should have asked
>>>>>> for directions before doing this - now I'm wondering if that switch actually
>>>>>> had any effect. Is that the right thing to do, and if not, what is?
>>>>>>
>>>>>> Thanks
>>>>>> Gib
>>>>>> ________________________________
>>>>>> From: Steve Pieper [pieper at isomics.com]
>>>>>> Sent: Sunday, 14 September 2014 10:02 a.m.
>>>>>>
>>>>>> To: Gib Bogle
>>>>>> Cc: slicer-devel at bwh.harvard.edu
>>>>>> Subject: Re: [slicer-devel] BigTIFF
>>>>>>
>>>>>> Yes, well, don't say I didn't warn you! ; )
>>>>>>
>>>>>> You do need loadable modules and you probably do want python (a lot of
>>>>>> core stuff is in python, like the editor).
>>>>>>
>>>>>> BRAINSTools should be off for now, since it needs ITKv3.
>>>>>>
>>>>>> I'm not sure either what to do next, but I suggest maybe trying the
>>>>>> Process Monitor from microsoft (sysinternals) and see what it was doing when
>>>>>> it exited. But that may be a longshot.
>>>>>>
>>>>>> -Steve
>>>>>>
>>>>>> On Sat, Sep 13, 2014 at 4:39 PM, Gib Bogle <g.bogle at auckland.ac.nz>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Steve,
>>>>>>>
>>>>>>> That was an interesting exercise. I managed to build Slicer without
>>>>>>> Qtloadablemodules. As you might expect, it was not much use. The program
>>>>>>> started up but without any capabilities, just an empty shell. (I'm a bit
>>>>>>> handicapped by not knowing anything about how Slicer is constructed.) So I
>>>>>>> built it again, this time selecting most things except BRAINTools. The
>>>>>>> build took a long time, partly because I turned on the Python option, which
>>>>>>> I don't need. This time there were no errors, except for a couple of
>>>>>>> occasions where the attempt to create a directory failed - this was because
>>>>>>> the directory already existed, and was easily solved by deleting the
>>>>>>> directory and building again. I installed everything that wanted to be
>>>>>>> installed, and modified the environment variables to suit.
>>>>>>>
>>>>>>> My sense of satisfaction was short-lived, however. When Slicer is
>>>>>>> invoked the Acknowledgements screen flashes up briefly then the program
>>>>>>> exits. There are no error messages. Dependency Walker shows that all the
>>>>>>> DLLs are being found. I am assuming that BRAINTools is not needed (not
>>>>>>> knowing what it is).
>>>>>>>
>>>>>>> I sense that I must be close to getting it working, but I'm not sure
>>>>>>> what to do next.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Gib
>>>>>>> ________________________________
>>>>>>> From: Steve Pieper [pieper at isomics.com]
>>>>>>> Sent: Sunday, 14 September 2014 12:36 a.m.
>>>>>>>
>>>>>>> To: Gib Bogle
>>>>>>> Cc: slicer-devel at bwh.harvard.edu
>>>>>>> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>
>>>>>>> Hi Gib -
>>>>>>>
>>>>>>> A lot of the building goes on in parallel so you need to review the
>>>>>>> whole build log to see what is going on. I'm guessing ITK didn't build
>>>>>>> correctly. Typically I do a Control-A Control-C in the visual studio output
>>>>>>> window and then paste it into a text editor to look for issues. Definitely
>>>>>>> you don't want to be editing any of the visual studio files, since they are
>>>>>>> generated by cmake every configure -- much better to sort out what is going
>>>>>>> on at the cmake flag level.
>>>>>>>
>>>>>>> Best,
>>>>>>> Steve
>>>>>>>
>>>>>>> On Fri, Sep 12, 2014 at 9:27 PM, Gib Bogle <g.bogle at auckland.ac.nz>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Looking at the Project Properties for qSlicerBaseQTCore I notice
>>>>>>>> something odd. Here is a snippet from the list of Linker > Input >
>>>>>>>> Additional Dependencies:
>>>>>>>>
>>>>>>>> ...
>>>>>>>> C:\s\b\ITKv4-build\lib\Release\itktiff-4.6.lib
>>>>>>>> C:\s\b\ITKv4-build\lib\Release\itkjpeg-4.6.lib
>>>>>>>> C:\s\b\ITKv4-build\lib\Release\ITKIOMRC-4.6.lib
>>>>>>>> C:\s\b\ITKv4-build\lib\Release\ITKIOImageBase-4.6.lib
>>>>>>>> C:\s\b\VTKv5-build\bin\Release\vtkInfovis.lib
>>>>>>>> C:\s\b\VTKv5-build\bin\Release\vtkWidgets.lib
>>>>>>>> C:\s\b\VTKv5-build\bin\Release\vtkVolumeRendering.lib
>>>>>>>> ..\..\lib\Slicer-4.3\Release\FreeSurfer.lib
>>>>>>>> ITKCommon.lib
>>>>>>>> C:\Qt64\4.8.1\lib\QtOpenGL4.lib
>>>>>>>> ...
>>>>>>>>
>>>>>>>> For some reason ITKCommon.lib is treated differently from all the
>>>>>>>> other (at first sight) ITK libraries. Any ideas about how I might fix this?
>>>>>>>> If I edit the linker configuration for qSlicerBaseQTCore to point correctly
>>>>>>>> to the ITKCommon library it builds OK, but I'd rather not have to do this
>>>>>>>> 40+ times.
>>>>>>>>
>>>>>>>> Thanks again
>>>>>>>> Gib
>>>>>>>> ________________________________
>>>>>>>> From: slicer-devel-bounces at bwh.harvard.edu
>>>>>>>> [slicer-devel-bounces at bwh.harvard.edu] on behalf of Gib Bogle
>>>>>>>> [g.bogle at auckland.ac.nz]
>>>>>>>> Sent: Saturday, 13 September 2014 12:59 p.m.
>>>>>>>>
>>>>>>>> To: Steve Pieper
>>>>>>>> Cc: slicer-devel at bwh.harvard.edu
>>>>>>>> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>
>>>>>>>> Hi Steve,
>>>>>>>>
>>>>>>>> All goes well until the point where the qSlicer*.lib get made. The
>>>>>>>> first error, while building qSlicerBaseQTCore.lib, is:
>>>>>>>>
>>>>>>>> LINK : fatal error LNK1181: cannot open input file 'ITKCommon.lib'
>>>>>>>>
>>>>>>>> I don't know how to interpret this. I am guessing that it wants to
>>>>>>>> link the ITK library that was just built, i.e.:
>>>>>>>> \s\b\ITKv4-build\lib\Release\ITKCommon-4.6.lib
>>>>>>>> This is the first of about 40 such link errors.
>>>>>>>>
>>>>>>>> I'm not sure if ITK really needed to be built, since it is already
>>>>>>>> installed (64-bit) on my system, but I didn't see any option for skipping
>>>>>>>> that step (same for VTK). Is an INSTALL step for ITK needed? Should I set
>>>>>>>> ITK_DIR appropriately?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Gib
>>>>>>>> ________________________________
>>>>>>>> From: Steve Pieper [pieper at isomics.com]
>>>>>>>> Sent: Saturday, 13 September 2014 9:02 a.m.
>>>>>>>> To: Gib Bogle
>>>>>>>> Cc: slicer-devel at bwh.harvard.edu
>>>>>>>> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>
>>>>>>>> Hi Gib -
>>>>>>>>
>>>>>>>> I'd give a qualified 'yes' answer. Technically what you propose is
>>>>>>>> quite reasonable, and would be workable. But if you haven't built a big
>>>>>>>> package on windows before there are quite a few prerequites (qt, cmake, git,
>>>>>>>> visual studio...) and odd things can go wrong if it isn't all done just
>>>>>>>> right. That said, slicer is actually quite well supported on windows,
>>>>>>>> better, IMHO, than many cross-platform systems. But windows is really the
>>>>>>>> trickiest platform in my experience.
>>>>>>>>
>>>>>>>> -Steve
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Sep 12, 2014 at 4:32 PM, Gib Bogle <g.bogle at auckland.ac.nz>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Steve,
>>>>>>>>>
>>>>>>>>> Do you think I would be able to build Slicer myself, with
>>>>>>>>> ITK_USE_64BITS_IDS and leaving out BRAINSTools and anything else that
>>>>>>>>> depends on either ITKDeprecated or ITKV3Compatibility? My need at this
>>>>>>>>> point is simply for a 3D viewer that can handle big images.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Gib
>>>>>>>>> ________________________________
>>>>>>>>> From: Gib Bogle
>>>>>>>>> Sent: Wednesday, 10 September 2014 10:34 a.m.
>>>>>>>>> To: Jean-Christophe Fillion-Robin; Steve Pieper
>>>>>>>>> Cc: slicer-devel at bwh.harvard.edu
>>>>>>>>> Subject: RE: [slicer-devel] BigTIFF
>>>>>>>>>
>>>>>>>>> Hi Jean-Christophe,
>>>>>>>>>
>>>>>>>>> Any idea when 4.5 will enter the world?
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Gib
>>>>>>>>> ________________________________
>>>>>>>>> From: slicer-devel-bounces at bwh.harvard.edu
>>>>>>>>> [slicer-devel-bounces at bwh.harvard.edu] on behalf of Jean-Christophe
>>>>>>>>> Fillion-Robin [jchris.fillionr at kitware.com]
>>>>>>>>> Sent: Wednesday, 10 September 2014 10:31 a.m.
>>>>>>>>> To: Steve Pieper
>>>>>>>>> Cc: slicer-devel at bwh.harvard.edu
>>>>>>>>> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>>
>>>>>>>>> Hi Folks,
>>>>>>>>>
>>>>>>>>> Thanks to Brad Lowekamp, Slicer core (r23663) does NOT depend on
>>>>>>>>> either ITKDeprecated or ITKV3Compatibility.
>>>>>>>>>
>>>>>>>>> That said, BRAINSTools and some extensions are still depending on
>>>>>>>>> these module. All details are captured here:
>>>>>>>>>
>>>>>>>>> http://na-mic.org/Mantis/view.php?id=3825#c12486
>>>>>>>>>
>>>>>>>>> Note also that this will NOT be addressed for Slicer 4.4 release. The
>>>>>>>>> enabling of ITK_USE_64BITS_IDS that will allow BigTiff to be loaded is
>>>>>>>>> planned for 4.5.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Jc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Sep 5, 2014 at 10:26 AM, Steve Pieper <pieper at isomics.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Matt -
>>>>>>>>>>
>>>>>>>>>> Thanks, that's helpful.
>>>>>>>>>>
>>>>>>>>>> I suspect that for slicer, the only real issues will be in vtkITK,
>>>>>>>>>> which includes all the file IO adapters. But I think it will be pretty
>>>>>>>>>> straightforward.
>>>>>>>>>>
>>>>>>>>>> But there's no reason to start that until we know that BRAINSTools
>>>>>>>>>> will work - right now at least some of them depend on ITKDeprecated.
>>>>>>>>>>
>>>>>>>>>> -Steve
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 5, 2014 at 10:06 AM, Matt McCormick
>>>>>>>>>> <matt.mccormick at kitware.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Here is what the process would look like:
>>>>>>>>>>>
>>>>>>>>>>> 0) Start with a clean software quality dashboard.
>>>>>>>>>>> 1) Set ITKV3_COMPATIBILITY to OFF in
>>>>>>>>>>> Superbuild/External_ITKv4.cmake
>>>>>>>>>>> 2) Rebuild and encounter errors and test failures.
>>>>>>>>>>> 3) Fix the errors with the help of the ITK migration guide [1] and
>>>>>>>>>>> the
>>>>>>>>>>> ITK mailing list [2]. They usually fairly strait forward changes
>>>>>>>>>>> (minor modifications to the API, etc).
>>>>>>>>>>> 4) Set ITK_USE_64BITS_IDS to ON.
>>>>>>>>>>> 5) Profit.
>>>>>>>>>>>
>>>>>>>>>>> HTH,
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>> [1] http://itk.org/migrationv4/
>>>>>>>>>>>
>>>>>>>>>>> [2] http://www.itk.org/ITK/help/mailing.html
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 4, 2014 at 4:52 PM, Steve Pieper <pieper at isomics.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> > Yes, agreed it's a good goal and I believe the expertise exists,
>>>>>>>>>>> > but it's
>>>>>>>>>>> > looking like there's a fair amount of code to retrofit.
>>>>>>>>>>> >
>>>>>>>>>>> > Maybe Hans, Brad, Matt or others could provide some idea just
>>>>>>>>>>> > what is
>>>>>>>>>>> > involved?
>>>>>>>>>>> >
>>>>>>>>>>> > -Steve
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > On Thu, Sep 4, 2014 at 4:50 PM, Gib Bogle
>>>>>>>>>>> > <g.bogle at auckland.ac.nz> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> :( I imagine that people are increasingly working with very
>>>>>>>>>>> >> large
>>>>>>>>>>> >> datasets, so the number of people who would like to have this
>>>>>>>>>>> >> capability
>>>>>>>>>>> >> will grow. I, alas, am not an ITK expert.
>>>>>>>>>>> >> ________________________________
>>>>>>>>>>> >> From: Steve Pieper [pieper at isomics.com]
>>>>>>>>>>> >> Sent: Friday, 5 September 2014 8:42 a.m.
>>>>>>>>>>> >>
>>>>>>>>>>> >> To: Gib Bogle
>>>>>>>>>>> >> Cc: Bradley Lowekamp; slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>>>> >>
>>>>>>>>>>> >> Alas the build where I enabled 64 bit id's failed to even
>>>>>>>>>>> >> configure
>>>>>>>>>>> >> properly. Lots of key code depends on the ITKDeprecated module,
>>>>>>>>>>> >> like vtkITK
>>>>>>>>>>> >> and various components of BRAINSTools. So I would say some ITK
>>>>>>>>>>> >> experts are
>>>>>>>>>>> >> going to need to dig in before this mode can be enabled.
>>>>>>>>>>> >>
>>>>>>>>>>> >> -Steve
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Thu, Sep 4, 2014 at 4:08 PM, Gib Bogle
>>>>>>>>>>> >> <g.bogle at auckland.ac.nz> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> I await the results with interest...
>>>>>>>>>>> >>> ________________________________
>>>>>>>>>>> >>> From: slicer-devel-bounces at bwh.harvard.edu
>>>>>>>>>>> >>> [slicer-devel-bounces at bwh.harvard.edu] on behalf of Steve
>>>>>>>>>>> >>> Pieper
>>>>>>>>>>> >>> [pieper at isomics.com]
>>>>>>>>>>> >>> Sent: Friday, 5 September 2014 1:32 a.m.
>>>>>>>>>>> >>> To: Bradley Lowekamp
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Cc: slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Makes sense, thanks for clarifying Brad. Jc recently moved out
>>>>>>>>>>> >>> a lot of
>>>>>>>>>>> >>> legacy CLI code - perhaps those were the main places
>>>>>>>>>>> >>> ITKV3_COMPATIBILITY was
>>>>>>>>>>> >>> required? I kicked off a build to see what will happen.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> -Steve
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> On Thu, Sep 4, 2014 at 8:36 AM, Bradley Lowekamp
>>>>>>>>>>> >>> <blowekamp at mail.nih.gov>
>>>>>>>>>>> >>> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Steve,
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Yes, this is certainly an issue with how ITK has been
>>>>>>>>>>> >>>> configured in
>>>>>>>>>>> >>>> Slicer.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> To turn on the 64-bit IDs for windows 64, ITKV3_COMPATIBILITY
>>>>>>>>>>> >>>> needs to
>>>>>>>>>>> >>>> be disabled, and then the ITKDeprecated module can no longer
>>>>>>>>>>> >>>> be used. I have
>>>>>>>>>>> >>>> brought these issue up before and offered assistance but no
>>>>>>>>>>> >>>> one wanted to
>>>>>>>>>>> >>>> champion changing these configuration flags.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Brad
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On Sep 3, 2014, at 6:30 PM, Steve Pieper <pieper at isomics.com>
>>>>>>>>>>> >>>> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Hi Brad -
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Right, this is not tiff specific but is ITK specific. I was
>>>>>>>>>>> >>>> able to
>>>>>>>>>>> >>>> create a 1650^3 volume (of doubles) in VTK, save with slicer's
>>>>>>>>>>> >>>> vtkNRRDWriter
>>>>>>>>>>> >>>> and reload with vtkNRRDReader. Could not read the same file
>>>>>>>>>>> >>>> with ITK's NRRD
>>>>>>>>>>> >>>> reader. This was all on a slicer current trunk build with
>>>>>>>>>>> >>>> default options
>>>>>>>>>>> >>>> on win7 64bit.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> So are we out of luck enabling 64bit IDs or is it just
>>>>>>>>>>> >>>> something nobody
>>>>>>>>>>> >>>> has tried?
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> -Steve
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On Wed, Sep 3, 2014 at 11:17 AM, Bradley Lowekamp
>>>>>>>>>>> >>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Steve,
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Can you usr/load any image greater that 2GB into Slicer on
>>>>>>>>>>> >>>>> windows 64?
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> There should be some image source filters in the
>>>>>>>>>>> >>>>> SimpleFilters modules
>>>>>>>>>>> >>>>> to generate images. I don't think this issue is tiff
>>>>>>>>>>> >>>>> specific.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Bread
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> On Sep 3, 2014, at 11:03 AM, Steve Pieper
>>>>>>>>>>> >>>>> <pieper at isomics.com> wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> I was able to replicate the crash - Thanks for the data, Gib!
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> I happens in the itk tiff reader. I created a bug report and
>>>>>>>>>>> >>>>> pasted in
>>>>>>>>>>> >>>>> a stack trace and put a link to the data.
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> http://na-mic.org/Bug/view.php?id=3825
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> -Steve
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> On Tue, Sep 2, 2014 at 5:24 PM, Bradley Lowekamp
>>>>>>>>>>> >>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Matt, I was just about to point that out.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> The other things is the compatibility flag:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_ITKv4.cmake#L48
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> I think the prevents the 64-bit IDs being used. That is it's
>>>>>>>>>>> >>>>>> still
>>>>>>>>>>> >>>>>> long not long long, so that it's "compatible" with ITKv3.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkIntTypes.h#L122
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Brad
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> On Sep 2, 2014, at 5:15 PM, Steve Pieper
>>>>>>>>>>> >>>>>> <pieper at isomics.com> wrote:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Thanks Matt - that looks logical! Let's see if we can
>>>>>>>>>>> >>>>>> replicate the
>>>>>>>>>>> >>>>>> issue and then we can see if that has any side effects.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> On Tue, Sep 2, 2014 at 4:44 PM, Matt McCormick
>>>>>>>>>>> >>>>>> <matt.mccormick at kitware.com> wrote:
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> Here is an untested patch that may fix the problem:
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> https://github.com/thewtex/Slicer/commit/24d571c970d012015a95ac6063e3b0a3fede96fb
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> On Tue, Sep 2, 2014 at 4:42 PM, Gib Bogle
>>>>>>>>>>> >>>>>>> <g.bogle at auckland.ac.nz>
>>>>>>>>>>> >>>>>>> wrote:
>>>>>>>>>>> >>>>>>> > I have to do something else for a while now. I'll get
>>>>>>>>>>> >>>>>>> > back to this
>>>>>>>>>>> >>>>>>> > later.
>>>>>>>>>>> >>>>>>> > ________________________________
>>>>>>>>>>> >>>>>>> > From: Steve Pieper [pieper at isomics.com]
>>>>>>>>>>> >>>>>>> > Sent: Wednesday, 3 September 2014 8:41 a.m.
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> > To: Gib Bogle
>>>>>>>>>>> >>>>>>> > Cc: Bradley Lowekamp; slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>>>>>> > Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> > Sure, if that works that's fine. Or maybe Brad knows how
>>>>>>>>>>> >>>>>>> > to
>>>>>>>>>>> >>>>>>> > generate a big
>>>>>>>>>>> >>>>>>> > file with SimpleITK. Or a statically linked executable
>>>>>>>>>>> >>>>>>> > for any
>>>>>>>>>>> >>>>>>> > standard
>>>>>>>>>>> >>>>>>> > platform should be fine too.
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> > On Tue, Sep 2, 2014 at 4:40 PM, Gib Bogle
>>>>>>>>>>> >>>>>>> > <g.bogle at auckland.ac.nz>
>>>>>>>>>>> >>>>>>> > wrote:
>>>>>>>>>>> >>>>>>> >>
>>>>>>>>>>> >>>>>>> >> On second thoughts a very simple image will compress to
>>>>>>>>>>> >>>>>>> >> a
>>>>>>>>>>> >>>>>>> >> reasonable size.
>>>>>>>>>>> >>>>>>> >> Slicer seems to handle the compression modes used by ITK
>>>>>>>>>>> >>>>>>> >> without
>>>>>>>>>>> >>>>>>> >> problems.
>>>>>>>>>>> >>>>>>> >> ________________________________
>>>>>>>>>>> >>>>>>> >> From: Steve Pieper [pieper at isomics.com]
>>>>>>>>>>> >>>>>>> >> Sent: Wednesday, 3 September 2014 8:31 a.m.
>>>>>>>>>>> >>>>>>> >> To: Gib Bogle
>>>>>>>>>>> >>>>>>> >> Cc: Bradley Lowekamp; slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>>>>>> >> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>>>> >>>>>>> >>
>>>>>>>>>>> >>>>>>> >> Hi -
>>>>>>>>>>> >>>>>>> >>
>>>>>>>>>>> >>>>>>> >> Is there an easy way to generate a big tiff like this,
>>>>>>>>>>> >>>>>>> >> for example
>>>>>>>>>>> >>>>>>> >> with a
>>>>>>>>>>> >>>>>>> >> few lines of SimpleITK code? (Easier than trying to
>>>>>>>>>>> >>>>>>> >> transfer a
>>>>>>>>>>> >>>>>>> >> 4.5GB file
>>>>>>>>>>> >>>>>>> >> from NZ).
>>>>>>>>>>> >>>>>>> >>
>>>>>>>>>>> >>>>>>> >> -Steve
>>>>>>>>>>> >>>>>>> >>
>>>>>>>>>>> >>>>>>> >>
>>>>>>>>>>> >>>>>>> >> On Tue, Sep 2, 2014 at 4:26 PM, Gib Bogle
>>>>>>>>>>> >>>>>>> >> <g.bogle at auckland.ac.nz>
>>>>>>>>>>> >>>>>>> >> wrote:
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> Hi Brad,
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> I installed Slicer-4.3.1 64-bit version on Windows 7.
>>>>>>>>>>> >>>>>>> >>> I can load
>>>>>>>>>>> >>>>>>> >>> a tiff
>>>>>>>>>>> >>>>>>> >>> file that is about 1 GB (grey-scale 1000x1000x1000),
>>>>>>>>>>> >>>>>>> >>> but a couple
>>>>>>>>>>> >>>>>>> >>> of bigger
>>>>>>>>>>> >>>>>>> >>> files fail. When I try to open a file that is about
>>>>>>>>>>> >>>>>>> >>> 4.5 GB
>>>>>>>>>>> >>>>>>> >>> (actually when I
>>>>>>>>>>> >>>>>>> >>> try to add data to the scene) the program crashes
>>>>>>>>>>> >>>>>>> >>> immediately,
>>>>>>>>>>> >>>>>>> >>> exception
>>>>>>>>>>> >>>>>>> >>> code c0000005. The result with an image of about half
>>>>>>>>>>> >>>>>>> >>> this size
>>>>>>>>>>> >>>>>>> >>> is the
>>>>>>>>>>> >>>>>>> >>> same. Sometimes the behaviour is slightly different -
>>>>>>>>>>> >>>>>>> >>> I see the
>>>>>>>>>>> >>>>>>> >>> "Loading..." popup, but it's stuck on 15% and the
>>>>>>>>>>> >>>>>>> >>> windows greys
>>>>>>>>>>> >>>>>>> >>> out.
>>>>>>>>>>> >>>>>>> >>> Nothing happens after that, until I click the x button
>>>>>>>>>>> >>>>>>> >>> on the
>>>>>>>>>>> >>>>>>> >>> popup, and the
>>>>>>>>>>> >>>>>>> >>> program crashes.
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> These files were all written with ITK. The reason I
>>>>>>>>>>> >>>>>>> >>> installed
>>>>>>>>>>> >>>>>>> >>> Slicer is
>>>>>>>>>>> >>>>>>> >>> simply to be able to view big files - Irfanview is very
>>>>>>>>>>> >>>>>>> >>> good but
>>>>>>>>>>> >>>>>>> >>> BigTIFFs
>>>>>>>>>>> >>>>>>> >>> are not enabled.
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> Is it a case of having to build Slicer myself, with
>>>>>>>>>>> >>>>>>> >>> different
>>>>>>>>>>> >>>>>>> >>> build
>>>>>>>>>>> >>>>>>> >>> options?
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> Thanks
>>>>>>>>>>> >>>>>>> >>> Gib
>>>>>>>>>>> >>>>>>> >>> ________________________________
>>>>>>>>>>> >>>>>>> >>> From: Bradley Lowekamp [blowekamp at mail.nih.gov]
>>>>>>>>>>> >>>>>>> >>> Sent: Wednesday, 3 September 2014 1:00 a.m.
>>>>>>>>>>> >>>>>>> >>> To: Gib Bogle
>>>>>>>>>>> >>>>>>> >>> Cc: slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>>>>>> >>> Subject: Re: [slicer-devel] BigTIFF
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> Hello,
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> I believe Slicer is using ITK's libtiff library 4.0.3,
>>>>>>>>>>> >>>>>>> >>> and the
>>>>>>>>>>> >>>>>>> >>> associated
>>>>>>>>>>> >>>>>>> >>> ITK ImageIO. This should support BigTIFFs. Could you
>>>>>>>>>>> >>>>>>> >>> please
>>>>>>>>>>> >>>>>>> >>> provide more
>>>>>>>>>>> >>>>>>> >>> detail about your issue?
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> Brad
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> On Sep 1, 2014, at 5:14 PM, Gib Bogle
>>>>>>>>>>> >>>>>>> >>> <g.bogle at auckland.ac.nz>
>>>>>>>>>>> >>>>>>> >>> wrote:
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> Hi,
>>>>>>>>>>> >>>>>>> >>> It seems that Slicer (the Windows version, anyway) does
>>>>>>>>>>> >>>>>>> >>> not
>>>>>>>>>>> >>>>>>> >>> handle
>>>>>>>>>>> >>>>>>> >>> BigTIFFs. Is there a plan to add this capability?
>>>>>>>>>>> >>>>>>> >>> Thanks
>>>>>>>>>>> >>>>>>> >>> Gib
>>>>>>>>>>> >>>>>>> >>> _______________________________________________
>>>>>>>>>>> >>>>>>> >>> slicer-devel mailing list
>>>>>>>>>>> >>>>>>> >>> slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>>>>>> >>>>>>> >>> To unsubscribe: send email to
>>>>>>>>>>> >>>>>>> >>> slicer-devel-request at massmail.spl.harvard.edu with
>>>>>>>>>>> >>>>>>> >>> unsubscribe as
>>>>>>>>>>> >>>>>>> >>> the
>>>>>>>>>>> >>>>>>> >>> subject
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> The information in this e-mail is intended only for the
>>>>>>>>>>> >>>>>>> >>> person to
>>>>>>>>>>> >>>>>>> >>> whom it
>>>>>>>>>>> >>>>>>> >>> is
>>>>>>>>>>> >>>>>>> >>> addressed. If you believe this e-mail was sent to you
>>>>>>>>>>> >>>>>>> >>> in error
>>>>>>>>>>> >>>>>>> >>> and the
>>>>>>>>>>> >>>>>>> >>> e-mail
>>>>>>>>>>> >>>>>>> >>> contains patient information, please contact the
>>>>>>>>>>> >>>>>>> >>> Partners
>>>>>>>>>>> >>>>>>> >>> Compliance
>>>>>>>>>>> >>>>>>> >>> HelpLine at
>>>>>>>>>>> >>>>>>> >>> http://www.partners.org/complianceline . If the e-mail
>>>>>>>>>>> >>>>>>> >>> was sent
>>>>>>>>>>> >>>>>>> >>> to you in
>>>>>>>>>>> >>>>>>> >>> error
>>>>>>>>>>> >>>>>>> >>> but does not contain patient information, please
>>>>>>>>>>> >>>>>>> >>> contact the
>>>>>>>>>>> >>>>>>> >>> sender and
>>>>>>>>>>> >>>>>>> >>> properly
>>>>>>>>>>> >>>>>>> >>> dispose of the e-mail.
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> _______________________________________________
>>>>>>>>>>> >>>>>>> >>> slicer-devel mailing list
>>>>>>>>>>> >>>>>>> >>> slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>>>>>> >>>>>>> >>> To unsubscribe: send email to
>>>>>>>>>>> >>>>>>> >>> slicer-devel-request at massmail.spl.harvard.edu with
>>>>>>>>>>> >>>>>>> >>> unsubscribe as
>>>>>>>>>>> >>>>>>> >>> the
>>>>>>>>>>> >>>>>>> >>> subject
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>> The information in this e-mail is intended only for the
>>>>>>>>>>> >>>>>>> >>> person to
>>>>>>>>>>> >>>>>>> >>> whom it
>>>>>>>>>>> >>>>>>> >>> is
>>>>>>>>>>> >>>>>>> >>> addressed. If you believe this e-mail was sent to you
>>>>>>>>>>> >>>>>>> >>> in error
>>>>>>>>>>> >>>>>>> >>> and the
>>>>>>>>>>> >>>>>>> >>> e-mail
>>>>>>>>>>> >>>>>>> >>> contains patient information, please contact the
>>>>>>>>>>> >>>>>>> >>> Partners
>>>>>>>>>>> >>>>>>> >>> Compliance
>>>>>>>>>>> >>>>>>> >>> HelpLine at
>>>>>>>>>>> >>>>>>> >>> http://www.partners.org/complianceline . If the e-mail
>>>>>>>>>>> >>>>>>> >>> was sent
>>>>>>>>>>> >>>>>>> >>> to you in
>>>>>>>>>>> >>>>>>> >>> error
>>>>>>>>>>> >>>>>>> >>> but does not contain patient information, please
>>>>>>>>>>> >>>>>>> >>> contact the
>>>>>>>>>>> >>>>>>> >>> sender and
>>>>>>>>>>> >>>>>>> >>> properly
>>>>>>>>>>> >>>>>>> >>> dispose of the e-mail.
>>>>>>>>>>> >>>>>>> >>>
>>>>>>>>>>> >>>>>>> >>
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> > _______________________________________________
>>>>>>>>>>> >>>>>>> > slicer-devel mailing list
>>>>>>>>>>> >>>>>>> > slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>>>>>> >>>>>>> > To unsubscribe: send email to
>>>>>>>>>>> >>>>>>> > slicer-devel-request at massmail.spl.harvard.edu
>>>>>>>>>>> >>>>>>> > with unsubscribe as the subject
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>> > The information in this e-mail is intended only for the
>>>>>>>>>>> >>>>>>> > person to
>>>>>>>>>>> >>>>>>> > whom it is
>>>>>>>>>>> >>>>>>> > addressed. If you believe this e-mail was sent to you in
>>>>>>>>>>> >>>>>>> > error and
>>>>>>>>>>> >>>>>>> > the
>>>>>>>>>>> >>>>>>> > e-mail
>>>>>>>>>>> >>>>>>> > contains patient information, please contact the Partners
>>>>>>>>>>> >>>>>>> > Compliance
>>>>>>>>>>> >>>>>>> > HelpLine at
>>>>>>>>>>> >>>>>>> > http://www.partners.org/complianceline . If the e-mail
>>>>>>>>>>> >>>>>>> > was sent to
>>>>>>>>>>> >>>>>>> > you in
>>>>>>>>>>> >>>>>>> > error
>>>>>>>>>>> >>>>>>> > but does not contain patient information, please contact
>>>>>>>>>>> >>>>>>> > the sender
>>>>>>>>>>> >>>>>>> > and
>>>>>>>>>>> >>>>>>> > properly
>>>>>>>>>>> >>>>>>> > dispose of the e-mail.
>>>>>>>>>>> >>>>>>> >
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> _______________________________________________
>>>>>>>>>>> >>>>>> slicer-devel mailing list
>>>>>>>>>>> >>>>>> slicer-devel at bwh.harvard.edu
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>>>>>> >>>>>> To unsubscribe: send email to
>>>>>>>>>>> >>>>>> slicer-devel-request at massmail.spl.harvard.edu with
>>>>>>>>>>> >>>>>> unsubscribe as the
>>>>>>>>>>> >>>>>> subject
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> The information in this e-mail is intended only for the
>>>>>>>>>>> >>>>>> person to whom
>>>>>>>>>>> >>>>>> it is
>>>>>>>>>>> >>>>>> addressed. If you believe this e-mail was sent to you in
>>>>>>>>>>> >>>>>> error and the
>>>>>>>>>>> >>>>>> e-mail
>>>>>>>>>>> >>>>>> contains patient information, please contact the Partners
>>>>>>>>>>> >>>>>> Compliance
>>>>>>>>>>> >>>>>> HelpLine at
>>>>>>>>>>> >>>>>> http://www.partners.org/complianceline . If the e-mail was
>>>>>>>>>>> >>>>>> sent to you
>>>>>>>>>>> >>>>>> in error
>>>>>>>>>>> >>>>>> but does not contain patient information, please contact the
>>>>>>>>>>> >>>>>> sender
>>>>>>>>>>> >>>>>> and properly
>>>>>>>>>>> >>>>>> dispose of the e-mail.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > slicer-devel mailing list
>>>>>>>>>>> > slicer-devel at bwh.harvard.edu
>>>>>>>>>>> > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>>>>>> > To unsubscribe: send email to
>>>>>>>>>>> > slicer-devel-request at massmail.spl.harvard.edu
>>>>>>>>>>> > with unsubscribe as the subject
>>>>>>>>>>> >
>>>>>>>>>>> > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > The information in this e-mail is intended only for the person to
>>>>>>>>>>> > whom it is
>>>>>>>>>>> > addressed. If you believe this e-mail was sent to you in error
>>>>>>>>>>> > and the
>>>>>>>>>>> > e-mail
>>>>>>>>>>> > contains patient information, please contact the Partners
>>>>>>>>>>> > Compliance
>>>>>>>>>>> > HelpLine at
>>>>>>>>>>> > http://www.partners.org/complianceline . If the e-mail was sent
>>>>>>>>>>> > to you in
>>>>>>>>>>> > error
>>>>>>>>>>> > but does not contain patient information, please contact the
>>>>>>>>>>> > sender and
>>>>>>>>>>> > properly
>>>>>>>>>>> > dispose of the e-mail.
>>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> slicer-devel mailing list
>>>>>>>>>> slicer-devel at bwh.harvard.edu
>>>>>>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>>>>>>> To unsubscribe: send email to
>>>>>>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the
>>>>>>>>>> subject
>>>>>>>>>>
>>>>>>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The information in this e-mail is intended only for the person to
>>>>>>>>>> whom it is
>>>>>>>>>> addressed. If you believe this e-mail was sent to you in error and
>>>>>>>>>> the e-mail
>>>>>>>>>> contains patient information, please contact the Partners Compliance
>>>>>>>>>> HelpLine at
>>>>>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to
>>>>>>>>>> you in error
>>>>>>>>>> but does not contain patient information, please contact the sender
>>>>>>>>>> and properly
>>>>>>>>>> dispose of the e-mail.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> +1 919 869 8849
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> slicer-devel mailing list
>>>>> slicer-devel at bwh.harvard.edu
>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>> To unsubscribe: send email to
>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the
>>>>> subject
>>>>>
>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>>>
>>>>>
>>>>> The information in this e-mail is intended only for the person to whom it
>>>>> is
>>>>> addressed. If you believe this e-mail was sent to you in error and the
>>>>> e-mail
>>>>> contains patient information, please contact the Partners Compliance
>>>>> HelpLine at
>>>>> http://www.partners.org/complianceline . If the e-mail was sent to you in
>>>>> error
>>>>> but does not contain patient information, please contact the sender and
>>>>> properly
>>>>> dispose of the e-mail.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> +1 919 869 8849
>>>
>>>
>>> _______________________________________________
>>> slicer-devel mailing list
>>> slicer-devel at bwh.harvard.edu
>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>> To unsubscribe: send email to slicer-devel-request at massmail.spl.harvard.edu
>>> with unsubscribe as the subject
>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>>
>>>
>>> The information in this e-mail is intended only for the person to whom it is
>>> addressed. If you believe this e-mail was sent to you in error and the
>>> e-mail
>>> contains patient information, please contact the Partners Compliance
>>> HelpLine at
>>> http://www.partners.org/complianceline . If the e-mail was sent to you in
>>> error
>>> but does not contain patient information, please contact the sender and
>>> properly
>>> dispose of the e-mail.
>>>
>>>
_______________________________________________
Community mailing list
Community at itk.org
http://public.kitware.com/mailman/listinfo/community
More information about the Community
mailing list