Posts by liesenfeld

Hi Marcel,

it seams that conquest writes dicom tag 0002,0010 to 1.2.840.10008.1.2.4.70 instead of ...57 when compressing incoming uncompressed images to j2! That seems to be the only bug.

Everything else behaves like it should. So when retrieving these files they get recompressed because of the wrong header: ...57 is requested, but ...70 is stored so they get recompressed althoug actually they are already j2 (there is no more j1 compression in the code) but with wrong header and then by recompressing they get the correct tag ...57.

Incoming files already having tag 0002,0010 set to ...57 are stored as is whithout recompression and ...57 stays in the header.

Hope this helps!

Heinz

Hi Marcel,

just trying 1.4.17alpha. Again the issue with j2 and j1:

I configured conquest: dropped j2, incoming j2, archiving as. When sending already j2 compressed (1.2.840.10008.1.2.4.57) to conquest, they are just stored without recompression and also retreived with j2-configured client without recompression (good so far), but when sending uncompressed data to conquest, conquest says they are compressed as j2 but actually they are stored as j1 (in 0002,0010 in conquest header dump 1.2.840.10008.1.2.4.70) and need to get recompressed to a retrieving client configured to accept j2. In the client the dicom header then is 1.2.840.10008.1.2.4.57. Sending these files back to conquest is handled correctly: just stored without recompression, and by again retrieving no recompression required.

Sending files retrieved from older version of conquest identically configured (stored as j2 and retrieved without recompression, tag 0008,2111 lossless jpeg selection value 6) to new conquest-server get recompressed and header in new conquest server shows (0002,0010) UI [1.2.840.10008.1.2.4.57] # 22 TransferSyntaxUID. But when retrieving again these files again are recompressed by conquest server to j2 although they should already be stored as j2! [CONQUESTSRV1] [recompress]: recompressed with mode = j2 (strip=0)
Some confusion on my side!

As I changed my job, it is not essential for me, but I think it's an issue.

Best wishes for the new year!

Heinz

Hi Marcel!

The builtin compression (at least the j2, which I use), sets tag(0028,0101) = bits stored to 16 instead of 12.
My Clearcanvas clients complain about the mismatch of (0028,0102) = high bit, which is correctly set to 11.
This should be 0 or (bits stored - 1).
Other clients don't bother about that.
I'm using 1.4.16rc4.

For now, as I have some Clearcanvas clients, I'm back to external compression with the OFFIS-Consortium executables.

Again thanx for all your work!
Heinz

Hi Marcel, hi Bruce!

Thank you very much!
This again shows the superior workflow of open-source to closed-source !

Heinz

Hi Marcel, hi Bruce,

my link to wikipedia was some lines to far in that file, the explanation of sv1 vs. sv6 is just above JPEG-LS.
Cluny describes the differences between lossless jpeg sv1..6..8 vs. JPEG-LS vs. J2K and several other compression algorithms on medical images in

http://www.dclunie.com/papers/…comCompression_Clunie.pdf

Lossless jpeg sv6 seems to have slightly better compression than sv1, which is identical to my own experience, but the difference is very small.
So my suggestion for a quick and dirty fix:
- Use the new internal j1 compression, even if j2 is configured
- do not recompress incoming j2 files, just store them
- write correct tags (...70 for j1, leave ...57 for incoming j2)
- send the files as they are without recompression on both requests by the client j1 or j2
- add optional modification of tag from ...70 to ...57 on outgoing files if client rejects ...70 (not DICOM-conform)
The decompression algorithms are identical, so I see no problem in this optional deviation of the standard.

Heinz

Hi Bruce,

j1 has selection value 1, j2 has selection value 6, see here for the difference:

http://en.wikipedia.org/wiki/JPEG-LS#JPEG-LS

It is a problem, cause conquest makes that difference. All my clients are configured to prefer j2, so the files stored with dicom tag ...70 instead of ...57 get recompressed (decompressed and again compressed), which means a very high load on the server. I switched back to version 1.4.14, because no recompression is required with the files stores with tag ...57, they are just sent.

With several concurrent threads this means an improvement of up to factor 20 in time.

Best regards,
Heinz

Hi Marcel,

I guessed it was just the uid set wrong because retrieving with a j2-configured client lets conquest recompress to j2.
My setup for this:
Conquest1: getting all dicom-pictures from the modalities, wrongly stored as j1, forwarding to Conquest2 as j2, all forwarded pictures get recompressed to j2 before sending, in Conquest2 they are just stored with correct uid ...57 without recompression. Clients configured to j2 get them from Conquest2 without recompression.

Does this help?
Heinz

Hi Marcel,

could this be the bug in line 4633ff of nkiqrsop.cpp: ?

// bcb: should not j1 & J2 offer both types of lossless.			case '1': // lossless			case '2': // losless sv 6				  uid.Set("1.2.840.10008.1.2.4.57"); TrnSyntax.Set(uid);				  PresContext.AddTransferSyntax(TrnSyntax);				  uid.Set("1.2.840.10008.1.2.4.70"); TrnSyntax.Set(uid);				  PresContext.AddTransferSyntax(TrnSyntax);				  break;

be better:

case '1': // lossless
				  uid.Set("1.2.840.10008.1.2.4.70"); TrnSyntax.Set(uid);
				  PresContext.AddTransferSyntax(TrnSyntax);
				  break;
			case '2': // losless sv 6
				  uid.Set("1.2.840.10008.1.2.4.57"); TrnSyntax.Set(uid);
				  PresContext.AddTransferSyntax(TrnSyntax);
				  break;

It's a long time ago that I coded in c/c++, so it's no more than a guess. Could you please post me, when you compile a new version?

Thank you very much for all!
Heinz

Hi Marcel,

thanks for your fast reply. In the meantime I'll switch back to 1.4.14, as this version can handle decompression with fast builtin-jpg-support, so the very slow binaries of the dcmtk are only needed for compression. 1.4.16 just has one switch in dicom.ini for both compression and decompression internal or external.

One hypothesis is, that the compression is correct, but the dicom tag (0002,0010) TransferSyntaxUID is updated to [1.2.840.10008.1.2.4.70] instead of [...57] by mistake. I don't know how to test this, and so far I have not read a line of the source code, sorry for that, I ought to be ashamed of myself !

Heinz

Hi Conquest users!

I switched
from 1.4.13 built in dbf incoming compression j2 over external compression
to 1.4.16 built in sqlite incoming compression j2 over internal compression (the external compression-executables do not exist any more)

When sending to 1.4.16 the logging says to recompress to j2 before writing to mag0:
[CONQUESTSRV1] [recompress]: recompressed with mode = j2 (strip=0)
[CONQUESTSRV1] Rewritten file: ...,
but it actually compresses to j1. In the dicom-header of the written files I find:
(0002,0010) UI [1.2.840.10008.1.2.4.70] # 22 TransferSyntaxUID, which is j1.
Retrieving these files whith a client configured to prefer j1, the data is sent directly without recompressing (which proofs, that they are j1).
A j2-configured client lets conquest recompress to j2 before sending (which proofs, that they are not j2).

But when I send already j2-compressed files to conquest, they are not recompressed and so they are stored as j2 (1.2.840.10008.1.2.4.57).
These files are not recompressed for a j2-configured client (proof, that they are really stored as j2).

My workaround so far: putting the executables of external compression in the binary directory and modifying dicom.ini: UseBuiltInJPEG = 0.

Does anybody know a solution for that problem?

Thanx in advance,
Heinz Liesenfeld

bart

The database is less than 1 TByte, already j2 = jpeg lossless.

I just figured out that a newly set up conquest-server with builtin-sqlite already accepts incoming dicom-pictures during regenerating an existing data-source.

So my workflow will be:
- switch off the existing conquest-server
- start the newly set-up server (builtin sqlite) with ae/port of the old one, so any new studies appear in the new server
- start the old conquest-server with different ae/port
- have the new server configured as virtual server for the old one, so queries for old studies are virtually mapped to the old server
- start regenerate the new one on the existing data-source
- stop old server when regenerate is finished

hope this works!

Liesenfeld

Hi,

I want to upgrade to a new conquest-server whithout a longer down-time of the existing production system.
Is it a good idea to

- leave the existing running (dbaseIII-based 1.4.13), i.e. production system
- set up the new one with different AE/port (builtin sqlite 1.4.16)
- timestamp, regenerate the new one on the existing data/magdevice
- switch off the old server
- configure the new with AE/port from old system and startup
- send missing studies from timestamp to now to new server ?

I want to switch to sqlite, cause starting up conquest with dbaseIII takes about 15 minutes for building up the index. I have to migrate to new version for better forwarding capabilities.

Thanx in advance for better suggestions!
Liesenfeld

When I import Bitmaps or other pictures they appear regularly in the local imagebox. But when sending them to a Conquestserver, deleting them locally and retreiving from Conquest I get a correct Query-Result but Retrieving does abort with a KPServer-Crash.

I can import the dicom-files from the Conquest-Data-Filesystem only with unchecking testing for dicom-conformance.