dcm4che 3.2.0 released

[gunterze]

I just released dcm4che 3.2.0 at https://sourceforge.net/projects/dcm4che/files/dcm4che3/3.2.0/ .

It now supports also
- generating IHE ATNA compliant audit messages and sending via UDP or TLS SYSLOG
- image rendering
- image compression/decompression

For a complete change log see: http://www.dcm4che.org/jira/secure/ReleaseNote.jspa?projectId=10322&version=10690

Compression/Decompression relies on JAI-IMAGE-IO 1.2, which binaries are included.

Because JAI-IMAGE-IO does not support Windows 64-bit and MAC OS X, dcm4che 3.x will not support compression/decompression for such platforms.

You may replace the use of JAI-IMAGE-IO by any other Image Reader/Writer supporting JPEG 12-Bit Extended, JPEG LossLess, JPEG LS or JPEG 2000 by specifiying your own Transfer Syntax -> Image IO Reader/Writer mapping files by System properties

-Dorg.dcm4che.imageio.codec.ImageReaderFactory=<URL of mapping file>
-Dorg.dcm4che.imageio.codec.ImageWriterFactory=<URL of mapping file>

Unfortunately I am not aware of any open-source Image IO Reader/Writer beside JAI-IMAGE-IO for JPEG 12-Bit Extended, JPEG Loss Less, JPEG LS or JPEG 2000. I think/hope, it would not be much work to wrap existing open-source native codec implementations for JPEG 12-Bit Extended (already supported by IJG used by openjdk, but not exported by JDK JPEG Image IO Reader/Writer), JPEG Loss Less (IJG with ls-patch) and JPEG LS (CharLS) and provide it in future versions of openjdk.

I am afraid, I will not find time for implementing such Image IO Reader/Writer wrappers in the foreseeable future: My company already implemented some wrappers for Accusoft Pegasus JPEG codec implementations for use in our dcm4che based proprietary products, so they have little interest in spending time in development of an open-source alternative.

gunter

[Aaron Boxer]

Great, I have been looking forward to this for a while.

It should be pretty straightforward to wrap OpenJPEG. 

Do you have an ETA for a web admin interface?  

Does DICOM have a standard for administering a PACS server? 

Aaron

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[gunterze]

On Wednesday, June 5, 2013 4:45:14 PM UTC+2, Aaron Boxer wrote:

Great, I have been looking forward to this for a while.

It should be pretty straightforward to wrap OpenJPEG. 

Do you have an ETA for a web admin interface?  

There is already a wicket based web application ( https://github.com/dcm4che/dcm4chee-wizard ) for editing the configuration of general DICOM devices and for a DICOM proxy application ( https://github.com/dcm4che/dcm4chee-proxy ), which will be released in coming weeks. The plan is to extend this web application to be useable also for dcm4chee-archive specific configuration parameters, hopefully during next 3 months.

For administration tasks beyond archive configuration I plan to provide RESTfull Services for use by otherwise independent web application(s). I will start implementing RESTfull Service already specified/drafted by DICOM:

Supp 161: WADO by means of RESTful Services (Standard)
Supp 163: Store Over the Web by RESTful Services (STOW-RS) (Draft)
Supp 166: Query based on ID for DICOM Objects by RESTful Services (QIDO-RS) (Draft)

Does DICOM have a standard for administering a PACS server? 

Just about how to read/write/update DICOM related configuration parameters in a LDAP server:

Part 15, Annex H.1 APPLICATION CONFIGURATION MANAGEMENT PROFILE
 

gunter

[Aaron Boxer]

Thanks, Gunter.  Are you familiar with Orthanc 

https://code.google.com/p/orthanc/ ?

This is an open source REST interface to a DICOM server (C++ with DCMTK).

It might give you some ideas for the QUIDO and STOW implementations.

Also, I notice that reducing memory consumption was one of the primary design focuses

when building dcm4che 3. Is it possible to specify a fixed buffer when compressing/decompressing?

I used this trick when hacking the clear canvas viewer, and it dropped memory thrash in the VM by

an order of magnitude. 

Cheers,

Aaron

[Aaron Boxer]

I have just finished upgrading/fixing the java wrappers for openjpeg 2.0 compression/decompression.

With openjpeg support, dcm4che would have native jpeg2000 support on all majour platforms.

Now, I would like to integrate it with dcm4che 3.2.  Any advice on how to go about doing this?

I see gunter's comments about changing the Transfer Syntax to Image IO Reader/Writer mappings,

but I am not familiar with the Image IO or JAI Image IO libraries. And, my impression is that they are abandoned.

I did find this interesting project on github that supports additional JAI Image IO plugins and extensions:

https://github.com/geosolutions-it/imageio-ext/

This has support for kakadu jpeg2000. How could this be integrated into dcm4che?

Thanks,

Aaron

On Wed, Jun 5, 2013 at 7:15 AM, gunterze <gunt...@gmail.com> wrote:

[nicolas...@gmail.com]

On Sunday, July 7, 2013 8:39:39 PM UTC+2, Aaron Boxer wrote:

I have just finished upgrading/fixing the java wrappers for openjpeg 2.0 compression/decompression.

 

Did you use the Java Wrapper in the OpenJPEG sources? because it is outdated.

With openjpeg support, dcm4che would have native jpeg2000 support on all majour platforms.

Now, I would like to integrate it with dcm4che 3.2.  Any advice on how to go about doing this?

I see gunter's comments about changing the Transfer Syntax to Image IO Reader/Writer mappings,

but I am not familiar with the Image IO or JAI Image IO libraries. And, my impression is that they are abandoned.

Yes it is abandoned but the core mechanism of imageIO is in the JVM (in javax.imageio.*). You must, for an image decoder, create a class that extends the class ImageReaderSpi and ImageReader, and register ImageReaderSpi in IIORegistry. The same for the encoder with ImageReaderWriterSpi and ImageReaderWriter. For JPEG200, image tiling should be implemented in the reader and the writer with RenderedImage.
 

I did find this interesting project on github that supports additional JAI Image IO plugins and extensions:

https://github.com/geosolutions-it/imageio-ext/

This has support for kakadu jpeg2000. How could this be integrated into dcm4che?

imageio-ext provides the GDAL interface for kakadu, but not the library which is proprietary and requires a license. In addition, if it has not changed, the Java wrapping can only have a file as an input, not a stream. However, now with dcm4che3 and bulk data, it will be easier to have in a separated jpeg2000 file.

[Aaron Boxer]

Thanks, Nicolas.

On Sunday, July 7, 2013 8:39:39 PM UTC+2, Aaron Boxer wrote:

I have just finished upgrading/fixing the java wrappers for openjpeg 2.0 compression/decompression.

 

Did you use the Java Wrapper in the OpenJPEG sources? because it is outdated.

I have updated the wrapper to work with 2.0. Also, fixed a few small memory leaks there.

I tested decompression on a number of images, using a simple java viewer to inspect

the results. The viewer uses the jni wrapper.

 

With openjpeg support, dcm4che would have native jpeg2000 support on all majour platforms.

Now, I would like to integrate it with dcm4che 3.2.  Any advice on how to go about doing this?

I see gunter's comments about changing the Transfer Syntax to Image IO Reader/Writer mappings,

but I am not familiar with the Image IO or JAI Image IO libraries. And, my impression is that they are abandoned.

Yes it is abandoned but the core mechanism of imageIO is in the JVM (in javax.imageio.*). You must, for an image decoder, create a class that extends the class ImageReaderSpi and ImageReader, and register ImageReaderSpi in IIORegistry. The same for the encoder with ImageReaderWriterSpi and ImageReaderWriter. For JPEG200, image tiling should be implemented in the reader and the writer with RenderedImage.

Thanks. I notice that Weasis has a kakadu image reader spi. Perhaps I can repurpose this to use openjpeg.

 

 

I did find this interesting project on github that supports additional JAI Image IO plugins and extensions:

https://github.com/geosolutions-it/imageio-ext/

This has support for kakadu jpeg2000. How could this be integrated into dcm4che?

imageio-ext provides the GDAL interface for kakadu, but not the library which is proprietary and requires a license. In addition, if it has not changed, the Java wrapping can only have a file as an input, not a stream. However, now with dcm4che3 and bulk data, it will be easier to have in a separated jpeg2000 file.

Good to know. Thanks again.

[nicolas...@gmail.com]

Two years ago, I tried to use imageio-ext with the kakadu wrapper in Weasis but I haven't released this code because the reader and writer only handle j2k files. That means when you are reading a local DICOM file, you always need to extract the image in a file before reading it. However, with dcm4chee3 it will be easier to extract the image in a file.

With OpenJEPG 2.0, it is possible to handle a stream instead of a file, but it is not implemented in the current Java Wrapper. I start of doing this job for making a JPEG-LS wrapper (with charls lib) but unfortunately I haven't much time for that.

I also adapted Weasis to support JPIP but the problem is the JPIP client uses fastcgi and I haven't analyzed how this part could be integrated in Weasis. I asked the developers for having a JPIP client without system dependencies.

[Aaron Boxer]

On Tue, Jul 9, 2013 at 4:57 AM, <nicolas...@gmail.com> wrote:

Two years ago, I tried to use imageio-ext with the kakadu wrapper in Weasis but I haven't released this code because the reader and writer only handle j2k files. That means when you are reading a local DICOM file, you always need to extract the image in a file before reading it. However, with dcm4chee3 it will be easier to extract the image in a file.

Interesting. Are you thinking of releasing your code along with dcm4chee 3?

 

With OpenJEPG 2.0, it is possible to handle a stream instead of a file, but it is not implemented in the current Java Wrapper. I start of doing this job for making a JPEG-LS wrapper (with charls lib) but unfortunately I haven't much time for that.

I have implemented streaming from memory in the java wrapper, on my branch on github

https://github.com/OpenRadStack/openjpeg/tree/java_viewer

This repo is a nightly mirror of the openjpeg svn repo, along with my own java branch.

 

I also adapted Weasis to support JPIP but the problem is the JPIP client uses fastcgi and I haven't analyzed how this part could be integrated in Weasis. I asked the developers for having a JPIP client without system dependencies.

I think JPIP support would be very interesting; improving user experience.

 

On Tuesday, July 9, 2013 4:22:59 AM UTC+2, Aaron Boxer wrote:

Thanks, Nicolas.

On Sunday, July 7, 2013 8:39:39 PM UTC+2, Aaron Boxer wrote:

I have just finished upgrading/fixing the java wrappers for openjpeg 2.0 compression/decompression.

 

Did you use the Java Wrapper in the OpenJPEG sources? because it is outdated.

I have updated the wrapper to work with 2.0. Also, fixed a few small memory leaks there.

I tested decompression on a number of images, using a simple java viewer to inspect

the results. The viewer uses the jni wrapper.

 

With openjpeg support, dcm4che would have native jpeg2000 support on all majour platforms.

Now, I would like to integrate it with dcm4che 3.2.  Any advice on how to go about doing this?

I see gunter's comments about changing the Transfer Syntax to Image IO Reader/Writer mappings,

but I am not familiar with the Image IO or JAI Image IO libraries. And, my impression is that they are abandoned.

Yes it is abandoned but the core mechanism of imageIO is in the JVM (in javax.imageio.*). You must, for an image decoder, create a class that extends the class ImageReaderSpi and ImageReader, and register ImageReaderSpi in IIORegistry. The same for the encoder with ImageReaderWriterSpi and ImageReaderWriter. For JPEG200, image tiling should be implemented in the reader and the writer with RenderedImage.

Thanks. I notice that Weasis has a kakadu image reader spi. Perhaps I can repurpose this to use openjpeg.

 

 

I did find this interesting project on github that supports additional JAI Image IO plugins and extensions:

https://github.com/geosolutions-it/imageio-ext/

This has support for kakadu jpeg2000. How could this be integrated into dcm4che?

imageio-ext provides the GDAL interface for kakadu, but not the library which is proprietary and requires a license. In addition, if it has not changed, the Java wrapping can only have a file as an input, not a stream. However, now with dcm4che3 and bulk data, it will be easier to have in a separated jpeg2000 file.

Good to know. Thanks again.

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.

Visit this group at http://groups.google.com/group/dcm4che.

[Arnold Maderthaner]

hi aaron !

Any update on that or what your plans are for replacing imageio ?

yours

Arnold

[Aaron Boxer]

Hi Arnold,

Unfortunately, I've put this on hold, but it wouldn't take much effort to complete.

I have a java wrapper, I just need to hook it up to the imageio frame

One issue I had was that the jpeg2000 implementation I was going to use - openjpeg - seems to be have become inactive: two checkins since april of this year.

And nobody responds to google group questions.  So I got a bit discouraged about using this project.

I still would like to finish this eventually.

Cheers,

Aaron

[Arnold Maderthaner]

are there any other good jpeg/jpegLS/jpeg2000 lossless/lossy open source implementations ?

[Aaron Boxer]

one of the challenges is getting 12 bit support. 

For jpeg, there is the turbo jpeg library, which uses SIMD acceleration, but

it doesn't support 12 bit. So, you need to use the original JPEG group implementation,

which I understand is not very optimized.

 For jpegLS, there is CharLS.  http://charls.codeplex.com/  

Jpeg2000 -  there is JasPer http://www.ece.uvic.ca/~frodo/jasper/ but I understand it is buggy and slow.

I am mirroring some of these projects here:

https://github.com/CodecCentral

[nicolas...@gmail.com]

Hi Arnold,

There are not a lot of projects, for jpeg2000 I know only openjpeg, the initial implementation in pure java (jj2000.j2k in jai_imageio.jar) and the jasper implementation (native imageio is based on, but old). So, I think openjpeg is only way to have a native library with a good level of implementation (because jpeg2000 specifications are large).

The following syntaxes exist only on OS which have the native imageio library (win32, Linux 32 and 64-bit and Solaris):

    1.2.840.10008.1.2.4.51  JPEG Extended (Process 2 & 4): Default Transfer Syntax for Lossy JPEG 12 Bit Image Compression (Process 4 only)

    1.2.840.10008.1.2.4.57  JPEG Lossless, Non-Hierarchical (Process 14)

    1.2.840.10008.1.2.4.70  JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression

    1.2.840.10008.1.2.4.80  JPEG-LS Lossless Image Compression

    1.2.840.10008.1.2.4.81  JPEG-LS Lossy (Near-Lossless) Image Compression 

I've started a project to handle those syntaxes on all the operating systems. The problem is that pure java decoders or encoders will be to slow. So it requires to wrap native libraries with jni. I've already done a wrapper for JPEG_LS lossless and lossy with the charls project (I think the best implementation of jpeg-ls). This wrapper is a bit faster than the one in the native imageio library. It can work with dcm4che3 and Weasis. There is a special profile to build it for dcm4che3 because the registering mechanism of the library is different from Weasis. In dm4che3, the wrapper is registered by Java Service Provider Interface (SPI) in imageio and the native lib must be dropped in the lib directory related to the OS. Weasis uses OSGI service mechanism (bundle fragment, allow to download only the native lib of the current running system). The wrapper supports to manipulate RenderedImage and BufferedImage.

I also started the wrapper for the other JPEG syntaxes, but I faced some problems when building the 3 jpeg libraries (required 8, 12 and 16-bit) and linking them with CMAKE. There is also the turbo-jpeg library but it can be only compile for 8-bit images. 

As my knowledge in CMake and building native libs are quite limited, any help is welcome (please contact me).

[Marco Kuballa]

Hi Nicolas,

sounds great...is your wrapper implemented as an open source project? I'm very interested in your JPEG-Lossless Codec running on a 64-Bit Windows system.

Regards

[nicolas...@gmail.com]

The wrapper is now supporting all the jpeg syntaxes mentioned above for reading DICOM. It has been tested on Windows, Mac and Linux. The wrapping of the openjpeg (jpeg2000) library is an on-going development. The JPEG-LS wrapping gives good reading performance while openjpeg wrapping is slower than the native implementation of Sun in JAI (derived from jasper implementation).

A this stage the wrapper is targeted only for Weasis and dcm4che. Unfortunately I cannot assume the support of the wrapper in a general context and the cross compilation is a complex process, so I will not provide as a open source project for the moment.

[Emanuel Hillberg]

Same as mk.

Very interested in functionality making it possible to use JPEG-Lossless Codec on an 64bit windowsbased system.

Is there any possibility to be included in some kind of testing? : ) Would be more than happy to try it out.

[Nicolas Roduit]

Yes but to be included in dcm4che3 (and dcm4chee-arc4) it still need some adaptions for transcoding and for color model conversions. If you need only for reading all the jpeg syntaxes, it should be possible to test it.

[Emanuel Hillberg]

Dear Nicolas, 

Im not sure.

Have trouble retrieving studies stored with JPEG Lossless *.70 (The old system was 32 bit when they where stored, and since then migrated to 64 bit.)

So do I then just need it for reading syntaxes? 

regards Emanuel

[Nicolas Roduit]

You can install a 32-bit JRE, it is a workaround meanwhile running new decoders.

You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/kxoryXjsidw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.

To post to this group, send email to dcm...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che.

For more options, visit https://groups.google.com/d/optout.