AVI Encapsulation - Transfer Syntax?

[Matthias Wild]

Hello there!

 

We have realized a file compression feature in our own DICOM PACS.

What we did is compressing a dicom multiframe file to a Windows AVI

Stream. After this we write the AVI stream back into to the pixel data

tag of the dicom file. 

 

This results to a DICOM file which pixel data are an Windows AVI:

 

- easy to use for play back just copy the data into a file and start windows-media-player.

- smaller than DICOM.

- no DICOM data lost (Patient Name, Patient ID, ...) with respect to an ordinary AVI.

 

Yes, lower pixel quality but some advantages in our opinion.

 

Now the questions is. Is anybody out there who did something similar? I think should be.

And when we are doing the same than we should use only one transfer syntax for our DICOM

files.

 

Hello Mr. Clunie :),

 

is there an official way to get a transfer syntax for a special pixel data encapsulation.

MPEG will be another good compression methode.

 

Sincerely,

Matthias

+---------------------------------------------------------+
Company: Quazar Software GmbH
Street : Hoheluftchaussee 108
City   : 20253 Hamburg
Country: Germany
Contact: Matthias Wild
Phone  : +49-40-480653-0 (11)
Fax    : +49-40-480653-290
Mobil  : +49-177-4009640
Web    : http://www.quazar.de
E-Mail : wi...@quazar.de
+---------------------------------------------------------+

[David Clunie]

MPEG is being considered by WG 12 at the present time. The
work is not progressing very quickly.

As far as I know, AVI is not really a compression scheme but
a file format and may use different codecs (just like Quicktime).
As such it is not really a candidate for a transfer syntax,
even if there were the interest.

Selecting a particular codec and creating a transfer syntax
for that would be theoretically feasible, and then one could
even find a way to create a "dual personality" file that
was both a valid RIFF (AVI) and DICOM file, much like can
be done with TIFF.

However, the fragment item boundaries are a potential source
of problems.

The current use of motion-JPEG seems sufficient for most
people's applications at present, which is why there has
been little interest in video compression.

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://idt.net/~dclunie/

[Matthias Wild]

Dear Mr. Clunie,

of course you are right if you say AVI is a file format not
a compression scheme. Our transfer syntax should only
say pixel data are an AVI stream (a complete RIFF file). All the
AVI related stuff (especially codecs) are not known by the
DICOM world. They are defined within the AVI data itself. Just
copy out the data from the tag and run "Windows Media Player"
to view it. Pretty simple.
To make it easy like that, we don't use any frame fragment
encapsulation. The AVI data are written to the pixel data tag as is.
No basic offset table. No fragment items. Just the data stream.

Sincerely,
Matthias Wild

BTW: The transfer syntax we use is "1.2.840.10008.1.2.0.1".

"David Clunie" <dcl...@idt.net> schrieb im Newsbeitrag
news:399DBC77...@idt.net...

[David Clunie]

You must but use a transfer syntax beginning with
"1.2.840.10008" ... only NEMA can assign UIDs with
such a root.

You need to use your own organization's UID root as the
basis for your private transfer syntax UID.

david