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

Tue Feb 25 23:35:14 UTC 2014

Hi Aaron et al.,

Looking at the topic named "j2k" [1], I noticed that you backported the
change originally implemented by Osirix folks [2]

Few ideas:

 1) Checking the osirix history, there are also more general bug fixes that
could probably be contributed to upstream DCMTK. We should probably look
into these.

 2) Based on Michael answer [3], I don't think they would be against
integrating support for Jpeg2k. @Michael: Assuming we also add test
validating the proper integration, would you be up to consider upstream
integration ?

 3) Waiting change are pushed into the official upstream DCMTK, may be CTK
and Osirix folks could share a common repository ?

Let me know what you think,

Thanks
Jc

[1] https://github.com/OpenRadStack/dcmtk/commits/j2k

[2] https://github.com/pixmeo/osirix/commits/develop/Binaries/dcmtk-source

[3] http://slicer-devel.65872.n3.nabble.com/JPEG-2000-tp4030949p4030965.html

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

> 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
>

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