Visual DICOM browser issues

[che85]

Slicer version (Windows) 5.11 2026-06-15

• (1) Unclear what the input fields are for unless the user hovers over the field to see tooltip.
  Not sure, why only the top two fields are filled with solid green color.
  
  clear in version 5.10
  

• (2) searching for a specific study description that only matches one study returns all patients (0 studies) from the DICOM server (not filtered).
  W: The number of responses of the query task at patients level surpassed the maximum value of permitted results (i.e. 25).
  Note: Using the non-visual DICOM query retrieve returns the correct result I filtered for from the DICOM server

• (3) selecting and trying to delete individual or multiple patients from the local database has no effect (neither in tab mode nor in list mode)

• (4) delete all patients button is gone

• (5) tab mode button randomly hovering on top of list:
  

• (6) checkbox to control querying servers gone in preview release
  

[lassoan]

@Punzo can you comment on these? I think these are mostly just UI rearrangements, but the study-level query may be a new feature; and the deletions and field highlighting behavior may need to be fixed.

[Punzo]

@che85 thanks for testing and reporting!

1. I can't reproduce in linux version 2026-06-15. I tried also my local builds (Qt5 debug and Qt6 debug) and I could not, i.e.: this is what I get:

I removed the labels to optimize the space, especially in side panel mode:

I could re-insert them in the layout, but maybe it is better to fix the issues in Windows. @lassoan is something that you could check? please let me know, otherwise, I will have to setup a dev env in windows.

the color is set with the palette in https://github.com/commontk/CTK/blob/master/Libs/DICOM/Widgets/ctkDICOMVisualBrowserWidget.cpp#L1043-L1062
looking at the code I don't see anything wrong.

2. I have tried using as study description "CORONARY" as filter and I queried the default server (MedicalConnections). Indeed there were patients with 0 studies (this should not happen, it seems a regression, I will investigate). On the other hand it gave me also the patient with the correct study. I guess what happened in your case is that the query gave a lot of false positive with 0 studies and excluded the good one.

NOTE: there is a thershold of 25 patients on query results. Only the first 25 patients of the query are kept. Do you have any feedback on this? we introduced it to limit the user from querying "too much". This was introduce in the previous version which had perfomances issues on large datasets. I think we can remove it, do you agree? or maybe we should make it configurable?

3. can you please specify more steps to reproduce? I did the following and it worked for me:
   -) I have strated with a clean/empty database
   A) I have retrieved from default server (MedicalConnections) some data using as filter MRN = "1". Data are stil ldownlaoding, but I did not waited, right click either in tab or list mode on the patient widgets -> delete .. patient from local database -> worked
   B) I have imported some dicom (import DICOM files button), right click on patient widget -> worked.

Probably there are some edge cases that it is more difficult to reproduce, please let me know if you did something more specific. Thanks in advance!

Update: if a patient had zero studies, I could not remove it, I am investigating it (in general the query should not create patients with zero studies).

4. you are right, I simply did not know were to place it. Have you any suggetion? maybe we can place it in the collapsible group "Actions"? @lassoan what do you think?

5. I did not know where to place this as well, any suggestion would be very welcome!

6. this is done in purpose. I managed to make the filtering on the local database interactive in the new version, so the filtering on the local database it is done automatically as soon as you edit any filtering variable. Therefore, it is not needed anymore to have a local filtering button (it was a workaround in the previous version because of the poor performances). In the previous version, it was also very unclear to users the duality of the button (local filtering vs server query/retrieve) and how to switch between the two (some users were missing the menu arrow). So we decided that the query/retrieve button simply perform only the query and retrieve to the servers defined in the advanced settings, while local filtering is applied as as soon as you modify any filtering field (and filters apply also to the query/retrieve when pushing the button). Please let me know if it still unclear and/or if you have any suggestion.

[Punzo]

PR at #1435

1. in 46e6af1 I set manually the color of the PlaceholderText when there is warning. Probably this shoudl fix the issue on windows. But it would be nice if anyone can compile and double check. Thanks in advance.

2. fixed in ed0712c

NOTE: in default the number of patients results for query is now unlimited (see abd3edc)

3. fixed in 3836202

4-5-6) I will wait for feedback @lassoan @che85 . Thanks!

[che85]

@Punzo Thank you for working on these issues.

4. Are these DICOM database settings going to stay? If so, then we probably don't need a separate button for deleting all patients.

5. I would probably just expose both layout options (list view, tab view) as an exclusive button group with icons. The button group could be placed somewhere between the search form and the results.

6. makes sense as long as it works as expected

[Punzo]

@Punzo Thank you for working on these issues.

4. Are these DICOM database settings going to stay? If so, then we probably don't need a separate button for deleting all patients.

I would say yes.

5. I would probably just expose both layout options (list view, tab view) as an exclusive button group with icons. The button group could be placed somewhere between the search form and the results.

ok thanks for the feedback. The issue is that I was aiming for something more embbeded in the patient view object. So that's why I have the 3 dots in tab mode to go in list mode:

and the floating icon in list mode to go in tab mode:

the idea was to have the controls to switch exactly on the patient view. But I guess it was not good enough. I wil lthink a little bit more about it, to see if I can find another solution.

6. makes sense as long as it works as expected

sure, if you find any other bug after PR #1435 will be merged, please let me know!

[che85]

@Punzo from my perspective, the "..." would never turn the widget into a list.

And having the button float around might not be ideal either.

Probably better to be explicit than expecting the user to know what these buttons mean

For the tab view, I have also seen buttons to scroll or enable horizontal scrolling.

Example: https://stackoverflow.com/questions/49705201/ios-horizontal-scrollable-tab-bar-in-swift

[Punzo]

@Punzo from my perspective, the "..." would never turn the widget into a list.

ok I have changed the icon in ca3eacb into

---

And having the button float around might not be ideal either.

yeah I agree the floating button is not ideal. Let's wait also @lassoan feedback, he may have some other ideas as well.

Probably better to be explicit than expecting the user to know what these buttons mean

I agree!

For the tab view, I have also seen buttons to scroll or enable horizontal scrolling.

we had this in an early version (there was no list mode). But already for more than 10 patients, it was not very useful. So we decided to keep the tab mode only for maximum 5 patients (i.e. currently tab mode shows only the first 5 patients), and for more patients we switch automatically into list mode. Of course if other users find horizontal scrolling in tab mode useful, we can restore/enable.

[lassoan]

Text visibility

I can reproduce - type ttt in MRN... box. The gray text is practicially invisible over the dark yellow background.

When the background color is changed then the text color should be changed, too.

4. delete all patients button is gone

It has been there (and will be there) in the left panel.

list view, tab view

The floating tab could be moved into the layout (next to the ... button).

Automatic switch between single and multi-line patient selector is useful, but it should be easier for the user to change the preference. For example, there could be a layout selector button that displays a menu when clicked (auto, tab, list); or layout selection (auto, tab, list) could be added as a menu section of the right-click menu and/or ... menu.

7. A small additional comment: Modality and Date labels should be on the left side of the corresponding widget.

[Punzo]

Text visibility

I can reproduce - type ttt in MRN... box. The gray text is practicially invisible over the dark yellow background.

When the background color is changed then the text color should be changed, too.

already done in 46e6af1

list view, tab view

The floating tab could be moved into the layout (next to the ... button).

Automatic switch between single and multi-line patient selector is useful, but it should be easier for the user to change the preference. For example, there could be a layout selector button that displays a menu when clicked (auto, tab, list); or layout selection (auto, tab, list) could be added as a menu section of the right-click menu and/or `...` menu.

These are both not straightforward to implement properly (the patient view is a full custom widget). I would address them later in a future PR, I have added points 32 and 33 in #1230

7. A small additional comment: Modality and Date labels should be on the left side of the corresponding widget.

Done in 6ebc683

[lassoan]

Thank you for the update. Please add colon (:) after Modality and Date. In Slicer style, labels are left-aligned by default, so I would use that here, too (unless it looks strange here; which is possible, since the editboxes are somewhat unusual here, too, in that they don't have labels).

[Punzo]

Thank you for the update. Please add colon (:) after Modality and Date. In Slicer style, labels are left-aligned by default, so I would use that here, too (unless it looks strange here; which is possible, since the editboxes are somewhat unusual here, too, in that they don't have labels).

thanks for the feedback. I have added the colon:

in 47101ca

I have tried to place the labels left-aligned, but it was not looking good. We can always iterate in future PR and change the general layout if we don't like it.

#1435 is ready for review. Thanks in advance!