Discover proprietary raster format?

[dlemstra]

I am also having a bit more success when I rename the file to test.dcm. It seems to process part of the file but exits with an 'Insufficient image data in file' message. Might be a dicom file we don't fully support or a bug in the dicom reader.

[fmw42]

Snibgo,

I would be interested to know how you determined -size 556x467 and the 800 bytes offset.

Fred

[snibgo]

I would be interested to know how you determined -size 556x467 and the 800 bytes offset.

A hex dump suggested 1 byte/channel and 1 channel/pixel, with a header between about 300 and 900 bytes. It seems the header ends with many zeros and the data starts with many zeros so I can't see the boundary.

I made an initial guess at the width: 512 bytes. The height was int(file_size/width). The header was file_size-(width*height). By observing the "interference" pattern, I saw how far the guessed width was too large or small, so adjusted it (and height and header) until it looked reasonable. This gives 556x467, with 800 bytes header.

My results show four squished circles at the bottom. I think this represents a single circular image, width=556/4. It is probably a thumbnail of the main image. If so, that could be cropped off, and the main image rolled to something reasonable. As each line starts and ends with a series of black pixels, I can't see exactly how far it should be rolled.

[fmw42]

I would be interested to know how you determined -size 556x467 and the 800 bytes offset.

A hex dump suggested 1 byte/channel and 1 channel/pixel, with a header between about 300 and 900 bytes. It seems the header ends with many zeros and the data starts with many zeros so I can't see the boundary.

I made an initial guess at the width: 512 bytes. The height was int(file_size/width). The header was file_size-(width*height). By observing the "interference" pattern, I saw how far the guessed width was too large or small, so adjusted it (and height and header) until it looked reasonable. This gives 556x467, with 800 bytes header.

My results show four squished circles at the bottom. I think this represents a single circular image, width=556/4. It is probably a thumbnail of the main image. If so, that could be cropped off, and the main image rolled to something reasonable. As each line starts and ends with a series of black pixels, I can't see exactly how far it should be rolled.

Thanks for the explanation. I sort of guessed it would be some kind of intelligently guessed iteration, but hoped you may have found a more direct solution.

Fred

[snibgo]

The file starts with the bytes "Header: Sabine{00}" where {00} is ASCII null. The rest of the first 800 bytes are either text data or null. There seems to be nothing that says there are two images, or their dimensions, or start positions.

We can extract both images from the two files. Windows BAT script:

Code: Select all

set TOTSIZE=260452

set W1=556

set W2=139
set H2=123

set /A H1=(%TOTSIZE%-%W2%*%H2%)/%W1%
set /A START1=%TOTSIZE%-%W1%*%H1%-%W2%*%H2%
set /A BYTES1=%START1%+%W1%*%H1%-1

set /A START2=%TOTSIZE%-%W2%*%H2%

echo H1=%H1% START1=%START1% BYTES1=%BYTES1% START2=%START2%


head --bytes=%BYTES1% 20140616.001 | tail --bytes=+%START1% | %IM%convert -size %W1%x%H1% -depth 8 gray:- xray1a.png

tail --bytes=+%START2% 20140616.001 | %IM%convert -size %W2%x%H2% -depth 8 gray:- xray1b.png


head --bytes=%BYTES1% 20141013.002 | tail --bytes=+%START1% | %IM%convert -size %W1%x%H1% -depth 8 gray:- xray2a.png

tail --bytes=+%START2% 20141013.002 | %IM%convert -size %W2%x%H2% -depth 8 gray:- xray2b.png

"head" and "tail" are utilities from the Cygwin collection. Windows doesn't come with good tools for binary files.

The calculated numbers are:

Code: Select all

H1=437 START1=383 BYTES1=243354 START2=243355

The images are:




These results may have pixels on the left when they should be on the right, or pixels in the small image when they should be in the large image, etc.

The small images seem to be left-right reversals of the large images.

[courtejm]

Awesome! Thanks so much! Not sure about the images at the bottom, but otherwise they look pretty good to me! Thanks again!

[courtejm]

Sorry, that was replying to the earlier attempt ... your final output is perfect! Once more thanks!