help
10 Subscribers 
help > Error when processing dicom files
Showing 1-7 of 7 posts
May 3, 2011 07:05 PM | Garrett McGrath
Error when processing dicom files
We are attempting to integrate the duke QA scripts into our new
conquest dicom server. However when we attempt to parse files
output by conquest with dicom2bxh we get an error about seeking to
a specific file position. IE:
Error seeking in file to position 4294918174!
ERROR: can't find pixel data offset!
No additional information appears to be output when the debug flag is included in the command call.
I have attached one of these files to this post.
Error seeking in file to position 4294918174!
ERROR: can't find pixel data offset!
No additional information appears to be output when the debug flag is included in the command call.
I have attached one of these files to this post.
May 3, 2011 08:05 PM | Syam Gadde
RE: Error when processing dicom files
Unfortunately the tools don't currently support DICOM files that
use JPEG transfer syntax. I agree the error message
needs to be more clear, and I will fix that in a later release.
If your scanner only supports writing JPEG-encoded DICOM images, then I will have to see whether we can support them directly...
If your scanner only supports writing JPEG-encoded DICOM images, then I will have to see whether we can support them directly...
May 3, 2011 09:05 PM | Garrett McGrath
RE: Error when processing dicom files
This seems more specific to the conquest server than it is to the
scanner that's transmitting the images themselves. Currently
it its configured to store images using the flag 'un = uncompress
NKI and/or JPEG compressed images'. However there is a large
variety of other formats I can choose from, is there a recommended
one? (list below)
as = store images as is, e.g. without changing
the compression.
is = store images as is, e.g. without changing the compression.
un = uncompress NKI and/or JPEG compressed images
n1 = fast NKI private loss-less compression mode 1 (50%)
n2 = as n1 but with CRC check for errors (50%)
n3 = fast NKI private loss-less compression mode 3 (40%)
n4 = as n3 but with CRC check for errors (40%)
j1 = JPEGLossless (33%)
j2 = JPEGLosslessNH14 (33%)
j3 = JPEG baseline 1 (8 bit) lossy (8%)
j4 = JPEGExtended2and4 lossy (15%)
j5 = JPEGSpectralNH6and8 lossy (15%)
j6 = JPEGFulllNH10and12 lossy (14%)
jk = Lossless JPEG2000 (variable)
jl = Lossy JPEG2000 (variable)
nj = Highest NKI mode; but leaves JPEG as is (variable)
uj = Uncompressed; but leaves JPEG as is (variable)
k1 = Downsize image>1024 pixels wide/high to 1024 (variable)
k2 = Downsize image>512 pixels wide/high to 512 (variable)
k4 = Downsize image>256 pixels wide/high to 256 (variable)
k8 = Downsize image>128 pixels wide/high to 128 (variable)
ka = Downsize image>64 pixels wide/high to 64 (variable)
kb = Downsize image>32 pixels wide/high to 32 (variable)
kc = Downsize image>16 pixels wide/high to 16 (variable)
s0 = Run CompressionConverter0 (n/a)
..
s9 = Run CompressionConverter9 (n/a)
is = store images as is, e.g. without changing the compression.
un = uncompress NKI and/or JPEG compressed images
n1 = fast NKI private loss-less compression mode 1 (50%)
n2 = as n1 but with CRC check for errors (50%)
n3 = fast NKI private loss-less compression mode 3 (40%)
n4 = as n3 but with CRC check for errors (40%)
j1 = JPEGLossless (33%)
j2 = JPEGLosslessNH14 (33%)
j3 = JPEG baseline 1 (8 bit) lossy (8%)
j4 = JPEGExtended2and4 lossy (15%)
j5 = JPEGSpectralNH6and8 lossy (15%)
j6 = JPEGFulllNH10and12 lossy (14%)
jk = Lossless JPEG2000 (variable)
jl = Lossy JPEG2000 (variable)
nj = Highest NKI mode; but leaves JPEG as is (variable)
uj = Uncompressed; but leaves JPEG as is (variable)
k1 = Downsize image>1024 pixels wide/high to 1024 (variable)
k2 = Downsize image>512 pixels wide/high to 512 (variable)
k4 = Downsize image>256 pixels wide/high to 256 (variable)
k8 = Downsize image>128 pixels wide/high to 128 (variable)
ka = Downsize image>64 pixels wide/high to 64 (variable)
kb = Downsize image>32 pixels wide/high to 32 (variable)
kc = Downsize image>16 pixels wide/high to 16 (variable)
s0 = Run CompressionConverter0 (n/a)
..
s9 = Run CompressionConverter9 (n/a)
May 4, 2011 02:05 PM | Syam Gadde
RE: Error when processing dicom files
I'm not familiar with Conquest, but I would probably suggest "as"
or "is" to retain the format of the incoming data. It's
unclear from the documentation what exactly "un" means, whether the
scope of "and/or" means "uncompress (NKI and/or JPEG) compressed
images" or "(uncompress NKI) and/or (JPEG compressed
images)". The first seems more likely, but then you are
getting JPEG images out, so I'm not sure.
May 26, 2011 06:05 PM | Garrett McGrath
RE: Error when processing dicom files
Sorry to resurrect this thread, I've got one thing to bring up.
Would it be possible to add a sanity check to
fmriqa_generate.pl so that it makes sure the .bxh file it's passed
actually exists? As it stands now it dies pretty deep into
the code with an error that isn't very clear it's a 'missing file'
error. (ie. LWP Request Failed at
/mnt/cd/usr_csbmb/os/linux64/pkg/BXH_XCEDE_TOOLS/bxh_xcede_tools-1.9.9.2-lsb31.x86_64/bin/XML/SAX/PurePerl/Reader/URI.pm
line 51.)
I can now to some level run the qa scripts against files delievered from our scanners, my local k-pacs workstation is another matter but I'm working on that now.
Belated Thanks for the help!
-Garrett
I can now to some level run the qa scripts against files delievered from our scanners, my local k-pacs workstation is another matter but I'm working on that now.
Belated Thanks for the help!
-Garrett
May 26, 2011 07:05 PM | Syam Gadde
RE: Error when processing
dicom files
That's a very reasonable request. I've added it to the SVN
repository
and will be pushed out in the next release. Here is the patch (let's
see if it makes it through unscathed):
Index: fmriqa/fmriqa_generate.pl
===================================================================
--- fmriqa/fmriqa_generate.pl (revision 2329)
+++ fmriqa/fmriqa_generate.pl (working copy)
@@ -382,6 +382,11 @@
}
my $outputpath = pop @ARGV;
+my @missingfiles = grep { ! -f $_ } @ARGV;
+if (scalar(@missingfiles)) {
+ die "Error: following input files do not exist:\n" . join("\n",
@missingfiles) . "\n";
+}
+
if (-e $outputpath && !$opt_overwrite) {
die "Output directory $outputpath exists, aborting...";
}
and will be pushed out in the next release. Here is the patch (let's
see if it makes it through unscathed):
Index: fmriqa/fmriqa_generate.pl
===================================================================
--- fmriqa/fmriqa_generate.pl (revision 2329)
+++ fmriqa/fmriqa_generate.pl (working copy)
@@ -382,6 +382,11 @@
}
my $outputpath = pop @ARGV;
+my @missingfiles = grep { ! -f $_ } @ARGV;
+if (scalar(@missingfiles)) {
+ die "Error: following input files do not exist:\n" . join("\n",
@missingfiles) . "\n";
+}
+
if (-e $outputpath && !$opt_overwrite) {
die "Output directory $outputpath exists, aborting...";
}
May 26, 2011 09:05 PM | Garrett McGrath
RE: Error when processing dicom files
It appears to be working great! Thanks!