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,
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
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
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 Marcel
Visible Light Video Endoscopy uses MPEG video. I haven't seen any yet, but I think it will be more popular soon. I haven't heard of ultrasound using it yet, but it seems like a nice fit. I'm not sure how hard it would be, I have seen some open source decoders. I will look at it and at a --echo command too.
Bruce
Hi Marcel,
Hope you had a good time.
Another thing is what to do about MPEG. I looked at it and decoding might not be that hard, but encoding will be very hard. The video stream can also have an audio stream in it. Pulling it out and saving it might not be that hard, but when encoding, get them to sink up correctly may be very difficult. I think for MPEG, it should be detected and stored only as MPEG. Also when asked for, it should only be offered as uncompressed or MPEG. We would need to ignore the incoming compression settings for MPEG and just save it as is. What do you think?
Bruce
Hi Marcel and anyone else playing with these files,
I just updated the nkiqrsop to fix a leak in segmented palettes. Now the only thing that looks like I need to add is Deflated Explicit (zip). However, I don't think we should delay the beta for it. The code is in the same place.
http://www.bitsltd.net/images/…e/dgate1416a5_changes.zip
In Decompress Image, it looks like it was written specifically to avoid the use of 0002,0010. Was there a reason for this? I use it to test for jpeg vs j2k, should I change it to look at the jpeg header instead? Are there cases where the 0002 tag are stripped using Decompress Image?
Last, I am making a MAC interface for dgate, and though, far from done, it does kind of work. One of the features I added on the Known DICOM providers tab was a dicom ping button. In your case it might be easier to put in the last tab. I have the code for the c-echo and looking at it, it has very few "Apple" routines in it. It creates a packet from ANY_SCP, sends it, waits for the return and if it comes back, it just scans the packet for ANY_SCP. I have put the code for it here:
http://www.bitsltd.net/images/stories/file/dicomPingIP.txt
Bruce
Hi Marcel,
Fixed it (pdu.cxx). And a memory leak in dgate.cpp calling it. Of course I had to change my old favorite nkiqrsop.cpp. I fixed RLE to now work to with frames, I also added a Palette Color decoder for both regular and segmented palettes (even the dcm toolkit can't do segmented palettes). This allowed me to decode two color ultrasounds images I found, one being from an Aloka. I put all of the changed code in one place with the fixes from before.
Bruce
Hi Marcel,
I will look in to it.
Bruce
Hi Marcel,
Found it. I've never seen signed data before. In lossless mode, there is no difference between sign and unsigned data, what goes in, comes out. In lossy mode the compression is done differently, and, signed and unsigned data makes a big difference. I now check for 28,103 and set signed (sngd) for the data. Also I set the precision to 28,100 instead of 28,101, but that wasn't your problem since both were 16. I just found an ultrasound image that is RLE palette color. In the next few days I would like to try and add it.
But for now, here is the fixed nkiqrsop.cpp file:
http://www.bitsltd.net/images/stories/file/nkiqrsop.cpp.zip
Bruce
Hi Marcel,
Looks like 12 bit data with byte reversal. I will try to duplicate it here. I may need to use your original image. I will let you know.
Bruce
Hi Marcel,
A typo on my part.
They're there now.
http://www.bitsltd.net/images/…le/dgate1416a5changes.zip
Bruce
Hi Marcel,
Looks like the release is soon! Very small changes.
In nkiqrsop.cpp I moved the full_422 test to after my jpeg code because I can do full_422 (I think, although, never had a file to test it). If it doesn't work, send me a full_422 image file and I will fix it.
dbsql.cpp and dgate.cpp have the - w changes. I don't know if they can be adapted to windows, but I don't think it would be too hard. I know of one machine running 8 copies of Conquest. This is done where the doctor read and stores the images for many sites. It is up to you.
In the deivr's I just moved the other default to the hpp file.
And Last, I fixed a comment date in filepdu.cpp.
The alpha has been running well for me 
.
http://www.bitsltd.net/images/…le/dgate1416a5changes.zip
Bruce
Hi Marcel,
I would like to make one more small change. I have a system that has many instances of dgate running on it. Every time I update, I have to move several copies of dgate into each directory. With the small changes I have made alpha 4, dgate can be given the command -wDIR, where DIR is the location of dicom.ini and dgate.dic files. The command sets DicomDict and ConfigFile file locaters. Now I can put dgate in a bin directory and only have to update one copy. In dicom.ini, I can set the location of any of the other files, like maybe etc. I would like to make this change to the alpha 5 I just grabbed, last change, really.
If you want, I can look into web server problem too. Also, if you want I can look into any issues that I can duplicate on my Mac (unix). Which one(s) do you want me to look at?
Bruce
Hi Marcel,
I will look at printing and try to leak test it.
Should I spread the DDO->Getxxx(g,e)'s throughout?
Bruce
Hi Marcel.
I think I have fixed AddAbstractSyntaxAlias, but is is only used in PrinterSupport and I have no way to test it. Maybe one day I can add unix printer support.
I did most of my work in deivr and nkiqrsop.cpp. I think I fixed the LastVR and LastVRG problems. I also add some routines to deivr now used throughout nkiqrsop.cpp. I hope you like them. It made my code a lot easier to debug. I did not spread them throughout the other files, but I could if you want. I also put RLE back. After looking closely at ReplaceVR, I realized that it does not replace the VR, but instead replaces with a copy of the VR. So after each use, I deleted the original. I would like to remove all uses of ReplaceVR from the code, it looks like a mess in deivr.cxx and hard to follow. Are any of the Special Value Code Of VR ([[FIX_TMS]],[[RGB_TO_MONO_PLUS]],[[RGB_TO_MONO]]) used?
Sorry, but I have made a mess of the nkiqrsop.cpp tabs and will try to fix them later, for now, just try to look at what I have done. 
I would move and build on 3 different systems (32,64,32BE).
Changes were only made to your last set of files posted and are here:
http://www.bitsltd.net/images/stories/file/dgateAlpha4Up.zip
Bruce
Hi Marcel,
I included a file with my changes: dgateAlpha4updates.
Here is a direct link to the zipped files.
http://www.bitsltd.net/images/stories/file/linux.zip
What I would really like you do is to try and remove as many "#ifdef __GNUC__"s as possible. I put most of them there because it is easier to delete them rather than add them, they show where my changes were made, and they leave the old code there. For examples:, I added member initializations, they are faster and should be used in all builds; protected copy functions are great to find memory leaks and invalid pointers, they should be in all builds. For QUES7:, I made the copy private and watched for the errors and warnings. The warning came in pdu.cxx, the is where the copy function is used. You will find comments in there as to what I think is happening. I would like to see what you think. For the virtual destructors, I liked this blog http://blogs.msdn.com/b/oldnew…ve/2004/05/07/127826.aspx , comment # 1. Most of your changes I kept, but I had to remove most of the DeleteVR() changes because they cause a crash when doing a JPG to J2K conversion.
What is the current windows system you are using to build, I'm thinking of setting up a windows box (or at least a virtual machine) to build on. Is the compiler open source?
Bruce
Hi Marcel,
Easy fix.
Change in ToJPG, at line 4746, from:
jpeg_stdio_dest(&cinfo, f);
rowWidth = cinfo.image_width * cinfo.num_components;
while (cinfo.next_scanline < cinfo.image_height)
to:
jpeg_stdio_dest(&cinfo, f);
rowWidth = cinfo.image_width * cinfo.num_components;
jpeg_start_compress(&cinfo, TRUE);
while (cinfo.next_scanline < cinfo.image_height)
I forgot to start the conversion ( I have total recall, except when I forget ).
Also forgot to free out if it errors!
Change in ToJPG, at line 4721, from:
if(f != NULL)
{
fclose(f);
if (!append)unlink(filename);
}
to:
if(f != NULL)
{
fclose(f);
if (!append)unlink(filename);
free(out);
}
Should we add ToJ2k? I can code just that part and send it to you to add to the file.
Bruce
Hi Marcel,
I look for the 8 byte ints, you are right, on 64 bit cpu, ints are put on the stack as 8 bytes, but all functions only use the lower 4.
I love the idea of expanding the VR class.
I hate the word slower, we could add a global or pass a bool to "parse*". I still like fixing illegal data, in or out. We could add a FIX_DATE_LZ.
Bruce
Hi Marcel,
Sorry to be a bother. I would like to explain some of the ways I use dgate, first would be a standard pacs server being sent and sending images, the second thing I do is take data from other pacs servers that no longer function, point dgate at them and rebuild the data base. dgate's feature to be able to recover images from servers that corrupt after the databases become to large ( Ex: eFilm, K-Pacs, OsiriX ) is a great one that I would like to keep. That is why the date is being fixed where I did it. I agree that we should fix the dates when the data comes in and I think where I did it will do that too.
I am currently running version 16 on three 64 bit systems, one 32 bit and I do some coding on my power pc laptop (32 bit, big endian). One thing that bothers me is lines like this:
iMaxRowsColumns = (unsigned int)(*((unsigned int*)pVR->Data));
because of the size of int is unknown. I would like to change them to something like this:
iMaxRowsColumns = 0;
For (int i = 0; i < 4; i++) iMaxRowsColumns = (iMaxRowsColumns << 
+ *(char *)pVR->Data;
Here, iMaxRowsColumns still gets to stay a faster int, but pVR->Data length is fixed at 4. This also fixes any endian problems. I could also use this method to remove most of the "#if NATIVE_ENDIAN == "'s.
I have found this in the following files
dgate.cxx:
iVrSizeLimit = (unsigned int)(*((unsigned int*)pVR->Data)); //2 places.
if ( *((unsigned int*)vrsilent->Data) == 0x44414544)
nkiqrsop.cxx
iVrSliceLimit = (unsigned int)(*((unsigned int*)vr->Data));
if (vr) MaxCompression = (unsigned int)(*((unsigned int*)vr->Data));
if (pVR->Length>8 && ((unsigned int*)pVR->Data)[1]>MAXNKICOMPRESSION)
iMaxRowsColumns = (unsigned int)(*((unsigned int*)pVR1->Data));
ExtractFrame(pDDO, (unsigned int)(*((unsigned int*)pVR2->Data)));
piHeader = (int*)pVR->Data;
piSrc = (int*)pVR1->Data;
iMaxRowsColumns = (unsigned int)(*((unsigned int*)pVR->Data));
trnsyn.cxx
CurrentGroupLength = *(unsigned int *)vr->Data; //2 places.
*((int*)vr->Data) = *((int*)vr->Data) + 4;//strlen("DICM");
I would really like to fix all of these and also get rid of the "#if NATIVE_ENDIAN =="'s if possible, however, if that seems like to much work to check after I'm done, I could just changes the ones listed above or just make the "#if NATIVE_ENDIAN =="'s in nkiqrsop.cxx. Let me know what you want me to do.
It looks easy to put the RLE decoder back, I could also do that when fixing nkiqrsop.cxx.
Bruce
