Hi,
in priciple yes, i think, but not in the existing code. Good for the wish list.
Marcel
Hi,
in priciple yes, i think, but not in the existing code. Good for the wish list.
Marcel
Ok,
change you change into:
#define SQLLEN SDWORD
and sorry for the errors ;->>> I usually compile for dbaseIII for testing on linux and now solaris.
Marcel
Hi, add
#define SQLLEN int
in odbci.hpp
Sorry, not all (10) builds are tested before I release. Someone should have picked this up in the beta.
Marcel
Hi,
you need to regenerate the database after you do this. This tag (0004,0001) = "Scheduled Station AE Title" seems a reasonable tag to use, but is is also used in the Worklist. I do not believe this is an issue (there are no queries that mix the worklist with the images), but take care anyway.
Marcel
Hi,
You can add a lot of information to DICOM objects using import converters (such as the originator AE) - and add it to the database as well. That may allow you to build your restriction. Do you have control over the viewing application? If not, you may have to install multiple servers and use ImportConverters to filter a priory (it can reject any incoming data), and then only allow viewing of a server with filtered information.
Marcel
Sorry, what DICOM software?
Marcel
This is correct,
but ROTMAN may not know CONQUEST and therefore reject. What kind of system is ROTMAN?
Marcel
Hi,
it is trying to use the postgres code, so obviously the wrong define is used in the make script. Can you check that.
Marcel
Hi,
there may be a stray USEDBASEIII file in your install: the gui thinks it must use DbaseIII, while maybe you use another database. Backup dicom.ini, delete it and re-set up should fix this.
Marcel
Hi,
maybe ROTMAN is not known on the server?
Marcel
Hi,
the dicomviewer does not support compression, so conquest must uncompress before sending. This does not modify the file.
I have seen the EOFexception as well, but it did not give any problems with my test data.
There are small differences how java reads from a cgi client and from a file. I noticed the .skip() calls did not work, but there may be other issues as well.... You can try if this is the problem by saving the file from the CGI link (cut and past from a viewer page source) and then serving it as file to dicomviewer - I noticed differences in behavior, while it is really the same data.
In any case, someone should further debug dicomviewer101 for it to be useful. The authors probably won't.
Marcel
Hi, the HL7 fields are set in DICOM.SQL, and can be edited without regeneration:
{ 0x0040, 0x0002, "StartDate", 8, SQL_C_DATE, DT_DATE, "OBR.7.DATE" },
{ 0x0040, 0x0003, "StartTime", 16, SQL_C_CHAR, DT_TIME, "OBR.7.TIME" },
So it is OBR.7.
If you want to extend the worklist, you can also add database fields, but then you need to clear the worklist to make it work again.
Marcel
Hi,
ftp://ftp-rt.nki.nl/outbox/Mar…erver/dgatepatch1414a.zip
exe for windows + source. Also fixes 1.4.14 bugs 2 and 4. Also adds some more web scripting options (in development).
Marcel
Hi,
The same as you would set it up locally. You may have to add port forwarding in your router for the DICOM ports that you use and configure your firewall if any. You can also try to install the web interface which should be easier and faster over the internet. It runs fine on top of apache.
Marcel
HI, THIS WILL BE AN OPTION OF THE NEXT RELEASE AFTER 1.4.14:
Sorry about the quotes ;->>>
WARNING: IF YOU USE THIS SCRIPT TO MODIFY PATID, STUDYUID, OR SERIESUID, YOU MAY LOSE PATIENT'S DATA
Marcel
Hi,
piping is not used. Many dgate commands can accept a format that can be any string. This is used heavily in HTML creation, but can also be used this way. Your script is nice too.
Marcel
Hi,
you can add access rules to dgatesop.lst.
name SERVER1 RemoteAE
This should restrict access to SERVER1 only. However, I have never used this.
Marcel
Hi lhendricks,
the server should recompress to "un" before sending data to the viewer. This can be seen in debug logging of the server.
Marcel
Hi Jason,
I think it cannot find the VRs for rows and columns (0028,0010) and (0028,0011).
Could these be in a sequence? Maybe try some other types of images like CT or MRI (not multiframe). To check that the correct image is delivered, "view source" in your browser and copy one slice url (until the *). If you pass that to your browser as address it should download the DICOM file (named dgate).
If all else fails you will have to debug the java code. The "here" is a leftover of my efforts :D. You can start by setting debuglevel to a higher value and recompile.
EDIT: the fail on the second slice occured for me as well but I had fixed in my release of the viewer: dicomviewer101.zip (above). You did use that one - the fix is a rest of Part10 flags after the exception handling. In any case, that viewer is buggy... I also added dicom.dic to the release zip tonight.
I am playing around with ImageJ but I now believe it is not possible to get it to display a stack from the server without recoding some of its innards. Hope someone will pick that up from me.
Marcel