DICOMweb client: stops at 250 instances per series; ignores SpecificCharacterSet in QIDO list

clicker71 · Mon Sep 07, 2026 4:51 pm

Product: MicroDicom DICOM Viewer, build v2026.3.0.5126.
Role: DICOMweb client (QIDO-RS search + WADO-RS series retrieval) against a Clarus PACS DICOMweb server (PS3.18 origin).
Transport: reproduced both over local loopback and over LAN - transport-independent.

This topic reports two independent DICOMweb client defects found while integrating MicroDicom with a third-party DICOMweb server.

Defect 1: WADO-RS series retrieval silently stops after exactly 250 instances and reports "finished"

When MicroDicom retrieves a series with more than 250 instances via WADO-RS (one series-level multipart GET), it consumes EXACTLY 250 parts of the response, then stops reading the stream and marks the operation as finished in its "Network activity" pane ("finished 250/432", "finished 250/626"). The remaining instances are never downloaded.

Server-side evidence (Clarus PACS sender log; failed=0 means the server encountered no errors for any instance it delivered):

Code: Select all

16:56:59 WADO_SERIES started study=2.16.840.114421.12451.9835700745
         series=2.16.840.114421.12451.9835700778.9867236778 ip=192.168.1.116
16:58:26 WADO_SERIES partial study=2.16.840.114421.12451.9835700745
         got=250 of=432 bytes=301608356 us=71914430 failed=0

16:57:25 WADO_SERIES started study=1.3.6.1.4.1.25403.246788402477788.12876.20260812120435.1
         series=1.3.6.1.4.1.25403.246788402477788.12876.20260812120641.3 ip=192.168.1.116
16:58:46 WADO_SERIES partial study=1.3.6.1.4.1.25403.246788402477788.12876.20260812120435.1
         got=250 of=626 bytes=196317294 us=46844656 failed=0

Loopback reproduction on a second machine, same build:

Code: Select all

16:45:20 WADO_SERIES started study=2.16.840.114421.12451.9835700745 ...
16:46:30 WADO_SERIES partial study=2.16.840.114421.12451.9835700745
         got=250 of=432 bytes=301601106 us=3431377 failed=0

Notable details:

The cut-off is EXACTLY 250 instances on every attempt, for every series size (364, 432, 626), on both transports and both machines.
The sender log shows the transfer stalling after part 250: the server streamed 250 parts quickly but the "partial" event was logged ~60 s after the request started. This is the signature of a client that STOPS READING the TCP stream after part 250 while the connection stays open; the sender blocks writing part 251 until its own timeout.
Repeat attempts by MicroDicom to "get the remainder" show decreasing progress (250 -> 131 -> 1 instances) and can cross-corrupt the partially downloaded series (observed with the 626-instance study, where slices from another series ended up inside it).
The IDENTICAL series downloads completely with other clients: curl retrieves the full 432-instance series (521,187,070 bytes, ~15 s), Weasis and OHIF retrieve it fully. The server and the network deliver the complete response.

Expected behavior: PS3.18 10.4.2 (WADO-RS RetrieveSeries): the client shall retrieve the complete set of instances in the series. If a client imposes its own limit, PS3.2 requires it to be declared in the Conformance Statement. The MicroDicom DICOM Conformance Statement (section 2.5.4, DICOMweb Server Parameters) declares no instance-count limit.

Questions:

Is there a hardcoded limit of 250 instances per WADO-RS series retrieval in the DICOMweb client?
Will the limit be removed (or made configurable) so that series with more than 250 slices download completely?

Defect 2: QIDO-RS search list shows Cyrillic PatientName as garbled text even though SpecificCharacterSet (0008,0005) is returned

The QIDO-RS JSON response contains Cyrillic PatientName encoded in UTF-8 with SpecificCharacterSet (0008,0005) = "ISO_IR 192" announced per row. MicroDicom renders these names as garbled text in the search list and in its "Network activity" pane, while the SAME patient names are shown correctly after the study is downloaded (the DICOM data path reads SpecificCharacterSet correctly).

Server response, captured with curl (first row):

Code: Select all

[{"00080005":{"Value":["ISO_IR 192"],"vr":"CS"},"00080020":{"Value":["20110628"],"vr":"DA"},...
"00100010":{"Value":[{"Alphabetic":"..."}],"vr":"PN"},...}]

Packet capture (tcpdump) of the MicroDicom request during a search:

Code: Select all

GET /dicomweb/studies?includefield=... HTTP/1.1
Accept: */*

The server answers Accept: */* with its JSON representation, i.e. MicroDicom receives exactly the JSON shown above. Yet the search list shows garbled Cyrillic.

Note: over DIMSE (C-FIND, where the same tag is present in the response dataset) MicroDicom decodes Cyrillic names correctly. Only the DICOMweb QIDO path fails.

Expected behavior: PS3.18 10.6: QIDO-RS JSON values are UTF-8; SpecificCharacterSet (0008,0005) = "ISO_IR 192" declares UTF-8. A conforming client decodes the JSON as UTF-8 and, when the tag is present, uses it for character conversion. The search list should show the same PatientName values as the downloaded study shows.

Questions:

Does the DICOMweb QIDO-RS client use SpecificCharacterSet (0008,0005) from the response when converting PatientName for display?
If not, can support for it be added so Cyrillic (and other non-ASCII) names display correctly in the DICOMweb search list?

Evidence available on request:

Full sender-side log excerpts (both machines) for Defect 1 and 2.
curl traces retrieving the same series completely (Defect 1) and the QIDO JSON with the tag (Defect 2).
tcpdump capture showing the exact request headers MicroDicom sends (Defect 2).
Reproduction recipes:
- Defect 1: point a MicroDicom DICOMweb node at any PS3.18 server holding a >250-instance series; download the series; observe "finished N/250" in the Network activity pane regardless of N.
- Defect 2: search for a patient with a Cyrillic name over the DICOMweb node; compare the garbled list entry with the correct name shown after the study is downloaded.

Reported by the Clarus PACS project: https://github.com/clarus-pacs/clarus

clicker71 · Sun Sep 13, 2026 10:48 am

Correction and final root cause (Clarus PACS side)

We would like to correct our own report above. After digging into the server access logs with a fresh reproduction, the "exactly 250" cut-off was OUR server behavior, not a hardcoded MicroDicom limit:

The Clarus QIDO-RS default result limit (250) was applied to the per-series instance list. The truncated response carried the standard Warning: 299 - Results truncated by limit header.
MicroDicom requests that list without limit/offset and treats the first page (250 rows) as the complete series, then downloads exactly those 250 instances over WADO-RS. With the server limit disabled, MicroDicom downloads the same study completely (432/432).
The WADO-RS sender stall after part 250 was the server blocking while the client stopped reading - a secondary effect, not a cause.

We have fixed our side (the default limit no longer applies to scoped per-study/per-series enumeration; it governs open-ended searches only, as DICOMweb pagination intends). Project: https://github.com/clicker71/clarus-pacs

What we believe still remains on the MicroDicom DICOMweb client side, now narrowed to two points:

No QIDO-RS pagination. A client that sends no limit/offset should follow the Warning: 299 header and re-query with offset to collect the remaining rows. MicroDicom takes the first page as the complete result set. PS3.18 section 8.3.4.1 describes this contract.
Partial import reported as "finished N/M". The UI shows the expected total (e.g. "finished 250/432") - so the expected count is known - yet a partial download is marked as finished with no error and no attempt to fetch the remaining M-N instances.

Happy to provide the server-side logs and a reproduction recipe for both points. Apologies for the initial misattribution.

Best regards,
Clarus PACS team

Mon Sep 21, 2026 9:04 am

Thank you for reporting these issues to us. We have already fixed them in the current beta version: https://www.microdicom.com/beta.html