YBR_FULL, YBR_FULL_422, YBR_PARTIAL_422
HSV
ARGB (retired, I know)
CMYK
Also, PALETTE_COLOR with more than 8-bits per color channel, or with
the segmented palette?
Thanks for your replies.
--
Craig Cornelius, Ph.D.
Chief Scientist
CEMAX-ICON, A Kodak Company
Sent via Deja.com http://www.deja.com/
Before you buy.
"Data validation for display failed: Photo Interpretation
[0028,0004] [=YBR_FULL_422] must be RGB for RGB images"
In article <8i8m9s$c31$1...@nnrp1.deja.com>, Craig
* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
The Acuson KinetDx system will keep the photometric interpretation of the
stored study regardless of the transfer syntax negotiated with the other
SCP. So if Sequoia images reside on the KinetDx PACS Server with a
photometric interpretation of YBR_FULL (The Sequoia and KinetDx server would
have negotiated RLE Lossless for Single Frame U/S when the study was first
stored), the study will retain that photometric interpretation even if the
transfer syntax negotiated with the other SCP is ILE (1.2.840.10008.1.2).
The result can be that a PACS server will store studies with a
photometric interpretation that the reading workstations do not
understand.
The DICOM Conformance Statements for Acuson products can be found at
http://www.acuson.com/dicom/index.html
Brian
"L. King" <lkingN...@sjmc.org.invalid> wrote in message
news:11a693c3...@usw-ex0109-069.remarq.com...
It is very important to understand the inter-relationship of
Photometric Interpretation and compressed transfer syntaxes.
Neither of the compression transfer syntax families in DICOM,
JPEG of any kind or RLE, specify the color space of the components
in the compressed bit stream.
Therefore it has to be specified in Photometric Interpretation.
Compressing color images (such as RGB) without first decorrelating
the color bands into a space like YCbCr is not very effective, so
everybody does this first. Most people assume that since tools
like the IJG JPEG code do this for you that it is specified or
require by the JPEG standard, but it is not. It is just conventional.
The bottom line here is as follows:
- all decompressed or uncompressed color images should normally be RGB
- all compressed color should normally be YBR_something
Under normal circumstances you will only see the YBR transfer syntaxes
on the wire or on media with one of the ultrasound media profiles
that supports RLE or lossy JPEG.
If a PACS or archive stores internally DICOM part 10 files in the
compressed form, then the transfer syntax will usually also be YBR something.
If the PACS or archive decompresses an inbound JPEG (or RLE) image
before storing it, and in this process remaps the color components
back to RGB space, which most decompressors do, then the Photometric
Interpretation should be set "back" to RGB.
Notice that it is vital that Photometric Interpretation be consistent
with what is actually stored in (7FE0,0010), because there is no other
way of signaling what is the color space of the color components.
I hope that the KinetDx referred to below that keeps the YBR_FULL
Photometric Interpretation is also keeping the color components
in the YBR space when regurgitating them in an uncompressed transfer
syntax (which is quite legal).
This was also so confusing that a CP was approved to address it:
ftp://medical.nema.org/medical/dicom/final/cp156_ft.pdf
HSV, ARGB and CMYK are never used in my experience, but could be used
in secondary capture objects, theoretically.
I have never actually seen a segmented palette image, but I guess
a DEFF image of that type converted literally into DICOM could
create one.
On the subject of funky palette color images, see also the CP from
the ultrasound group about this:
ftp://medical.nema.org/medical/dicom/final/cp143_ft.pdf
david
--
David A. Clunie mailto:dcl...@comview.com
Development Director, Medical Imaging Products http://www.comview.com/
ComView Corporation Work 914-332-4800 Fax 206-3566
220 White Plains Road, 5th Floor Home 570-897-7123 Fax 897-5117
Tarrytown NY 10591 http://idt.net/~dclunie/