Compressing DICOM Images
Andreas Schwind
Hello,
i have to write some software which should be able to compress
(existing) DICOM Images with a wavelet compression.
At the Moment i'm able to read a few DICOM Images and many other
File formats (like pgm, pnm, ...).
My question now is:
- Given a existing uncompressed DICOM Image:
which tags should i change, which ones could i leave as they are?
the tags (0028; 0010, 0011, 0101, aso.): Should they hold the
Information corresponding to the original image or to the
compressed image?
And which tags should hold the information of the other?
- Given an Image from an other file format:
Which tags MUST be set? (and with what values)
Same question as above.
In general:
I need a tag where i write in "WAVELET COMPRESSED" or something
like this, so that somebody who try to read it could see he isn't
able to do
this job.
Thanx a ot for answering my questions!
--
Andreas Schwind s_sc...@ira.uka.de
Yaman Aksu
Andreas Schwind wrote:
>
> Hello,
>
> i have to write some software which should be able to compress
> (existing) DICOM Images with a wavelet compression.
>
> At the Moment i'm able to read a few DICOM Images and many other
> File formats (like pgm, pnm, ...).
> ...
> In general:
> I need a tag where i write in "WAVELET COMPRESSED" or something
> like this, so that somebody who try to read it could see he isn't
> able to do
> this job.
>
> Thanx a ot for answering my questions!
> --
> Andreas Schwind s_sc...@ira.uka.de
I attended a meeting in Chicago early December in which the
issue of incorporating a type of wavelet compression
into DICOM was discussed. During the weeks following the
meeting, formal proposals were put together on this subject.
If in the near future wavelet compression is standardized
into DICOM, I thought this might be something you'd want
to follow closely.
If you wish to create your own wavelet compression
from DICOM images saved on storage media (the schemes
introduced in December worked with parts of the pixel
data coming through a DICOM transfer as opposed to all
of the pixel data found in an already stored Part 10 image),
then you probably can create your own private tag(s)
(in odd numbered groups) one of which you can assign the
value "WAVELET COMPRESSED" if you wish.
Yaman
--
Yaman Aksu ya...@sensor.com P: (703) 437 7651 ext.606
Sensor Systems, Inc. http://www.sensor.com F: (703) 437 0039
Dave Harvey
Andreas Schwind wrote in message <3504320D...@ira.uka.de>...
>i have to write some software which should be able to compress
>(existing) DICOM Images with a wavelet compression.
..
>
>My question now is:
>- Given a existing uncompressed DICOM Image:
> which tags should i change, which ones could i leave as they are?
> the tags (0028; 0010, 0011, 0101, aso.): Should they hold the
> Information corresponding to the original image or to the
>compressed image?
The _uncompressed_ image, as is done for JPEG compression etc.
> And which tags should hold the information of the other?
If you, again, follow the JPEG example, this should be within the
encapsulated data stream, rembering that you may use any format you like,
and that the _length_ of your data is defined by the fragment length(s).
(+/- 1 byte!)
>- Given an Image from an other file format:
> Which tags MUST be set? (and with what values)
> Same question as above.
This depends on the image source - the standard image IODs apply, and vary
by modality. If you can't fathom it out from the standard, get a copy of
the AGFA validation tool, and keep adding the elements that it tells you are
missing until you get no errors! (thought the current implementation
unfortunately doesn't support _any_ of the compressed pixel formats)
>In general:
> I need a tag where i write in "WAVELET COMPRESSED" or something
> like this, so that somebody who try to read it could see he isn't
>able to do
> this job.
No, what you need is a private transfer syntax, as your image would not
correspond to _any_ of the standard transfer syntaxes, and this is exactly
what private transfer syntaxes are for. This would normally define the
format to be explicit VR, little-endian, and expect your wavelet compressed
data.
This is all within the spirit of the standard, and allows your own
implmentations to read and write the data "officially" - my only question is
why bother with DICOM when you will not have useful compatability :-)
Dr David Harvey
Medical Connections (med...@dial.pipex.com)
Fax: +44 1792 234938
http://ds.dial.pipex.com/medconn
Andreas Schwind
Hello,
Dave Harvey wrote:
> Andreas Schwind wrote in message <3504320D...@ira.uka.de>...
>
> If you, again, follow the JPEG example, this should be within the
> encapsulated data stream, rembering that you may use any format you like,
> and that the _length_ of your data is defined by the fragment length(s).
> (+/- 1 byte!)
- 1byte? Why -? I thougt + takes much more sense...
> This is all within the spirit of the standard, and allows your own
> implmentations to read and write the data "officially" - my only question is
> why bother with DICOM when you will not have useful compatability :-)
Good question. I'll ask me boss :-) No, seriously:Of course i want
compatibillity with DICOM, and compressing DICOM files
isn't the whole job of my software. We get images from different sources, and
not
all of them uses DICOM, but we want to store all images as DICOM images.
And cause we haven't infinit disk space :-) we decide to compress the images.
So, because we developed a library for wavelet compression a few time ago,
we decide to use wavelet compression. But thats not described in standard out
now,
i have to create some own settings...
Ok, thnx a lot for helping!
Bye,
--
Andreas Schwind s_sc...@ira.uka.de
Eric Goodall
Andreas Schwind wrote:
> Hello,
>
> i have to write some software which should be able to compress
> (existing) DICOM Images with a wavelet compression.
>
> At the Moment i'm able to read a few DICOM Images and many other
> File formats (like pgm, pnm, ...).
>
> My question now is:
> - Given a existing uncompressed DICOM Image:
> which tags should i change, which ones could i leave as they are?
> the tags (0028; 0010, 0011, 0101, aso.): Should they hold the
> Information corresponding to the original image or to the
> compressed image?
> And which tags should hold the information of the other?
> - Given an Image from an other file format:
> Which tags MUST be set? (and with what values)
> Same question as above.
>
> In general:
> I need a tag where i write in "WAVELET COMPRESSED" or something
> like this, so that somebody who try to read it could see he isn't
> able to do
> this job.
>
If you don't change columns and rows, no reason to change (0028,0010),
(0028,0011). Bits stored is a bit trickier given the way that data
compression people sometimes talk about their algorithms, best bet is
just to leave it the same too (unless of course you explicit re-quantize
the data). If you have changed them, by all means let the tags reflect
the modified image. As for indicating that you have compressed using
wavelet. You should request and use a private tag for a transfer syntax.
If and when DICOM assigns a transfer syntax for your personal wavelet
algorithm, you can always change the value to the public UID.
In addition to the transfer syntax for the pixels, there are a few more
standard DICOM tags that you could use to notify users of the
compression. They are type 3 attributes so not every viewer is going to
support showing them in an obvious manner. On the other hand, if you put
them into the image, they will be there for the dilligent user that goes
looking for them.
I would suggest you look at the type 3 tags in the General Image Module
attributes
Source Image Sequence (0008,2112) - contains the sop class uid and sop
instance uid of the original source image. If you've changed something
from the original, they can always go find it an compare.
Lossy Image Compression (0028,2100) = 01 to indicate image has been
subjected to lossy image compression. Many viewers will respect this
tag and display it in an obvious manner in the user interface. Although
they won't neccesarily say "wavelet compressed" it will be marked as
having lost information in the compression.
Derivation Description (0008,2111) - text description of how this image
was derived (to me, this sounds like a fine place to put "Wavelet
Compressed", maybe even some references to the algorithm and parameters
used).
--Eric Goodall
David Clunie
> Andreas Schwind wrote:
> > My question now is:
> > - Given a existing uncompressed DICOM Image:
> > which tags should i change, which ones could i leave as they are?
As Eric points out, there are a few attributes that can be
added to indicate that the image, once decompressed, has
undergone lossy compression, and where it came from.
However all the other attributes should remain the same
since the image will still be of the same SOP Class once
decompressed. This includes those attributes that describe
the decompressed pixel data, presuming of course that your
compression algorithm decompresses to an image with the
same kind of characteristics as the source image (this is
sort of assumed in DICOM). The compression process is
always considered to be at the transfer syntax (ie.
presentation) level.
> > - Given an Image from an other file format:
> > Which tags MUST be set? (and with what values)
You have to make a valid SOP Instance of some SOP Class,
and which attributes you need depends on that. The least
amount of effort is required to make an SC SOP Class. See
Part 3.
> > I need a tag where i write in "WAVELET COMPRESSED" or something
There isn't a standard tag for this yet. A coded sequence
for this sort of thing is proposed in DX supplement 32 but
it isn't standard yet.
Eric Goodall wrote:
> If you don't change columns and rows, no reason to change (0028,0010),
> (0028,0011). Bits stored is a bit trickier given the way that data
It sounds likely that rows, columns, bits allocated and
stored, etc. should be the same as they were before the
compression/decompression cycle.
> wavelet. You should request and use a private tag for a transfer syntax.
Indeed you need a private UID for your private transfer syntax.
You also of course need a UID root in order to create SOP
Instances in the first place (NEVER EVER reuse the SOP Instance
UID of the source image after it has been lossy compressed).
You need to get such a root from an ISO member body (see the
FAQ) and then develop some local strategy for assigning
these below this root.
david clunie
Eric Goodall
>
>
> > > I need a tag where i write in "WAVELET COMPRESSED" or
> something
>
> There isn't a standard tag for this yet. A coded sequence
> for this sort of thing is proposed in DX supplement 32 but
> it isn't standard yet.
>
David,
The Derivation Description is a standard tag, albeit one with a rather
vague definition as to what should go into it. Application of lossy
compression algorithm fits my definition of a "derivation" and is listed
as one of the examples for the Derivation Description..
When it is needed, more information is better; but DICOM already has a
plethora tags which cover some superset of situations that have been
partially obsolesced by newer, more specific tags and sequences.
Certainly no one would argue the lossy compression ratio and algorithm
parameters are not needed. But it would be helpful if the standards
committee updated the definition of Derivation Description to
specifically exclude information that should be put in the new
compression tags.
Also, I find it a bit odd that new tags are being added to the General
Image Attributes Module under the aegis of a supplement for Digital
X-ray. Such an update would affect all the image storage SOP classes,
not just the new one. Without your posting, I would never had thought to
go look in the supplement for those updates to the General Image Module.
Isn't a correction proposal a better vehicle for introducing the new
tags that apply across multiple SOP classes?
Eric Goodall
Eric Goodall
Eric Goodall wrote:
> But it would be helpful if the standards
> committee updated the definition of Derivation Description to
> specifically exclude information that should be put in the new
> compression tags.
Skimmed to quickly. The notations are there. Apologies
--Eric
David Clunie
Eric Goodall wrote:
> Also, I find it a bit odd that new tags are being added to the General
> Image Attributes Module under the aegis of a supplement for Digital
> X-ray. Such an update would affect all the image storage SOP classes,
> not just the new one. Without your posting, I would never had thought to
> go look in the supplement for those updates to the General Image Module.
> Isn't a correction proposal a better vehicle for introducing the new
> tags that apply across multiple SOP classes?
This has been conventional practice for some time.
Whenever a new modality specific IOD is created, if it needs
specific attributes added, but they might be useful for other
existing or future IODs, they are often added as Type 3 to
a general module, and then specialized in the new modality
specific module.
For example, when XA and XRF were added, the Lossy Compression
attribute was added as 1C to the X-Ray Image module, but also
put in as a 3 in the General Image module, since it didn't force
existing implementations to behave differently (similar to a
Standard Extended SOP Class if you like) but it did allow new
implementations of old IODs, as well as future IODs, to make
use of it.
This is considered an important mechanism for ensuring consistency
as new IODs are added, to prevent each new IOD doing the same
thing in a different way.
It is not done separately in a CP if the Supplement itself
depends on it, because they are ballotted separately and timing
issues or ballot failure might mean that a new feature was
added to the standard without something else it depends on
to be implementable. It all has to go in one supplement.
Bottom line is it is very important to peruse every new supplement
even if it doesn't seem to directly apply to one's own work, just
to make sure there is nothing subtle going on that will affect you.
Such additional scrutiny is also very useful to help the DICOM Working
Group members, who don't have unlimited bandwidth and sometimes
don't catch every inconsistency.
david
--
David A. Clunie (david....@med.ge.com)
GE Medical Systems - Global System Connectivity Platform
PO Box 414, SN-475, Milwaukee WI 53201
Voicemail 1-800-525-1516 #153652