Google 網路論壇不再支援新的 Usenet 貼文或訂閱項目,但過往內容仍可供查看。

JPEG-LS and DICOM

瀏覽次數:135 次
跳到第一則未讀訊息

Ron K.

未讀,
2001年2月23日 晚上9:39:162001/2/23
收件者:
I have been investigating the use of JPEG-LS for lossless
DICOM compression. A few technical requirements needed to support
newer/larger DICOM images formats seem to be missing
from the specifications and source code:

Specifically the support for multi-frame/slices of images.
It seems that there is no built in support for compression
of multi-frames of images (I would assume that images do
not change much between frames and that JPEG-LS would
have a simple compression mechanism of storing the
differences between frames).

I have been playing around with just increasing the
number of rows by multiplying by the number of frames...
this works somewhat but I have found a 16-bit or 65536
row limitation in the JPEG-LS standard code I am using.

These limitations seem to eliminate the possibility of using
JPEG-LS for any large DICOM CINE loops or multi-slice
modalities. Are there alternatives... have I missed something?


Regards,
Ron K.


David Clunie

未讀,
2001年2月24日 中午12:43:142001/2/24
收件者:
Hi Ron

Here is a somewhat long response that hopefully addresses
your question and raises some other issues:

JPEG-LS, like JPEG (10918-1) and JPEG 2000 Part 1 (15444-1)
is a single image compression standard.

In DICOM, individual frames of a multi-frame image are
compressed using one of these standard schemes (or RLE)
completely independent of each other, and then encapsulated
in "fragments" (similar to sequence item tags).

This is similar to the use of de facto standards like
"motion-JPEG" as opposed to true motion compression schemes
like one of the MPEG standards.

In other words, unlike MPEG, none of the JPEG series of
standards have any way of encoding the "difference between
frames" as you suggest.

Concatenating multiple frames into large images, either as
a long thin one as you suggest or as some sort of tiled
array, doesn't help compression much using either JPEG or
JPEG-LS, since the former is block based and the latter is
locally predictive and adaptive. In JPEG one might save a
few bytes in transmitting the quantization and Huffman
tables only once, but this is a very small gain.

With full-frame frequency domain or wavelet transform techniques
there can be some savings with the concatenation approach, but
this may be offset by ridiculously large memory requirements.
JPEG 2000 has a built-in tiling mechanism to anyway to keep
memory requirements down which will of course defeat any effort
to concatenate frames.

Regardless, JPEG-LS can be used for cine images, small or large,
just as JPEG can, and one gets the same dramatic (?) improvement
in lossless compression as one does for single frame images. It
is also feasible for real-time software implementation since it
is a very simple scheme.

BTW. JPEG-LS is not limited to 2^16-1 rows ... there is an
"oversize image" mechanism in the LSE marker that permits
specifying larger images, though I don't know how many
implementations support it (I don't think mine does). The
actual limit is 2^32-1 rows (and columns).

Obviously, if inter-frame correlation is to be taken advantage
of one, should consider a compression scheme that either supports
prediction between frames, like one of the MPEG standards, or
that has a transform in more than 2 dimensions, like some of
the extensions proposed in JPEG 2000 Part 2 for 3D and hyper-
spectral data.

For cine images, MPEG-style motion prediction may be of some
advantage. For 3D CT and MR data sets, MPEG motion prediction
doesn't help and a JPEG 2000 Part 2 style wavelet transform in
the third dimension may gain some 30% better (lossless) compression
than compressing individual images alone.

Why has MPEG not been introduced as a DICOM transfer syntax (yet) ?

Well, the cardiac group decided that lossless motion-JPEG would do.
Evaluation of lossy motion-JPEG in the ACC study showed some limits
wrt. quantitative coronary angiography at quite modest bit-rates.
This rather put people off lossy compression for cardiac angio
and since there is no lossless form of MPEG, there has been little
further interest, especially since with faster software and CD drives,
real-time playback off the CD is feasible with the lossless motion
JPEG used in DICOM.

What about echocardiography, the other big area of multi-frame compression
interest ?

Well, so far vendors have been happy with lossy motion-JPEG, which has
been well tested against S-VHS tape in the literature. Some interest has
been shown in MPEG and H.263 for tele-echocardiography solutions. WG 12
(Ultrasound) has had a workitem open to develop an MPEG transfer syntax
but there has been slow progress. The issues seem to be reluctance to
adopt something where the need is already met in the installed base
by motion-JPEG, the limited effectiveness of MPEG on ultrasound images
(due to noise and ineffective motion prediction), the difficulty of
software implementation in embedded systems and the lack of low cost
MPEG2 hardware until very recently, etc. There are also intellectual
property issues with the encoding side of MPEG.

WG 12 is also discussing using JPEG 2000 for compression of still and
multi-frame images, and it will be interesting to hear the results of
their experiments. Real-time playback of JPEG 2000 multi-frame images
will probably be a struggle to start with, but for modest size 8 bit
per channel RGB images, presumably the digital camera vendors will
provide chips.

While there is a general reluctance to include too many compression
transfer syntaxes in the standard, there is recognition that some
applications are better suited to one scheme rather than another, and
that when there are substantial gains in performance the risk to
interoperability with the installed base needs to be balanced against
the need for progress.

Wrt. JPEG 2000 by the way, the current proposal is to include the
Part 1 capabilities (which it is hoped will soon be a popular
consumer standard, driven be digital camera vendors), and to watch
closely the development of Part 2 extensions, especially the third
dimension transform, which could conceivably be added as another
transfer syntax in the future.

The desire to use JPEG 2000 is not that it compresses better than
JPEG (it doesn't, at modest bit-rates, if JPEG is well optimized),
but rather that there are many desirable new features in JPEG 2000,
such as progressive contrast or spatial resolution to lossless,
selective choice of bit-rate by region-of-interest, etc.

david
--
David A. Clunie mailto:dcl...@comview.com
Development Director, Medical Imaging Products http://www.comview.com/
ComView Corporation Work 914-332-4800 Fax 208-445-5867
220 White Plains Road, 5th Floor Home 570-897-7123 Fax 570-897-5117
Tarrytown NY 10591 http://www.dclunie.com/

0 則新訊息