C-GET, JPEG transfer syntax, was Re: [pixelmed_dicom] YBR_FULL_422/uncompressed
- View Source
> You mentioned inDave Harvey and I just discussed this (we happen to both be at the
> q=YBR_FULL_422&rnum=7#5bb84e7b7a1678bb that YBR_FULL_422 should only
> be used with compressed data. So if I receive an uncompressed dicom
> file back from a PACS then there shouldn't be YBR_FULL_422 as
> Photometric Interpretation or am I wrong? Dave Harvey
> (http://www.dicomserver.co.uk/) tells me that uncompressed with
> YBR_FULL_422 is a valid combination.
same meeting in Madrid), and strictly speaking he is correct ...
YBR_FULL_422 is indeed a valid Photometric Interpretation, and there
is an explanation in PS 3.5 as to how to actually encode this;
however, I am not sure that this is the "best" choice to return and I
would personally rather see decompressed RGB returned since that is
much more likely to be usable by a viewer, though as Dave points out,
more bytes will be transferred. His server can apparently be
configured either way with a flag, but his public test server is
configured to return YBR_FULL_422 for testing purposes (which is cool
because then we can make test images using it).
This is essentially a weakness in the standard, which does not specify
what should be returned in terms of choices of Photometric
Interpretation when decompression is forced through choice of transfer
syntax. Personally, it never occured to me before that anyone would
not send RGB. Dave and I will think about a CP to address this.
PS. Needless to say, the pixelmed toolkit currently does not support
viewing of uncompressed YBR_FULL_422 images; I will put this on the
list of feature requests.
- View SourceHi David
Thanks a lot for your answer. Now I think, that I'm understanding the
problem. Sometimes it's not easy to know where the reason of a problem