Hi Bruce,
Please have a look at:
ftp://ftp-rt.nki.nl/outbox/Mar…erver/patch_1416beta2.zip. It merges your changes into 1.4.16beta released above.
Marcel
Hi Bruce,
Please have a look at:
ftp://ftp-rt.nki.nl/outbox/Mar…erver/patch_1416beta2.zip. It merges your changes into 1.4.16beta released above.
Marcel
Hi Marcel
Wow, beta! A few minor changes to get it to compile ( and of course I'm still mental about warnings ).
http://www.bitsltd.net/images/stories/file/dgate1416b3.zip
Bruce
Hi Bruce,
on the lastest windows build bigendian does not work. Every DICOM command is rejected by the parse.... routine because dicom fields are out of order - the message indeed shows swapped bytes. Do you have a clue what happened?
Thanks,
Marcel
Hi Marcel,
You have a big endian image? I don't have any big endian images. Send me one and I will have a look.
Bruce
Hm,
this is a bigendian network transfer. Not sure if I can capture it. It may take a while...
Marcel
Hi Marcel,
Where is it coming from? I have setup a blind DICOM listener on bitsltd.dnsalias.net, port 4096, AE Bruce. Push it there and I can take a look.
Bruce
Hm,
from kodak in the hospital, that will not work I assume.
Marcel
Hi Marcel,
Any Apple MACs? Osirix can store an image in original format, if it can't read it, it moves it to an unreadable folder. Then you could send it from that. Or, which Kodak, maybe I can find some web samples. I did find a GE Ultrasound on the web. I can try with that first and let you know.
Bruce
Hi Marcel,
I can duplicate the problem using the image I found and a regen. I will work it on my Monday (NY Time).
Bruce
Hi Bruce,
Perfect! I would like to include it in the upcoming release.
Marcel
Hi Marcel,
Got it. I also ran into a different type of j2k where a whole jp2 file is there instead of just the stream. I fixed that at the same time.
Both files are here:
http://www.bitsltd.net/images/stories/file/dgate1416up.zip
Time to move over to the conquest 1.4.16beta topic?
Bruce
Hi Bruce,
I will try the changes out asap. I feel that we are close to a full release ;->>>
Marcel
Hi Bruce,
still got an element out of order error after your fix. I guess the check for ordering comes too early....
Maexel
Hi Bruce,
Thanks for your fix, but this is what goes still wrong for me in Explicit_ParseRawVRIntoDCM:
Testing transfer: '1.2.840.10008.1.2.2' against list #0 = '1.2.840.10008.1.2'
Testing transfer: '1.2.840.10008.1.2.2' against list #1 = '1.2.840.10008.1.2.1'
Testing transfer: '1.2.840.10008.1.2.2' against list #2 = '1.2.840.10008.1.2.2'
***(Exp) at 00000000
***(Exp) at 00000200 (should be 00000002)
***(Exp) at 00000001 (should be 00000100)
***(Exp) Invalid element order during load of DCM file (in 00000200)
***(Dyn) Found 0001
[at log added as :
lVRBuffer >> vr->Group;
lVRBuffer >> vr->Element;
DicomError(DCM_ERROR_PARSE, "(Exp) at %08x\n", (vr->Group<<16)+vr->Element);]
So the transfer that is accepted is BigEndianExplicit, but the explictit code still runs in Littleendian mode..... Further I have no time to fix this soon....
Marcel
Hi Marcel,
I will have a look.
Bruce
Don’t have an account yet? Register yourself now and be a part of our community!