Ultrasound color images showing up with blue/green overlay

  • We just upgraded to 1.5a and got reports from our techs that old color images are showing up wrong now.

    They all seem to have a blueish overlay on them. This also looks like this in the imageviewer on Conquest itself.


    Strange thing is, this is only happening to old images, new images that are being saved to the server now are showing up correctly when they are retrieved.

    example:


    Doesn't matter if we open these on the server, KPACS, IQview, external reading station, all show up the same

    On the server everything is stored in j2 and when sending I have tried sending to the clients as j2 and un, both with the weird colors as a result.


    Anyone have any ideas on this one?

  • This is running on Windows 2012R2

    Old version was 1.4.19b (all files were upgraded to 1.4.19d, but then the dgate64.exe and related files rolled back to the b version)

    I will send the image to you in DM

    If I copy the dcm file out and open it in an external viewer without going through conquest, it looks fine

  • dgate32: seems not to work in version 1417d - 150a

    dgate64: also seems not to work in 150a (6’652’928 bytes) but 1419d (4’764’672 Bytes) does


    (SOPClassUID "1.2.840.10008.5.1.4.1.1.6.1")

  • Hm,


    the sample images Flyboy sent over where uncompressed, so the damage is done and stored in the pixel values. Are you sure these are the original images as stored?


    Edit: Sorry it uncompresses on load. Let me try again. But the new image seems uncompressed.


    Marcel

  • Indeed,


    the old image is jpeg compressed on shows wrong. The new image is NOT compressed, so does not go through the same code. Can you get me a new imagee that is compressed with j2 by 1.50.a and shows correctly? In 1.5.0 compression was accidently blocked.


    Marcel

  • Hi,


    can you test this executable for me:


    http://ingenium.home.xs4all.nl…gate64_150b_jpegissue.zip


    It should solve the issue for now, but it needs a bit more thought. This is the associated bug report:


    N12) Conquest error free jpeg compressed color data is compressed in wrong color space (YCR), but decompressed in the correct (RGB). Proposed fix in 1.5.0b being tested.

    Marcel

  • I tested the executable and this solves my 2 issues.

    My previous images are no longer blue and my new ones are getting compressed again (where 1.5.0a did not compress them)


    When you say this needs more thought, does that mean we should not be using this executable in production or is it just that you want to rethink something for the future, but we can use this one for now?

    I rather not have to go down to 1.4.19c because we'll lose the performance gains from the newer versions


    thanks again, you are a lifesaver!

  • Hi,


    executable is safe for production, but I think the losless jpeg compression of color images in conquest is not according to the standard because it uses YCR colorspace while it should use RGB. Because there are tons of image compressed like that, conquest must deal with this propetry, which the modified executable does for its own images. Note sure what happens with images from other sources though.


    Colorspace is encoded (optionally) in jpeg and (mandatory) in dicom. For lossless jpeg compressed images in your exectutable this is the behavior now (I think, will recheck):


    jpeg dicom decompress

    YCR RGB RGB (incorrect sample image 12345 decompresses correctly)

    RGB RGB RGB (correct)

    XXX RGB RGB (correct)

    YCR YCR YCR (used RGB just changed to YCR to correctly decompress conquest compressed)

    RGB YCR RGB (incorrect image)

    XXX YCR RGB (incorrect image)


    I am afraid many or all of these variants are out in the wild.


    Marcel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!