[Ctk-developers] Fwd: [GitHub] Retrieve (and Database) bugs [commontk/CTK GH-16]

[Steve Pieper]

Hi -

A couple other responses to Dragon's helpful comments:

> - The network connection in ctkDICOMRetrieve is never "dropped". Consequent calls to the retrieve function ends up with the message that "The network address is already in use" as the association is never closed.
> Should include call to closeAssociation on several places. It would be even better to use the member SCU (narked as to-do) in the source, to make it even better. Special care should be taken on exception when called from "outside".

Agreed - I've been working on this in the dropNetwork branch and it's
working now but not yet merged into the master.  This is a work in
progress, and not consistent with the way DcmSCU is evolving in
dcmtk3.6.  I plan to finish up a ctkDICOMSend (storescu) and
ctkDICOMExport (to write out nicely formatted filenames for selected
studies) and then see if we can get integrate with the latest DCMTK.

> - Retrieved object are written to the disk two times. The portion of code "borrowed" > from the dcmdjpeg example should not exist in the retrieve code, because the data > (according to the design) should be and is written in the database.insert().

Which section of code are you referring to here?

> - Also, in ctkDICOMDatabase, there is a problem with retrieved object paths/filenames. The present system of using UIDs is not compliant with the DICOM standard, especially if you would like to create (proper) DICOMDIR and archive media. Paths and filenames should be generated to have max 8 characters according to the DICOM standard (check with Clunie if you don't beleive me :) )
>

I guess Jorg already discussed this - our disk cache isn't meant to be
used with a DICOMDIR - I'm thinking we should have a way to export in
appropriate format but it's not high on my list :D

> - Different behavior of in-memory and file database should not be implemented (at least not like that) in the Core library code. One should expect that the call to a function (insert()) should depend on parameters only.

Sorry - again which code does this refer to?

> - You should also correct the calls to database.insert() to reflect the needed use.
> For instance, in ctkDICOMQuery, the call to database.insert() is missing "false, false" (causing some side-efects, like trying to generate thumbnails for non-existent images)
>

Good catch!  I committed a fix to the dropNetwork branch.

Thanks again,
-Steve

On Tue, May 3, 2011 at 7:12 AM, OFFIS DICOM Team <dicom at offis.de> wrote:
>
> Dear all,
>
> Dragan Toroman wrote on "github":
>
>> - Also, in ctkDICOMDatabase, there is a problem with retrieved object
>> paths/filenames. The present system of using UIDs is not compliant with the
>> DICOM standard, especially if you would like to create (proper) DICOMDIR and
>> archive media. Paths and filenames should be generated to have max 8
>> characters according to the DICOM standard (check with Clunie if you don't
>> beleive me :) )
>
> That's only true for DICOM Storage/Exchange Media, and the DICOM standard does not say anything about what systems have to do _internally_ - including the naming conventions of DICOM files ;-)
>
> Regards,
> Jörg Riesmeier
> --
> OFFIS DICOM Team, Escherweg 2, 26121 Oldenburg, Germany
> E-Mail: dicom at offis.de, URL: http://dicom.offis.de
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers