Posts by Saturne

Thank you very much, Mark
François

Perhaps we can use a Lua script to do this? But I am not yet familiar with this language. Do you have an example in this case?
thanks

François

Hi, Marcel
I have to convert JPEG or BMP files generated by one of my devices in DICOM format.
I find the instruction --convert_to_dicom in the documentation of version 1.4.16
Can I use this dgate "convert_to_dicom" option ? What is the exact syntax of this option

Best regards
François

Good morning,
is there a reason for the "ReqProcDescription" field of the worklist to be limited to 16 characters?
Is it possible without departing from the standard DICOM to get it to 64 characters?

{ 0x0032, 0x1060, "ReqProcDescription", 16, SQL_C_CHAR, DT_STR, "OBR.4.1" },
->
{ 0x0032, 0x1060, "ReqProcDescription", 64, SQL_C_CHAR, DT_STR, "OBR.4.1" },

Friends are also using old Fuji XG1 CR readers, Netpix softwares and conquest PACS with no problem

François

I use Conquest PACS with a FUJI Netpix console. When archiving a radiography, everything goes well but in the log file (PACStrouble.log) I find that kind of error message :

20080306 18:45:50 Inconsistent BodyPartEx in DICOMSeries: PatientID = 'FJ000001354' SeriesInst = '1.2.392.200036.9125.3.481999235196.64547347310.117211' AND SeriesPat = 'FJ000001354', Old='UP_EXM', New='PELVIS'
20080306 18:48:30 Inconsistent BodyPartEx in DICOMSeries: PatientID = 'FJ000001354' SeriesInst = '1.2.392.200036.9125.3.481999235196.64547347310.117211' AND SeriesPat = 'FJ000001354', Old='PELVIS', New='UP_EXM'
20080306 18:48:37 Inconsistent BodyPartEx in DICOMSeries: PatientID = 'FJ000001354' SeriesInst = '1.2.392.200036.9125.3.481999235196.64547347310.117211' AND SeriesPat = 'FJ000001354', Old='UP_EXM', New='PELVIS'

What type of anomaly could be generating them ? How could I fix that ?
Thanks for your help.

Hi

I am using A Fuji Capsula CR Reader, with a Netpix Console and a Conquest Database.

It works well

Best Regards

First of all, I would thank a lot Marcel van Herk and Lambert Zijp for their great, great, great work.

We are currently developing a DICOM viewer designed to visualize and measure radiographic pictures stored in the PACS Conquest.
You notified in the Conquest documentation that when reaching 25,000 pictures the database size grow very quickly, and once a size of 2 Gbytes is reached no more pictures can be added.
We have encountered the same issue. Using Access Jet Engine “repair and compression” function (through Visual Basic, for exemple) we managed to divided the database size by more than four. Could Access ODBC driver or Conquest PACS generate useless spaces in the database ?

Using “repair and compress” function once a day (or week) massively decrease database size and greatly increase the number of pictures Access can deal with.

While developing another software using Access Database we encountered the same problem while successively adding and removing records. Access doesn’t physically suppress records but marks them as non usable and only suppress them when a “compress and repair” is achieved.
Could Conquest be executing the same kind of operation (successive adding and removing) when archiving a DICOM file ?

Anyway, a simple Access Jet Engine function call resolved the problem.

PS : Please forgive my numerous mistakes, I am French !