For reference: http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_G.2.htmlsegment to generate the 2nd byte of each word. This would generate big-endian OW pixels.
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
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 naivedecompressor 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.
|Location:||Huddersfield, West Yorkshire, UK|
|Nodes:||16 (1 / 15)|