Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Genesis Image
38 views
Skip to first unread message
removethis
Feb 6, 2012, 2:04:58 AM2/6/12
to
Hi All,
My apologies if this is the wrong place to post.
I have a bunch of old DAT tapes in Genesis 5x format. I've written a
program to extract the headers and manipulate most of the data with the
intent on eventually converting it to something more useful like DICOM
or NIFTI.
My problem is that I have tapes in a variety of formats. The ones that
are file backups of a server seem to be fine. I've extracted MANY scans
from them and in general each one is made up of many files that are
145408 bytes in size. That works fine as its a 256x256 image with 2
bytes per pixel and with a header of 14336 bytes.
The other ones appear to have been written by the scanner itself (I
believe, I've never seen a scanner).
I restored these by creating a script that runs 'dd' on the tape and
pulls in the files one by one. The exact command was something like: -
dd if=/dev/tape/by-id/tape_device-nst of=image_file.NUM ibs=32k
Note that I'm restoring on a Linux box. The tapes were presumably
written under the SunOS system the Genesis uses. I havn't noticed any
'endian' issues.
This pulls in files that are about 72k in size, but they vary slightly
in size, sometimes as low as 51k. The headers are identical to the other
ones but nothing will open these images (brains2 detects it as ge5x but
fails, itksnap balks with these and the other ones unless I use raw
image which fails with these ones). My guess is that somehow I'm only
getting half the file but I'm unsure how to prove or disprove this. The
only other option I can think of is the image payload is compressed and
done so well that the size is cut in half and would explain the variance
in size. Looking at the headers of both a working and non working one,
the header states in both that they are compressed but not packed. My
understanding is this means any 'non-image' at the beginning and end of
each row of the image is truncated out.
I'm now going through restoring hundreds more scans but if my
restoration procedure is flawed it will be wasted time.
Does anyone here have any suggestions about what I can do to try open
these images?
Thanks,
Brendan Grieve
My apologies if this is the wrong place to post.
I have a bunch of old DAT tapes in Genesis 5x format. I've written a
program to extract the headers and manipulate most of the data with the
intent on eventually converting it to something more useful like DICOM
or NIFTI.
My problem is that I have tapes in a variety of formats. The ones that
are file backups of a server seem to be fine. I've extracted MANY scans
from them and in general each one is made up of many files that are
145408 bytes in size. That works fine as its a 256x256 image with 2
bytes per pixel and with a header of 14336 bytes.
The other ones appear to have been written by the scanner itself (I
believe, I've never seen a scanner).
I restored these by creating a script that runs 'dd' on the tape and
pulls in the files one by one. The exact command was something like: -
dd if=/dev/tape/by-id/tape_device-nst of=image_file.NUM ibs=32k
Note that I'm restoring on a Linux box. The tapes were presumably
written under the SunOS system the Genesis uses. I havn't noticed any
'endian' issues.
This pulls in files that are about 72k in size, but they vary slightly
in size, sometimes as low as 51k. The headers are identical to the other
ones but nothing will open these images (brains2 detects it as ge5x but
fails, itksnap balks with these and the other ones unless I use raw
image which fails with these ones). My guess is that somehow I'm only
getting half the file but I'm unsure how to prove or disprove this. The
only other option I can think of is the image payload is compressed and
done so well that the size is cut in half and would explain the variance
in size. Looking at the headers of both a working and non working one,
the header states in both that they are compressed but not packed. My
understanding is this means any 'non-image' at the beginning and end of
each row of the image is truncated out.
I'm now going through restoring hundreds more scans but if my
restoration procedure is flawed it will be wasted time.
Does anyone here have any suggestions about what I can do to try open
these images?
Thanks,
Brendan Grieve
Mathieu Malaterre
Feb 6, 2012, 7:33:10 AM2/6/12
to
On Feb 6, 8:04 am, removethis
http://www.dclunie.com/dicom3tools.html
http://www.tomovision.com/
2cts
<"brendan(removethis)"@worldguard.com.au> wrote:
> Hi All,
>
> My apologies if this is the wrong place to post.
>
> I have a bunch of old DAT tapes in Genesis 5x format. I've written a
> program to extract the headers and manipulate most of the data with the
> intent on eventually converting it to something more useful like DICOM
> or NIFTI.
...
> Hi All,
>
> My apologies if this is the wrong place to post.
>
> I have a bunch of old DAT tapes in Genesis 5x format. I've written a
> program to extract the headers and manipulate most of the data with the
> intent on eventually converting it to something more useful like DICOM
> or NIFTI.
> Does anyone here have any suggestions about what I can do to try open
> these images?
The tools I would try first are dicom3tools or TomoVision
> these images?
http://www.dclunie.com/dicom3tools.html
http://www.tomovision.com/
2cts
David Clunie
Feb 6, 2012, 3:32:12 PM2/6/12
to
Hi Brendan
Email me a sample if you like, and I will see if one of my older
utilities can determine whether it is compressed and if so
decompress it (or you can try gentodc with the -dat option in
my dicom3tools); I had implemented most if not all of the Genesis
varieties documented and encountered.
There are both a perimeter and differential compression schemes
used for Genesis bit streams (though more often with CT than MR,
the former often being circular reconstructions).
You could experiment with different (larger) ibs values for dd,
but I recall from the documentation that for Genesis DAT tapes
the block size written was 8k (though I also recall having many
block size issues with DAT in general).
David
Email me a sample if you like, and I will see if one of my older
utilities can determine whether it is compressed and if so
decompress it (or you can try gentodc with the -dat option in
my dicom3tools); I had implemented most if not all of the Genesis
varieties documented and encountered.
There are both a perimeter and differential compression schemes
used for Genesis bit streams (though more often with CT than MR,
the former often being circular reconstructions).
You could experiment with different (larger) ibs values for dd,
but I recall from the documentation that for Genesis DAT tapes
the block size written was 8k (though I also recall having many
block size issues with DAT in general).
David
removethis
Feb 7, 2012, 11:01:42 AM2/7/12
to
On 07/02/12 04:32, David Clunie wrote:
> Hi Brendan
>
> Email me a sample if you like, and I will see if one of my older
> utilities can determine whether it is compressed and if so
> decompress it (or you can try gentodc with the -dat option in
> my dicom3tools); I had implemented most if not all of the Genesis
> varieties documented and encountered.
>
> There are both a perimeter and differential compression schemes
> used for Genesis bit streams (though more often with CT than MR,
> the former often being circular reconstructions).
>
> You could experiment with different (larger) ibs values for dd,
> but I recall from the documentation that for Genesis DAT tapes
> the block size written was 8k (though I also recall having many
> block size issues with DAT in general).
>
I appreciate the offer David. I'll send through to your email a few from
> Hi Brendan
>
> Email me a sample if you like, and I will see if one of my older
> utilities can determine whether it is compressed and if so
> decompress it (or you can try gentodc with the -dat option in
> my dicom3tools); I had implemented most if not all of the Genesis
> varieties documented and encountered.
>
> There are both a perimeter and differential compression schemes
> used for Genesis bit streams (though more often with CT than MR,
> the former often being circular reconstructions).
>
> You could experiment with different (larger) ibs values for dd,
> but I recall from the documentation that for Genesis DAT tapes
> the block size written was 8k (though I also recall having many
> block size issues with DAT in general).
>
one of the later tapes. My tools that parse the headers work fine but I
suspect it may be that that image data is compressed.
Interestingly, under Debian dicom3tools seems to be missing a lot of the
command line tools, (maybe due to licensing?) so I'll need to compile it
up myself to test it out.
Brendan Grieve
----8< snip 8<--------
removethis
Feb 7, 2012, 11:11:54 AM2/7/12
to
debian package would be complete but its missing most of the interesting
ones and thus I missed seeing them.
Brendan
Mathieu Malaterre
Feb 8, 2012, 6:07:06 AM2/8/12
to
On 7 fév, 17:11, removethis <"brendan(removethis)"@worldguard.com.au>
wrote:
Brendan, this has been discussed previsouly on this very same
newsgroup and this choice is explained in the README file when you
install dicom3tools.
See it online if you want:
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/dicom3tools/trunk/debian/README.Debian?view=markup
Point is: upstream does not want that for good reasons.
-M
wrote:
newsgroup and this choice is explained in the README file when you
install dicom3tools.
See it online if you want:
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/dicom3tools/trunk/debian/README.Debian?view=markup
Point is: upstream does not want that for good reasons.
-M
Brendan Grieve
Feb 8, 2012, 8:01:59 PM2/8/12
to
similar to making up a MAC address.
Brendan
Brendan Grieve
Feb 10, 2012, 12:36:49 AM2/10/12
to
On 07/02/12 04:32, David Clunie wrote:
> Hi Brendan
2>
> Hi Brendan
> Email me a sample if you like, and I will see if one of my older
> utilities can determine whether it is compressed and if so
> decompress it (or you can try gentodc with the -dat option in
> my dicom3tools); I had implemented most if not all of the Genesis
> varieties documented and encountered.
---8< snip --------------
> utilities can determine whether it is compressed and if so
> decompress it (or you can try gentodc with the -dat option in
> my dicom3tools); I had implemented most if not all of the Genesis
> varieties documented and encountered.
Hi David,
gentodc has functioned perfectly converting those genesis files pulled
from DAT.
Now interestingly, the OTHER genesis files I already have do not convert
with this tool. They are all 145408 bytes in length, have the same
header format as the DAT ones (that is, with the prepended
study/series/etc and invalid pointers in the next), and yet gentodc does
not convert them.
I can open them with a viewer that supports gen5x, so they work. But if
I try use gentodc without the -dat, I get a segmentation fault. This
looks right because its trying to use the invalid pointers. Also the
headers of these files do not indicate they are ximg.
If I then run it with the parameter -dat, it converts the file to a dcm,
but the dcm is just mush in the viewer. Its not a clean convert. Perhaps
this is a different type of genesis format?
Looking closer at the header, it seems to have the same compression
flags and the headers looks pretty much the same as the dat version of
the files, and yet without any of the file size variance, which leads me
to think the image data is not compressed (or packed) at all.
An thoughts?
Brendan Grieve
David Clunie
Feb 10, 2012, 1:31:14 PM2/10/12
to
Hi Brendan
Send me one, and I will take a look.
David
Send me one, and I will take a look.
David
Brendan Grieve
Mar 23, 2012, 3:43:23 AM3/23/12
to
On 11/02/12 02:31, David Clunie wrote:
> Hi Brendan
>
> Hi Brendan
>
> Send me one, and I will take a look.
>
> David
>
> David
--8< snip --------------
>>
>>
>> Hi David,
>>
>> gentodc has functioned perfectly converting those genesis files pulled
>> from DAT.
>>
>> Now interestingly, the OTHER genesis files I already have do not
>> convert with this tool. They are all 145408 bytes in length, have the
>> same header format as the DAT ones (that is, with the prepended
>> study/series/etc and invalid pointers in the next), and yet gentodc
>> does not convert them.
>>
>> I can open them with a viewer that supports gen5x, so they work. But
>> if I try use gentodc without the -dat, I get a segmentation fault.
>> This looks right because its trying to use the invalid pointers. Also
>> the headers of these files do not indicate they are ximg.
>>
>> If I then run it with the parameter -dat, it converts the file to a
>> dcm, but the dcm is just mush in the viewer. Its not a clean convert.
>> Perhaps this is a different type of genesis format?
>>
>> Looking closer at the header, it seems to have the same compression
>> flags and the headers looks pretty much the same as the dat version of
>> the files, and yet without any of the file size variance, which leads
>> me to think the image data is not compressed (or packed) at all.
>>
>>
>> An thoughts?
>>
>> Brendan Grieve
>
Thanks David,
>>
>>
>> Hi David,
>>
>> gentodc has functioned perfectly converting those genesis files pulled
>> from DAT.
>>
>> Now interestingly, the OTHER genesis files I already have do not
>> convert with this tool. They are all 145408 bytes in length, have the
>> same header format as the DAT ones (that is, with the prepended
>> study/series/etc and invalid pointers in the next), and yet gentodc
>> does not convert them.
>>
>> I can open them with a viewer that supports gen5x, so they work. But
>> if I try use gentodc without the -dat, I get a segmentation fault.
>> This looks right because its trying to use the invalid pointers. Also
>> the headers of these files do not indicate they are ximg.
>>
>> If I then run it with the parameter -dat, it converts the file to a
>> dcm, but the dcm is just mush in the viewer. Its not a clean convert.
>> Perhaps this is a different type of genesis format?
>>
>> Looking closer at the header, it seems to have the same compression
>> flags and the headers looks pretty much the same as the dat version of
>> the files, and yet without any of the file size variance, which leads
>> me to think the image data is not compressed (or packed) at all.
>>
>>
>> An thoughts?
>>
>> Brendan Grieve
>
Apologies for the late response. I'll send you a slice plus what it
should look like and what it looks like after converting to DCM.
Cheers,
Brendan Grieve
0 new messages