Hello everyone,
I've received a number of dcm files on CD that look like legitimate DICOM, valid metadata and all, but I can't interpret the pixel data. They are fuji cardio US images with a standard UltrasoundImageStorage SOP class and JPEG Lossless Process 14 TS.

I've tried on several viewing programs and none of them can display the images. Only the CD included viewer works to read them, but there is no option to export. Anyone have ideas on what type of encoding this could be? The Implementation Version Name element indicates "EPIQ-AFFIN_5.00"...

Many thanks!

On Friday, February 11, 2022 at 3:41:55 PM UTC-5, pbru...@gmail.com wrote:
> Hello everyone,
> I've received a number of dcm files on CD that look like legitimate DICOM, valid metadata and all, but I can't interpret the pixel data. They are fuji cardio US images with a standard UltrasoundImageStorage SOP class and JPEG Lossless Process 14 TS.
>
> I've tried on several viewing programs and none of them can display the images. Only the CD included viewer works to read them, but there is no option to export. Anyone have ideas on what type of encoding this could be? The Implementation Version Name element indicates "EPIQ-AFFIN_5.00"...
>
> Many thanks!

That transfer syntax, 1.2.840.10008.1.2.4.70 JPEG Lossless Process 14, is the encoding of the PixelData, JPEG coding Process 14 "lossless, non-hierarchical, first-order prediction". This is one of the encoding modes of the original JPEG standard (ISO/IEC 10918-1). In my experience this lossless encoding seems to have the broadest support in medical imaging, despite the other lossless transfer syntaxes.

Note that ISO/IEC 10918-1 specifies JPEG Baseline, the most popular lossy encoding, but this standard also specifies other encoding modes.

I don't know if the reference standard provides support for this mode of JPEG. Many some open source packages can demonstrate how to support this encoding.

Don't understand why the Implementation Version Name is "EPIQ-AFFIN" that sounds a lot like the EPIQ Affinity machine from Philips (not Fuji).

Many thanks,
-Chris O

Hello Chris,
My apologies... I don't think I was verbose enough. Yes, I realize the TS is supposed to indicate the pixel encoding and I agree this one has very broad support. Normally I don't have a problem with this TS, but something in these images isn't standard. I've tried several viewers including open source ones on both PC and Mac with no success and I've even tried to do a simple decode on them them with both pydicom and dcmtk, both throw decode errors which I've added below. I was wondering if this was a known thing...

EPIQ Affinity, that does make sense to the implementation ver name... I'm not familiar with that particular model. The viewer on the CD however is branded Synapse Cardiovascular with "prosolv.com" name sprinkled in amongst the files. Usually the file header is rewritten when it goes through a PACS system and this version name changes, so I jumped to the conclusion that this was a Fuji product.

Thanks!

# dcmtk
F: Invalid lossless parameters Ss=1 Se=63 Ah=0 Al=0: decompressing file: file1

# pydicom
libjpeg error code '-1038' returned from Decode(): A misplaced marker segment was found - predictor for the lossless mode must be between 1 and 7

On Friday, February 11, 2022 at 5:35:55 PM UTC-5, pbru...@gmail.com wrote:
> Hello Chris,
> My apologies... I don't think I was verbose enough. Yes, I realize the TS is supposed to indicate the pixel encoding and I agree this one has very broad support. Normally I don't have a problem with this TS, but something in these images isn't standard. I've tried several viewers including open source ones on both PC and Mac with no success and I've even tried to do a simple decode on them them with both pydicom and dcmtk, both throw decode errors which I've added below. I was wondering if this was a known thing...
>
> EPIQ Affinity, that does make sense to the implementation ver name... I'm not familiar with that particular model. The viewer on the CD however is branded Synapse Cardiovascular with "prosolv.com" name sprinkled in amongst the files. Usually the file header is rewritten when it goes through a PACS system and this version name changes, so I jumped to the conclusion that this was a Fuji product.
>
> Thanks!
>
> # dcmtk
> F: Invalid lossless parameters Ss=1 Se=63 Ah=0 Al=0: decompressing file: file1
>
> # pydicom
> libjpeg error code '-1038' returned from Decode(): A misplaced marker segment was found - predictor for the lossless mode must be between 1 and 7

Ah excellent, thanks for the clarifications! I suppose the problem could be in two areas: either the PixelData isn't properly formatted or the image itself has some issues. dcmtk has the dcmdump utility, it can parse the PixelData section (without decode) and show if it has determined that the PixelData tags are properly formatted, as example:
(7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
(fffe,e000) pi (no value available) # 0, 1 Item
(fffe,e000) pi ff\d8\ff\e0\00\10\4a\46\49\46\00\01\01\00\00\01\00\01\00\00\ff\db... # 336758, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem)
If the PixelData tag bytes are proper, then dcmdump should find the enclosed SQ Items and SequenceDelimitationIterm. For the JPEG Lossless, it should be using the encapsulated PixelData rules. Notice the second item, starts with bytes FF D8 for JPEG start of image, and if you can view in a hex editor, you should find bytes FF D9 for end of image, just before the SequenceDelimitationItem, and hopefully at the correct offset in the file.

-thanks