Conquest 1.4.16alpha...1.4.16alpha5 released

  • Hi,


    Hm, I am just done fixing the web issue and uploaded the tar file.


    I put the linux distribution here:


    ftp://ftp-rt.nki.nl/outbox/mar…estlinux1416alpha5.tar.gz.


    This version looks usable and is fit for testing. Bruce, please edit any files from here, changing as little as possible for your -w update. I have some open issues listed in the bug list; but most are in the windows GUI that I have yet to update.


    Marcel

  • Bruce,


    I will have to update. I somehow lost some of your changed files on my master PC, such as the conditional date fix; they are on my laptop. Sorry for that. Please send me your -w update asap, then I will put it in.


    Marcel

  • 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

  • Thanks Bruce,


    I will merge and do the last few items in the bug list soon. However, for a beta I need more time to update the manuals (lot of work), and fix the windows GUI. Guess I should also do a alpha5 for windows too to get people that are waiting going.


    Marcel

  • Hi Bruce,


    I seem to have an issue with lossy jpeg2000 compression. I configured the compression for conquestsrv1 as jl, and sent a CT study to itself. This compresses, transmits and decompresses the data. Afterwards the CT data was corrupted. This was a axial pelvic CT slice:
    [Blocked Image: ftp://ftp-rt.nki.nl/outbox/MarcelVanHerk/dicomserver/jl_problem.BMP]
    This occurs for windows 32 or 64 bits. Compression modes jk, j2 and j6 are OK. Can you have a look? I changed nothing in your jpeg2000 code.


    Marcel

  • 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

  • Bruce,


    I printed from a 1.4.15 server to the new linux dgate and it crashed here:


    Presentation Context 2 "1.2.840.10008.5.1.1.15" 0
    Server Command := 0140
    Message ID := 01c5
    Creating Basic Film Session
    Server Command := 0140
    Message ID := 01d1
    Creating Basic Film Box with 24 Image boxes - PORTRAIT - Film# 0
    Server Command := 0120
    Message ID := 01dd
    Print file: ./data/printer_files/99999.99999.6.1283798261.1.0.4.6.0.dcm
    Server Command := 0130
    Message ID := 01e9
    Printing Basic Film Box
    UPACS THREAD 0: ENDED AT: Mon Sep 6 14:37:42 2010
    UPACS THREAD 0: TOTAL RUNNING TIME: 2 SECONDS
    <crash>


    This is the stack trace:


    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0xb7545b90 (LWP 13311)]
    0x080f744e in Array<TransferSyntax>::RemoveAt ()
    Current language: auto; currently asm
    (gdb) bt
    #0 0x080f744e in Array<TransferSyntax>::RemoveAt ()
    #1 0x080f74f3 in Array<TransferSyntax>::~Array ()
    #2 0x080507be in PresentationContext::~PresentationContext ()
    #3 0x080f7525 in DataLink<PresentationContext>::~DataLink ()
    #4 0x080f7623 in Array<PresentationContext>::RemoveAt ()
    #5 0x080518b0 in AAssociateRQ::~AAssociateRQ ()
    #6 0x0806309e in PDU_Service::~PDU_Service ()
    #7 0x080633c7 in CheckedPDU_Service::~CheckedPDU_Service ()
    #8 0x080ed663 in StorageApp::ServerChild ()
    #9 0x0804f79c in DriverApp::ServerChildThread ()
    #10 0x0804f7d4 in DriverHelper ()
    #11 0xb802250f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
    #12 0xb7e767ee in clone () from /lib/tls/i686/cmov/libc.so.6


    Seems like an issue with the modified transfer syntax alias code. Can you help please?


    Marcel

  • 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


    http://www.bitsltd.net/images/…e/dgate1416a5_changes.zip

  • 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,


    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 Bruce,


    what are the typical sources of mpeg data, or in other words, how much of a problem is this? But uncompressed or mpeg sounds good.


    For the other suggestion, it is of course very easy to add an echo command to dgate, like dgate --echo:port:ip, or dgate --echo:AE


    Marcel

  • 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

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!