[Ctk-developers] DCMTK JPEG 2000 support (was: [slicer-devel] JPEG 2000)

Tue Feb 25 23:18:12 UTC 2014

Cross-posting answer from Aaron:

On Tue, Feb 25, 2014 at 9:19 AM, Aaron Boxer <boxerab at gmail.com> wrote:

>
> Thanks. My patch will probably not be accepted by Offis, since they have
> their own commercial jpeg 2000 product.
> So, using this means that we will have to use an unofficial DCMTK build.
>
> My patch changes very little in the library, so it is quite safe.
>

On Tue, Feb 25, 2014 at 6:01 PM, Jean-Christophe Fillion-Robin <
jchris.fillionr at kitware.com> wrote:

>
>
> ---------- Forwarded message ----------
> From: Aaron Boxer <boxerab at gmail.com>
> Date: Fri, Feb 21, 2014 at 3:28 PM
> Subject: Re: [slicer-devel] JPEG 2000
> To: "slicer-devel at bwh.harvard.edu" <slicer-devel at bwh.harvard.edu>
>
>
> Well Folks, I've been able to successfully decode jpeg 2000 images on my
> dcmtk branch.
>
> You can find the branch here:
>
> https://github.com/OpenRadStack/dcmtk/tree/j2k
>
> I am still using git submodules and manual build to build openjpeg;
> haven't had a chance yet to follow Jcr's build advice.
>
>
> If you would like to try it out, you can follow these steps:
>
> 1) clone the project
> 2) run  $  git submodule init & git submodule update
> 3) use cmake to build  openjpeg  (third-party/openjpeg)   into
> third-party/openjpeg-build   folder (enable shared library)
> 4) make sure that openjp2 shared library is in your path
>
> For testing, I am running the dcmtk dcmj2pnm command line tool to convert
> dicom images to bmp.
>
> Command line I am using:
>
> +ob +Wm dicomFile destinationFile.bmp
>
> Cheers,
> Aaron
>
>
>
>
>
>
> On Thu, Feb 20, 2014 at 2:26 PM, Jean-Christophe Fillion-Robin <
> jchris.fillionr at kitware.com> wrote:
>
>> Hi Aaron,
>>
>> This is great news.
>>
>> I don't think DCMTK should use either git submodule or External project,
>> instead you should assume the library is either installed on the system or
>> related path passed at configure time. You could then just call:
>>
>>     find_package(OpenJPEG NO_MODULE)    See [1]
>>
>> in the 3rdparty.cmake. See [2]
>>
>> When configuring DCMTK, it means you would simply pass the path the
>> OpenJPEG build tree passing -DOpenJPEG_DIR:PATH=/path/to/openJPEG-build
>>
>>
>> [1] This is possible because a OpenJPEGConfig.cmake is configured. see
>> http://code.google.com/p/openjpeg/source/browse/trunk/cmake/OpenJPEGConfig.cmake.inand
>> http://code.google.com/p/openjpeg/source/browse/trunk/CMakeLists.txt#298
>>
>> [2] https://github.com/commontk/DCMTK/blob/patched-3/CMake/3rdparty.cmake
>>
>>
>> On Thu, Feb 20, 2014 at 2:08 PM, Aaron Boxer <boxerab at gmail.com> wrote:
>>
>>> Update: I am closing in on a jpeg2000-enabled branch from DCMTK master.
>>> Should be ready next week.
>>> One issue I am having: I have added the openjpeg project (which is a
>>> cmake proj) to dcmtk as a git submodule.
>>> Now I need to figure out how the cmake externalproject command works.
>>>
>>> (
>>> http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject
>>> )
>>>
>>> If anyone here is familiar with this, and would like to help, please let
>>> me know.
>>>
>>> Thanks,
>>> Aaron
>>>
>>>
>>>
>>> On Mon, Feb 17, 2014 at 9:45 AM, Steve Pieper <pieper at isomics.com>wrote:
>>>
>>>> Hi Aaron -
>>>>
>>>> I like your plan of reviewing the osirix implementation and taking
>>>> advantage of the latest developments in OpenJPEG - very exciting to see
>>>> this moving ahead!
>>>>
>>>> Regarding your questions about thumbnails in ctkDICOM2: CTK only uses
>>>> DCMTK, not GDCM, so it currently fails to create thumbnails for images not
>>>> directly supported by DCMTK.  CTK doesn't have a mechanism to use ITK or
>>>> GDCM, although I suppose this could be added.  In ctk we really wanted to
>>>> have robust networking support in CTK and as you noted DCMTK has a well
>>>> established track record in this.
>>>>
>>>> Best,
>>>> Steve
>>>>
>>>>
>>>> On Mon, Feb 17, 2014 at 8:53 AM, Aaron Boxer <boxerab at gmail.com> wrote:
>>>>
>>>>> Hi Steve,
>>>>>
>>>>>
>>>>>> That would be an awesome contribution - useful for slicer but also
>>>>>> for CTK and other DCMTK users.  The situation right now is that slicer
>>>>>> builds dcmtk (without jpeg2000 as you noted) so none of the dcmtk-based
>>>>>> code can access that kind of image.  So for example in the ctkDICOM app the
>>>>>> thumbnails aren't displayed for data of that type.  The osirix sample data
>>>>>> is a good source of images that are compressed in a way dcmtk doesn't like.
>>>>>>
>>>>>> That said, when slicer actually goes to read the data it is delegated
>>>>>> to ITK's readers, which include GDCM and that supports jpeg2000 so the
>>>>>> files load.
>>>>>>
>>>>>
>>>>>  Interesting. Can the ctkDICOM app use GDCM for the thumbnails?
>>>>>
>>>>>
>>>>>>
>>>>>> This is an oddly messy situation.  Personally I wish ITK had used
>>>>>> DCMTK from the start, since that includes all the networking and other
>>>>>> support.  But instead it started with GDCM, on the idea that it's lighter
>>>>>> weight and has support for things like jpeg2000 and then later added DCMTK
>>>>>> support too.  Since slicer delegates to ITK, there are some situations
>>>>>> where DCMTK is used and others where GDCM is used.
>>>>>>
>>>>>
>>>>>  Yes. GDCM and DCMTK seem to excell in orthogonal areas: GDCM on DICOM
>>>>> image reading and DCMTK on DICOM networking. So, I can see why ITK chose
>>>>> GDCM initially, because it is an image-focused toolkit.
>>>>>
>>>>> I would like to see more networking in GDCM, and more transfer
>>>>> syntaxes supported in the open DCMTK version :)
>>>>>
>>>>> Anywho, I would be happy to add both JPEG2000 and JPEG-LS to DCMTK.
>>>>>
>>>>> Cheers,
>>>>> Aaron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Sat, Feb 15, 2014 at 10:05 AM, Aaron Boxer <boxerab at gmail.com>wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I was wondering about types of compression supported by the slicer
>>>>>>> DICOM module.
>>>>>>> As you probably know, many DICOM images are compressed with JPEG
>>>>>>> 2000 compression. And I believe that DCMTK sells support for JPEG 2000,
>>>>>>> which leads me to believe that the slicer version of DCMTK does not support
>>>>>>> JPEG 2000.
>>>>>>>
>>>>>>> Is this the case? Because I have done some work on the OpenJPEG
>>>>>>> project, and I think I could integrate OpenJPEG support into the slicer
>>>>>>> DCMTK.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Aaron
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>

-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20140225/2b5b0093/attachment.htm>