We are having an issue with an older DICOM library reading a 1.2.840.10008.1.2.5 RLE image. The image is 16 bit grayscale from the tags. The library (LEADTOOL v 13) is creating a pixel stream on the PC that is distorted, but if we manually switch the
byte order displays correctly. So this is implying that the output is big Endian.
Internally, what endian-ness is the RLE pixels ? I mean there is no other tag other than tsx that would tell me the endian-ness, and I would have assumed that in DICOM, the file should be stored using the standard explicit VR little endian (no matter
what the architecture of the original site that created the image).
Am I wrong or is the library not working correctly (which we suspect).
FYI The image displays fine and decompresses well with dcm4che 5.x.x without any flipping required. I can see that the pixeldata is OW as expected.
Can someone clarify this endian-ness of RLE for me ? Thanks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For reference: http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_G.2.html

When 16-bit OW pixeldata is RLE compressed, it is turned into a bytestream roughly as follows:
First, the most significant byte of every word is fed into an 8-bit RLE compression algorithm to create the first segment of the PixelData.
Then, the least significant byte of every word is fed into an 8-bit RLE compression algorithm to create the second segment of the PixelData.

For little-endian, the 2nd byte of each word is the most significant byte. For big-endian, the 1st byte is most significant. So you can see that a naively coded decompressor might use the 1st segment to generate the 1st byte of each word, and the 2nd
segment to generate the 2nd byte of each word. This would generate big-endian OW pixels.

I've written a DICOM RLE decoder, myself, and in order to get little-endian pixels I use the 1st segment to generate the 2nd byte of each word, and use the 2nd segment to generate the 1st byte. Of course, one could just as easily use the naive
decompressor described above, and then perform a byteswap on the output.

Now, I can't say for sure whether the library you're using is wrong. The byte-order handling has to be done properly for both encoding or decoding, so it's possible that you found an incorrectly-encoded file.

You can find RLE sample images in /medical/dicom/DataSets/WG04/compsamples_rle_20040210.tar.bz2 on the medical.nema.org ftp site.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, February 5, 2021 at 6:44:22 PM UTC-5, david...@gmail.com wrote:

For reference: http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_G.2.html

When 16-bit OW pixeldata is RLE compressed, it is turned into a bytestream roughly as follows:
First, the most significant byte of every word is fed into an 8-bit RLE compression algorithm to create the first segment of the PixelData.
Then, the least significant byte of every word is fed into an 8-bit RLE compression algorithm to create the second segment of the PixelData.

For little-endian, the 2nd byte of each word is the most significant byte. For big-endian, the 1st byte is most significant. So you can see that a naively coded decompressor might use the 1st segment to generate the 1st byte of each word, and the 2nd

segment to generate the 2nd byte of each word. This would generate big-endian OW pixels.

I've written a DICOM RLE decoder, myself, and in order to get little-endian pixels I use the 1st segment to generate the 2nd byte of each word, and use the 2nd segment to generate the 1st byte. Of course, one could just as easily use the naive

decompressor described above, and then perform a byteswap on the output.

Now, I can't say for sure whether the library you're using is wrong. The byte-order handling has to be done properly for both encoding or decoding, so it's possible that you found an incorrectly-encoded file.

You can find RLE sample images in /medical/dicom/DataSets/WG04/compsamples_rle_20040210.tar.bz2 on the medical.nema.org ftp site.

Thanks, thats a good explanation.
So to paraphrase your explanation, the big end is encoded to the first segment and the little end is encoded to the second segment and thus encodes the endian-ness. Thats what I couldn't grasp, how the endian-ness is encoded in the RLE.
As I said, I have other decoders that do not have that issue. Seems that the version 13 LeadTools then was not performing the byte swap that we noticed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)