Posts by Davidone

Hi Marcel. I have a 'little' request for you.

In our organization we use a Worklist server to simplify the transcription of the patient data (name, surname, age an so on).
Our Worklist Server interpose the ' ^ ' letter to separate Name and Surname (eg. DON^JOHN instead of DON JOHN).
Unfortunately sometimes happens that we need to insert patient data manually and we forgot to insert the separator as before by using the spacebar (this is the natural uman writing method).

When we need to do some DICOM query the response could hide all the patients separated by ' ^ ' or speparated by the carachter space.

There is a way to tell to Conquest to consider ' ^ ' and ' space bar ' equivalents and then obtain a complete Dicom response ?

I know that inside a DICOM query I could use Jolly carachters ' ? ' or ' * ' but isn't so confortable. And in the web queryes theese characters cannot be used.

If not could be a "useful" feature to be introduced in the future ?

Thanks in advance, Davide.

Hi Giozera.
Thanks for you answer. I'm very impressed about your set-up.
I'm using Conquest basically as Dicom file server (like a PACS) to store thousands of images every day after they were reconstructed and reviewed thought a medical workstation.
Every time we transfer images from or to Conquest to comply daily activityes. This is a very simple case use.
In your set-up you are using conquest both as server and application software, so I think you have done a greath job until now by using a lot of Conquest Functionalityes like database and image archive sharing, and by virtualizing PACS concept.
I think that the best definition about your set-up is very similar to a "Conquest Cloud" !

Now about speed I unfortunately never used Conquest in that way, so I cannot help you to improve performances.
In this case use the network is the most important thing, so you have to check if there are too much packet collisions and CRC errors during communication (there are several network protocol analyzer software to monitoring network activity and check if everything is going well).

About your NAS I'm sure is a very good system, but usually network drives doesn't take advantages of server RAM cache during file system transactions, so I think it's normal have less performances that by using DAS or internal HDDs.

I'm sorry. I can't be useful this time !

Davide.

Quote from giozera

Hi Marcel
would removing mirroring from clients end will improve perfomance? I don't think would be possible for me to have exact copies of 4TB of images for all clients. I only see network the best way to do what we need to do everyday work. so my dicom.ini looks correct for that setup? thanks

Hi Giozera. I'm self add to the discussion again, sorry for my intrusion.
I'm a bit confued about your set-up.
If I understand correctly (in your example) you are using a Conquest main server and 4 separated Conquest server used as some sort of "Dicom Client".
All this systems are connected together by a Gigabit class LAN and the database server is shared over all 4 clients + main server.
About storage, all the images are stored in a central NAS shared over the network and they are mirrored over a second NAS.

In this Way every client can see and access to all the images stored over the Main server without need to mirror It locally.

Can I ask why this kind of solution ?

In my installation site I'm using a local 2 Tb HDD Raid as MAG0 and 8 Tbyte over a NAS as MAG1 and when I access to the images stored over MAG1 unit the speed isn't so fast than MAG 0 unit. Of course the performances depends on the NAS characteristics but sharing a lot of files trought network cause network protocol overhead.
A better performance solution is based by using a DAS array instead of NAS, but in your installation this can't solve the problem al all.

Could be feasable to use one Central Conquest server and "n" clients made by Dicom Gateways (of course by using Conquest but without local storage of the images) ?

Sorry for my stupid question but I'm curious about that

Best regards, Davide.-

Hi Giozera.
For my installation site I used XAMPP as webserver and datadase server and all worked fine.
After some years I needed to change the server used for Conqest so I decided to rebuild It from the scratch to "upgrade" to 64 bit. This time I used WAMP because some components support 64 bit and I've got some start-up problems. XAMPP and WAMP are basically composed by the same software modules (MySQL and Apache), but theese distribution have differents default configuration, so I needed to "study" a little in order to use Conquest with WAMP. So in some cases is better to restart from the scratch as you have done !

By using MySQL as database Conquest is very fast than internal database server.
If you take a look at Conquest documentation you will find that internal database is useful for small installations, like Dicom Router / Gateway, test and very small archive storage (up to 100.000 images). If you plan to use Conquest for production server you need to use external database and MySQL is one of fastest and cheapest
In my installation site I'm using Conquest from 2009 and I stored about 20 millions of images (90% CT+MRI and 10% CR+XA) using Conquest with MySQL over a Intel i5 @ 3.2 GHz and Windows XP 32 bit ! Both Dicom query and Web query are processe in realtime and take the time for a click.

About web crashes, unfortunately I have the same problem. If the web query returns about 900 - 1000 data row or more the web dgate.exe crashes and I can't see anithing in my web browser. I think colud be a buffer overflow or something like this.
If you do the same query by using a DICOM client It works fine, so I suggest to use a dicom client like K-PACS or similar to achieve the result and bypass the problem.

I'm a conquest user just like you and then I could not obtain a complete view of the system.

Davide

Hi Giozera.
I add by myself to the discussion.
About MySQL error I think Marcel was thinking a sort of "start-up" problem.
By booting Windows if Conquest dicom server starts BEFORE the MySQL service is started and initialized, you could obtain this error message. If you are using the Conquest GUI, try to flag "Keep Server Alive" showed in the CONFIGURATION TAB.
By setting this flag:
- If the database connection fail, It will retried after some seconds, and shuld work properly then.
- If the database connection continue to fail then you have some kind of problem (networks, sockets, ports, firewall, and finally database user account used (access permission and user type), and needs to be investigated.

About web crash Something I get the same error if the matching results list is too long (don't know exactly what is the limit but when around 1000 lines the web query crashes).

Best regards, DAvide.

Quote from marcelvanherk

Hi,

the option 'find patient on local' is local, it uses a database query.

the option 'find patient on server' when applied to local uses a dicom query and will go into virtual servers.

I realise that the latter option does not have a viewer (e.g., weasis) link.

The scripted interface by Luiz (packed i n in the 1.4.17d release) uses dicom queries and should go into virtual servers. ImageDate and ImageNumber in the lua scripts should be replaced by InstanceDate and InstanceNumber though.

regards,

Marcel

Display More

Thanks again for your reply Marcel.
I was out of business for the last month due to a car accident where someone didn't stopped at the right time and knocked to my car !

Now I'm back here !

1) About scripting and Virtual Server I can undestand what are you suggesting me, but unfortunately I'm not so trained about lua and programming other than my alarm clock
I realize that whith LUA could be possible resolve almost needs but I'm too stupid to undestant how without examples (I'm a dumb, and I need to study a little ).

2) Now I want to report to you a little Conquest misconfiguration about Weasis.
Taking a look at the file LaunchWeasisStudy.cq at rows 72 and 73 we have the following parameters:

<!-- Optional parameter. Allows to get plug-ins translations -->      <argument>-VMPweasis.i18n="http://%server_name%/weasis-i18n"</argument>

Actually with Weasis 1.2.9 this is not correct. In order to load correctly the multilanguage plug-in you need to adjust the path and the folder name as follow:

<!-- Optional parameter. Allows to get plug-ins translations -->      <argument>-VMPweasis.i18n="http://%server_name%/weasis/boundle-i18n"</argument>

I think that this fix could be useful to be included in the next Conquest release, and should be updated also launchWeasis.cq file.

3) About 1 month ago was released Weasis 2.0.0.0. I think this is the beginning of a new Weasis Fork.
In this new release some things has changed and needs to fe fixed in order to work correctly with Conquest.
By downloading Weasis 2.0.0.0-portable, if you execute It locally all works fine, so I assume that this release works fine.
Unfortunately when extracted weasis folder from the archive into the web server folder, I've found that Weasis 2 works in little different way, perhaps due to incomplete parameters passed during initialization.

1. There's a missing file needed to launch Weasis: substance.jnlp. I've taken It "as is" from the old version (1.2.9) and this issue was fixed immediately.
2. Don't ask me why but I needed to make a .zip of the content of the folder resources and place It in the same weasis folder. Ofcourse after this the 'resource' folder can be deleted ! this folder containg weasis logo and icon, LUT presets and Windowing presets. Isn't mandatory to have this loaded but could help
3. Language initialization is Always English unless the user manually modify the settings in preferences. If you want to start weasis with a different language localization you need to edit the file ext-config.properties inside conf folder and need to uncomment rows 33 and 35 and set the language you prefer.
This is the original untouched portion of the configuration file:

##### Language code (see Java Locale: http://www.oracle.com/technetwork/java/javase/locales-137662.html). Default value is "en_US". If value is "system" then the locale of the operating system will be used (client-side).
#locale.lang.code=fr
##### Format code for number and date (see Java Locale). Default value is "system". If value is "system" then the locale of the operating system will be used (client-side).
#locale.format.code=fr_CH

Perhaps this isn't the perfect way because this is a sort of override, but for now I solved the problem in this way.

I repeat again: by lauching weasis using the Win32 loader the program loads correctly, so I suspect that there are new parameters that needs to be passed from the weasisstudylauncher.

This isn't a bug. Is a natural evolution of the software.

Now I hope that my personal experience could be helpful to other peoples and to try to find a way to keep up-to date the weasis's Conquest launcher.

Thanks for reading this. I apologize for my bad english... I can't do better !

Davide.

Hi Marcel. I'm back again.

I checked the Dicom gateway functionality and unfortunately It Isn't available by the web interface.

For example. I set:
VirtualServerFor0 = PACS

Where PACS is a real PACS fullfilled of Tons of Dicom studies.

By using a Dicom client like K-PACS if I query CONQUEST I can see all the studyes on both PACS and CONQUEST (and of course I can retrieve them). But If I try to query CONQUEST from web interface I can see LOCALS studies only.
Of course I can use the function "FIND STUDIES on server PACS" but in this way i need to push It to CONQUEST before I can be able to see it through Weasis.

I've certainly discoveret hot water, but for a moment I hoped that the gateway was also possible via the web interface.

There is another way to do It ?

Thanks again for your attention.

Davide.

Quote from marcelvanherk

Hi,

In the 1.4.17d code it should react to the:

compress = un

feature of cgi-bin/dicom.ini. I suggest to use J2 as jpeg2000 is very slow.

Marcel

Display More

OOOPS !

I swear to have taken a look at dicom.ini file and..... found nothing !
Thanks Marcel and sorry for my eyes !!!

But now I have another 2 questions are opened.

1. I used a Brain MRI to make some tests and Weasis work well, but in some cases series are splitted in differents sub-series. For example. The Localizer series contains 5 axial images, 5 sagittal images and 5 coronal images. When I open this study with weasis I can see the series splitted by plane (5 ax, 5 Sag and 5 coronal).

2. Thanks to Conquest and Weasis a possible application is to make a conquest dicom gateway able to get images from differents PACS and then display by weasis. Unfortunately the Dicom gateway isn't available thought the web server. There is a way to do It ?

Thanks again for support and have a nice day.

Davidone.

Hi to all.
First of all thanks to all the people who worked during last year to find a way to set-up Weasis with Conquest. Greath JOB, REALLY !
After this I have a question (forgive me, I'm a noobs about Weasis and Java Applets).
I know that Weasis support Dicom Uncompressed and Dicom JPG and JPEG-2000 compressed images.
There is a way to use this feature ?
In my Test installation I can see that all the images are recompressed to UN ( = Uncompressed), and this cause a huge network load during images retrieve.
For an Internet Connetion for example Lossless JPEG 2000 or JPEG are the best way to send all the images quickly without loosing image quality at the other side.

I've taken a look to the WEASISSTUDYXML.LUA and I saw that there is a specific section used to set the wadoTransferSyntaxUID, but It appears to have no relevance over the transmitted files.

I'm doing something wrong ?

Thanks againg for reading this, and have a nice Conquest !

Davidone.

Thanks to all for your reply.

In the meanwhile I've taken a look at log files and didn't see any warning or error messages.
I think he's right .... Marcel. I suspect that my NAS is not very efficient in carrying out this operation (It took several days to complete the task).

I hope to have found a sort of workaround. I've just taked a look at the DGATE.EXE command list and tried to use the following commandline

dgate.exe --regendir:device,dir

Unfortunately It doesn't support wildcards. In my mind I was thinking to regen small parts of my MAG1 device. eg. all folders starting by "A" ( dgate.exe --regendir:MAG1,A* ) then all folders starting by "B" and so on.

So I've decided to use the following "strategy":
- dumped to file the root directory list (eg. from MAG1 folder by tiping "DIR > Myfolders.txt")
- edited the obtained file in order to clean all the not needed information and to leave only "<DIR> FolderName" ( I used Ultraedit, a text editor that enable to edit by columns, non by rows only).
- replaced the word <DIR> with the dgate commandline (dgate.exe --regendir:MAG1,FolderNAme)
- saved the result as a batch file.

This resulted in a file containing the dgate commandline for each folder (about 24.000 in my case).
As last operation I splitted this file in 10 smaller parts in order to have "more control" just in case of errors or troubles.

Last step: run each batch file one by one and see the results.

Perhaps this solution is a bit "dummy - home made". I apologize for this low-end solution but I'm not a programmer and wasn't able to do better, but At present Conquest regenerated about 8.000 folders without errors and finally I saw growing-up the number of images stored in the database.

Maybe if the --regendir:device,dir option could be able to supports wildcards It could semplify operations like this, but as said before I'm not a very expert user.

I hope my experience can be helpful to other peoples with little experience like me.

Comments and suggestions are appreciated. Thanks again to all. Davide.

P.S. Marcel. If you want to see some of the images that crash the dgate server during regeneration I can send to you by private mail. Theese could help you to improve the stability

Hi Marcel. This is Davide after several months of "silence".
First of all I want to thanks a lot for your work and your continuous support to the entire community through these years.

I'm a happy Conquest user from 2007 to manage various radiological images.
From 2010 I decided to use Conquest to store our historical images produced by CT and MRI scanner. So we set-up a Windows 32 bit dedicated server with a lot of storage.
Everything was ok until some days ago where our main RAID controller had a hardware failure and in a couple of days some files were damaged.
This accident involved some system Files including the Database (MySQL) and a little amount of images.
At the time of failure we where storing about 24 millions of CT/MRI images; 7 Millions images stored in MAG0 (1,5 Tb Internal RAID) and 17 Millions images stored in MAG1 (5,5 Tb external NAS).

Well. After this event I decided to change the server with a new one (was about 5 years old), reinstall all the software from the scratch and then to Rebuild the image database starting directly from the images stored, using the latest Conquest version (1.4.17d). All the images were stored in NKI format .V2

This operation was done in a few days for MAG0 (Regen MAG0) where the operation was interrupted several times when Conquest ecountered inconsistent damaged images and in some cases causing a VR Memory allocation Failure and a consequential Crash of DGate. With patience I isolated the damaged studyes and then restarded MAG0 Regen everytime.

Then I started to Regen MAG1. With surprise the operation was done in a short time, but when i Opened the database I saw 11 Millions images stored only, instead of 24 Millions.

The question is: MAG0 was rebuilt perfectly. There is a reason to explain why MAG1 was rebuilt with 3 or 4 Millions of images instead of 12 millions ?
MAG1 file system does not contains errors or damaged images and the folder structure is simple: z:\Mag1\%ID_%NAME\%StudyID_%Modality\%SeriesID\%Sopuid.v2

There is a limit in the number of folders scanned by REGEN MAGX procedure ? In his case in MAG1 contains about 23.000 subfolders but It seems that Conquest regenerated a minimal part of these.

Could you kindly suggest me a way to regen MAG1 completely ?

I'm trying to make a file containing the complete file-list to submit by using DGATE.EXE --regenfile:file

Any help or suggestion would be appreciated.

Thanks for your attention, Davide.

I'm agree with you
Fortunately today RAM doesn't cost too much

Bye, Davide.

Hi Marcel and thanks again for your reply.

Unfortunately our CT scanner is last generation 64 slice and It generates a lot of images for each series and It happens very often that one single series is composed by more than 770 images.
For example sometimes for a Body scan or for an angiographic examination the images contained in a single series can be up to 3000 images. Ok this is very sporadic limit but it's normal to need to manipulate 1000 images for a singfle series.

By the web interface I can't select a little slice group... I can download the single image or the single series (the single atom or the entire building but this isn't a big problem. I use the web interface as facility in order to get the series from everywhere instead to modify the dicom node list because in certain situations I have a dinamic IP and this isn't compliant with DICOM node maps that requires static IP.

One of my friends suggested to use objects and libraries that works with streams that can be kept in memory or to disk.
A low impact for the Windows version could be to change the MALLOC() instructions with Windows API that permits to specify if the memory has to be Phisical RAM or storable in Virtual memory if the Phisical RAM isn't enough to perform the request.

I repeat again... I'm not a programmer and I'm only doing copy/paste of discussions between me and one friend who tried to help me and I'm writing you for an accademic/philosophic discussion not more, not less.

THanks again and have a nice week-end

Davide.

Quote from marcelvanherk

Hi,

the zip file is transmitted as DICOM object and is sent and received in memory.

Marcel

Ok Marcel and thanks for your reply.
In the past 5 days one of my friends told me about this issue:
------
Could be a matter of how the data are managed. For example assuming the following variables:
A = 500 Mbytes of data (Memory ALLOCated)
B = 600 Mbytes of data (Memory ALLOCated)
C = A + B

The total committed system memory will be: 500 + 600 + ( 500 + 600) = 2.200 Mbytes of System RAM and depending on how the memory allocation is requested the entire memory commitment could be allocated over the available Phisical system memory only (without taking the advantages of swap / virtual memory).
------

Perhaps we are facing a similar memory issue and without changing something the only available solution is to "upgrade" the system to a 64 bit environment equipped with more system memory in order to bring up the memory limit issue by 2x or 3x.
Otherwise there is the possibility to take in consideration the use of temporary files for theese kinds of huge DICOM object on order to save system memory ?

I'm asking this for a sort of "accademic discussion" only and remember I'm not a programmer, I am an idiot who likes to use the computer and (unfortunately for you) loves conquest

Thanks for your patience.

Best Regards, Davide.

Hi Marchel and happy new year

I have a little issue with Conquest 1.4.16(h) form the web interface.
The Dicom Server runs over a Windows 32 bit environment with 3 Gbytes of system RAM (less than 600 Mbytes comitted by the system when running) with Apache httpd server.

By using the web interface.....
When I try to push as .ZIP archive a selected study containing up to 770 CT images everything goes well and I can download the .zip archive perfectly.
When I try to push as .ZIP archive a selected study containing more than 770 CT images the .zip archive is truncated after some Kbytes and I can't get the images.

By doing several tries by using huge CT studies made by more than 3300 images at a certain point The Dicom server just crashed and i got A VR Memory allocation Error in server status( for example "can't allocate 650 000 000 bytes" ) then the dicom server crashed and stopped to work until Kill and Restart.

I suspect could be a memory allocation problem but conquest log isn't helpful to find at what point it happen.

So I've tried to track out the operations done during this procedure.

a) When I click over Push ==> ZIP file the server copy all the selected study images to che directory /printer_files.
b) After the copy has finished It's time to create the .ZIP archive and i can see 7za.exe running in background and I can see the .zip archive increasing.
c) after the archive is created it "disappear" from /printer_files and I get the download prompt in my internet browser.

This is the Apache log when the server crash.
------Apache log ----
[Wed Jan 11 00:55:13 2012] [error] [client 192.168.0.12] Premature end of script headers: dgate.exe, referer: http://192.168.0.232:85/cgi-bi…0147437.372&source=(local)
------And of apache log----

What happen after the zip archive is created ? It's deleted from the file system and kept in system memory until the download has finished ? I wasn't unable to find It over the entire file system

If the archive is more than 200 Mbyte could be a memory allocation issue with 3 Gbytes of system ram ?

Considering that the dicom server log doesn't report any problem or anomaly could be a dgate.exe issue of the web server ?

Could be an apache memory configuration problem ?

Sorry for my english. I hope you can understand what I have done.

Thank you for your attention and best regards, Davide.

Quote from marcelvanherk

Hi,

just released version 1.4.16d

Marcel

Hi Marcel.
I've just tested the new release and It appears to work perfectly.
Unfortunately I'm a very mindless user so I have no idea about how to write the zip.cq script in order to download the selected study directly from the web interface.
Actually when I try to push the selected study to a ZIP file taking a look in the Conquest log window I can see a message for each image that say:

[CONQUEST]*** Importconverter-1.0 script not found: zip.cq

I know I sould have the informations to write my zip.cq exportconverter file but I have no idea, I'm sorry.
Can you suggest me something please ?

Thanks for reading this and have a nice holidays.

Davidone.

Hi Marcel.

Perhaps i've missed some posts but I have an issue with the ConquestUpdate1416c.zip work in progress version.
By using the serverside viewer I can view correctly the thumbs but when I try to "view" the images theese appears to have the same resolution of the thumbs but magnified up to "size" value (default 560 pixel). Doesn't matter what kind of image is viewed, this is constant in my system.

This issue happen with che ConquestUpdate1416c only so I think isn't my configuration fault.

Thanks in advance for your help.

Davide.

Hi Marcel.

Unfortunately I'm a Windows user so I don't think to be able to do this.
Don't worry, this is a wish only so there is no need to make changes to the code.

Actually I can get the study in my desired format by doing some steps like:
- getting the study from the web by using your new feature
- importing the .v2 study inside a conquest server ran locally in my PC
- using K-pacs to query locally the server and get the study in a uncompressed format then
- using K-pacs to export the study as CD but saving the project only to obtain the images uncompressed inside a folder.

This is a little complicated but It works

Thanks for your attention.

Davide.

Hi Marcel.

When i read about the wish list #11 (to get a .zip study from the web interface) I downloaded and immediately tested your new release in progress.
The feature works great but I'm asking if there is the way to "enhance" It.

The Dicom study is done by zipping directly the files archived inside the dicom server but this means that the image format is the original used by Conquest.
If Conquest is set-up to use NKI compression the result is a series of .V2 files that needs to be "translated" by a local conquest run by the user.
There is a way to specify the image format in order to have the study ready to be used by the user who requested it ?

The best solution is to let the web user to specify the image format output (un, as, jk, j4,.....) or otherway the simplest way is to uncompress the images to "un" before making the .zip archive in order to have full compatibility.

This would be a very useful feature for me and I hope to others Conquest users.

Thanks in advance for reading this.

Davide.

OK. This is a very long post.... I hope not to be too boring.

Finally I have done some tests in order to evaluate the global efficiency of Conquest's image format compression algoritm.
The hardware used was a common PC equipped with Intel i5 @ 3.2 GHz, Windows XP 32 bit and Conquest 1.4.16 + MySqI 5
I selected a very big study composed by about 3,500 images generated by a 64 slices CT scanner made by General Electric (Discovery CT750-HD).
I sent several times the entire study to the Conquest server trought a 100 Mbit/sec LAN changing at each try the method used by Conqest to save the images to Disk and taking a note about elapsed time needed to complete the task.

Images sent: 3492

LOSSLESS METHODS
UN = Uncompressed - Standard DICOM 3 format.
Time needed: 192 seconds
Archived Data: 1.809 Mbyte
Compression Ratio: 1:1 = 100 %
Speeds = 18 images /sec. Equivalent netwok speed = 77 Mbit/sec

N4 = Lossless compressed – Custom NKI V2 format.
Time needed: 212 seconds
Archived Data: 818 Mbyte
Compression Ratio: 1:2.21 = 45 %
Speeds = 16.5 images /sec. Equivalent netwok speed = 32 Mbit/sec

J2 = Lossless compressed – Standard Jpeg DICOM 3 format.
Time needed: 262 seconds
Archived Data: 735 Mbyte
Compression Ratio: 1:2.46 = 41 %
Speeds = 13.3 images /sec. Equivalent netwok speed = 23 Mbit/sec

JK = Lossless compressed – Standard Jpeg-2000 DICOM 3 format.
Time needed: 473 seconds
Archived Data: 630 Mbyte
Compression Ratio: 1:2.87 = 35 %
Speeds = 7.4 images /sec. Equivalent netwok speed = 11 Mbit/sec

LOSSY METHODS
J6 = Lossy compressed – Standard Jpeg DICOM 3 format. @ 95 % Quality
Time needed: 260 seconds
Archived Data: 734 Mbyte
Compression Ratio: 1:2.47 = 40 %
Speeds = 13.4 images /sec. Equivalent netwok speed = 23 Mbit/sec

JL = Lossy compressed – Standard Jpeg-2000 DICOM 3 format. @ 95 % Quality
Time needed: 516 seconds
Archived Data: 481 Mbyte
Compression Ratio: 1:3.76 = 27 %
Speeds = 13.4 images /sec. Equivalent netwok speed = 7.6 Mbit/sec

Following my personal consideration after theese tests.

1. On an up-to-date PC/server there are no reasons to NOT use NKI compression as default saving method over a dedicated server (PACS). The difference in time needed to save the study in NKI format is minimal compaired to the possibility to double the archive capacity. Obviously you need to keep Conquest as "media converter" to be able to read the images with a third party workstation or system but the work is done "on the fly" and is totally transparent to the users.

2. Using Lossless JPG compression algoritm permits to achieve e better compression ratio than NKI and to keep the Dicom compliance of the saved images for Workstation / viewer Dicom-JPG enabled but you need to "pay" a small amount of time to complete the task.
In addittion JPEG algoritm usually are asimmetric. This means that the time needed to Save/Encode an image in JPEG format is more than the time needed to Read/Decode the same image.
The storace capacity could be increased by 10 % than NKI compression. Could be a NKI alternative and moreover could be a good way to send the images to a workstation in order to speed-up the transfer time over a slow network.

3. The Lossless JPEG-2000 algorithm is an improvement of te "standard" JPEG. This was born at the beginning of the third millennium and introducing big enanchements like wavelet compression and other features. Unfortunately isn't very diffused and there aren't a lot of dicom viewer able to display this Dicom image format.
Using this image format "costs" a lot of time (2 X than NKI compression time) but It permit to increase the storage capacity by 20 - 25 % so could be a valid solution for long term archiviation or to transport the images between geographically dislocated Conquest servers connected by a low bandwith connection (10 Mbit/sec or less).

4. The use of lossy JPEG / JPEG-2000 algoritm is more difficult to evaluate because there are a lot of medical and legal considerations to take about the image quality threshold and the possibility to lost diagnostic informations inside the images. This is a simple compression test and I don't want to be involved in medical and ethic discussion, I hope you undestrand
The main difference between JPEG and JPEG-2000 is that JPEG is very fast than JPEG-2000 but with JPEG-2000 you can achieve a better compression ratio than JPEG introducing a very small amounts of image artifacts. In my test 95 % of image quality permits to display the images apparently avoiding any kind of image artifacts reducing the image size in a very significant way.
This opportunity is perfect to transport images over low bandwith networks like internet/VPN in a relative short time (in my test the equivalent transfer rate was 7.6 Mbit…. Very near to HDSL / VPN / internet connection bandwith).
In this way for Telemedicine, second opinion, other It’s possible to shorten the transfer times about 4 times without loss too much quality.
Could be also a way to definitely archive very old long term archives that can't be involved medical or legal issues.

5. Other image formats / the future.
If you take a look over the internet there are a lot of discussion about the possibility to introduce an advanced Jpeg-2000 3D compression algoritm able to increase in a significant way the compression ratio.
Today we compress/decompress every image as is... as standalone image but for some modalities this image is part of a volume (think to a CT elicoidal scan for example or fluoroscopy or ecography and so on).
Both lossless than lossy algoritm could have a lot of benefits if the images of a series could be considered and compressed as a "single 3D volume" pack increasing the compression ratio.
In this vision every slice is correlated to both previous and next slice and you need to save the differences only between a "key-image" and the following images.
This is a reality when you watch a youtube video or DIVX / XVID /H.264 video.
Of course the better results will be achievable with lossy compression algoritm with a big compression ration compaired to the introduced artifacts.
Some tests are demonstrating that this method could multiply by 2 or by 4 the compression ratio without significant loss of quality enabling the possibility to have a compression ratio of 1:8 or 1:16 without risks !!!
My dreams are thinking about a future implementation of this possibility but to do this we need more CPU power than today and the definition of e new updated Dicom image format (or - NKI V3 proprietary image format) to be used for telemedicine or other network related activivies.

Have e nice heaster time.
Davide