WADO images look grayscale-distorted (Conquest 1.5.0f, MariaDB, Ubuntu 24.x)

    Hello Marcel,

    I’m seeing a rendering issue with Conquest PACS 1.5.0f.
    Images retrieved via WADO look grayscale-distorted (tonal scale compressed / wrong window), similar to the attached example. They are not simply darker; the gray ramp looks incorrect.

    This occurs regardless of transfer syntax:

    • Implicit VR Little Endian
    • Explicit VR Little Endian
    • JPEG 2000 Lossless

    Opening the same study in the OHIF web viewer looks correct (proper window/level), so the stored pixel data seems fine and the problem appears limited to WADO conversion.

    Environment

    • Conquest: 1.5.0f
    • Database: MariaDB (local)
    • Viewers tested: OHIF (OK), OsiriX / direct browser download / curl (distorted)

    Question
    Could this be related to VOI LUT / Window translation during WADO export, or a dicom.ini or config files option that affects WADO JPEG generation?
    Which parameters/converters should I check or adjust to ensure correct grayscale mapping in WADO output?

    Thanks in advance for your help!

    Thank you for your reply. I apologize for the delay, but I was "trapped" in Asia due to operations in the Middle East and have only just returned to my duties.

    Regarding the previous issue...
    As you can see in the photos, when I use WADO and download the research (to Osirix), only the first frame (photo) in the entire series appears to be correct, while the rest of the photos are completely gray or a gray gradient. I don't know if this is related to the configuration of Conquest itself, permissions issues for the TMP files where the files are processed, or perhaps something else.

    Hello,

    To better understand what might be causing the issue, I recreated the environment using Docker.

    I have attached a fully working Docker Compose configuration that reproduces the same graphics problem when downloading WADO images.

    Could you please take a look and let me know if you notice anything unusual?

    Feel free to use the Docker configuration for your own testing if it is helpful.

    Best regards,

    Marcin

    Hi Marcin,

    I think your docker container builds the standard dicom server. Can you please explain what you expect to see in the pictures? I see gradients in all pictures. You say that the tonal scale is compressed and wrong window is applied. This can be true, but my question to you is if the client asks for a specific level/window, or is it the default level/window that is wrong.

    Edit: level and window read from the dicom object are rounded to integers, is that the issue?

    Marcel

    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

    Hello Marcel,

    Thank you for looking into this.

    The issue is not related to a specific Window Level / Window Width requested by the client. The problem occurs when OsiriX downloads the image through WADO and displays the default presentation.

    I have attached an example screenshot. Instead of displaying the actual MR image, the downloaded image appears as a smooth grayscale gradient from black to white. The anatomical information is completely missing.

    When the same DICOM file is opened directly from the PACS storage or viewed in OHIF, the image is displayed correctly. The problem only occurs when the image is retrieved through the WADO interface.

    Regarding your question about rounding Window Center and Window Width to integers: I do not think this is the root cause. Even if the window values were slightly different, I would still expect to see the anatomy, perhaps with different contrast. Instead, the returned image contains only a grayscale gradient and no diagnostic image content.

    Could there be an issue in the pixel data conversion or in the generation of the JPEG/PNG image returned by WADO?

    Best regards,

    Marcin

    Ok, thanks for the explanation, I did not understand and I have never seen it. Does this also happen in the conquest web interface so that I can easility reproduce it? Ana a high level debug log enabled when a WADO image is generated would be useful as well.

    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

    Hello Marcel,

    Yes, the images are displayed correctly through the OHIF viewer. I tested the same study and series, and the images are rendered properly in OHIF with the correct grayscale and anatomical details visible.

    The issue only occurs when OsiriX retrieves the image through WADO. Instead of the actual MR image, OsiriX receives and displays only a smooth grayscale gradient from black to white.

    I will enable debug logging and reproduce the issue again.

    Could you please advise which debug settings would be the most useful for investigating WADO image generation? If there are specific options in dicom.ini or a preferred log level that would help identify the problem, I will enable them and provide the resulting logs.

    Best regards,

    Marcin

    This is from the app/newweb:

    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

    Hello Marcel,

    I performed some additional tests and would like to share the results.

    When accessing the study through the standard Conquest web interface (/app/newweb), the images are displayed correctly and the anatomy is visible as expected.

    However, when accessing the same study through the DICOMweb endpoint (/api/dicom/rs), the images are not displayed correctly in OsiriX and appear as a grayscale gradient.

    I have attached the corresponding logs for both tests.

    Additional observations:

    • OHIF displays the images correctly.
    • Classic DICOM Query/Retrieve (C-FIND, C-GET and C-MOVE) works correctly.
    • The issue is only reproducible when using the DICOMweb / WADO-RS path.
    • Apache returns HTTP 200 responses for the DICOMweb requests.
    • The WADO-RS response is returned as multipart/related, and all parts have Content-Type: application/dicom.
    • The same behavior is reproducible on a clean Docker installation with the default Conquest configuration.

    At the moment, the issue appears to be isolated to the DICOMweb/WADO-RS retrieval path.

    I have attached the logs collected during these tests for your review.

    Best regards,

    Marcin

    Thank you, and with your help we at last found it:

    the dicomweb api does not implement the 'rendered' endpoint, only the 'thumbnail' endpoint. Therefore it returns dicom not jpeg.

    As a test can you plaase try to duplicate this block of code in index.php:

    And replace 'thumbnail' in the ->get function with 'rendered' and 128 with 512?

    Marcel

    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

    Hello Marcel,

    I added the /rendered routes in index.php as suggested and mapped them to thumbnail(..., 512).

    However, after checking the Apache access log, it looks like OsiriX does not call the /rendered endpoint at all.

    During retrieval, OsiriX only calls:

    GET /api/dicom/rs/studies

    and then:

    GET /api/dicom/rs/studies/

    There are no requests to /rendered, /thumbnail, /frames or /instances in the access log.

    So it seems that OsiriX is retrieving the whole study through WADO-RS Study Retrieve as application/dicom, not using the rendered image endpoint.

    Best regards,

    Marcin


    Ok, the last call generates a multipart message with all dicom objects of a study in it. I thought this call works fine. The formatting happens in rquery.lua line 54.

    A response looks something like this:

    Code
    --i1ohwvqqvw43wzung0t6igvzvmrc0wwy
Content-Type: application/dicom
Content-Transfer-Encoding: binary

DICOM HERE
--i1ohwvqqvw43wzung0t6igvzvmrc0wwy--

    Where after the -- is a random break string and the stuff up to DICOM here is repeated for each object. The header shows

    Content-Type: multipart/related; boundary=i1ohwvqqvw43wzung0t6igvzvmrc0ww

    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

    Hello Marcel,

    I tested the URL:

    /api/dicom/rs/studies/1.2.840.113619.6.388.16254670578653476717748544641543505467

    The response is returned as a file. The downloaded file is approximately 68.5 MB in size and is saved by the browser as an MHTML/MHT file.

    When retrieved with curl, the response has:

    Content-Type: multipart/related
    Content-Type: application/dicom (for each part)

    and contains the DICOM objects from the study.

    I have attached a screenshot of the downloaded file.

    I captured the response with curl.

    The request was:

    GET /api/dicom/rs/studies/1.2.840.113619.6.388.16254670578653476717748544641543505467

    with header:

    Accept: multipart/related; type=application/dicom

    The server responds with HTTP 200 OK and:

    Content-Type: multipart/related; boundary=Zjg1ke2qS8Mh9b4AOvmBVPpU3xRDQ6Cu
    Transfer-Encoding: chunked

    The downloaded file size is about 65.2 MB.

    So the endpoint returns a multipart response containing the DICOM objects from the study.

    Best regards,

    Marcin

Participate now!

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

Register Yourself Login