Legacy ImageMagick Discussions Archive

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.

Snibgo,

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

Fred

fmw42 wrote: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.

snibgo wrote:

fmw42 wrote: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

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: "head" and "tail" are utilities from the Cygwin collection. Windows doesn't come with good tools for binary files.

The calculated numbers are: 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.

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

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