… also, in case you’re wondering how to pronounce “spycolyf,” it’s “spice o’ life,” and it’s the business name of my music production company." I don’t remember how the use of that name happened, but that’s the way it turned out somehow. Thanks.
What are your current 3 color hex values? I want to try 990000, 009900 and 000099. Just brighter colors than current. Image background colors are fine. I’ll update the tasks on GitHub. Here is how the current Red and Green lines appear zoomed up in Photo Shop. I wonder how it’s being interpolated. Maybe a little exclusive or’ing going on? When I samle the pixel colors, it’s mostly dark gray.
For reference, here are the comment I directly shared by email few days ago:
- To set the colors of the reference markers on my four image panes.
To follow up on this thread SlicerQR Development - #54 by spycolyf
These are currently set here:
Note that the string “Red”, “Yellow” and “Green” are used to identify each viewer and do not define the
colors. The colors are defined using the hexadecimal code.Which color should we use ?
OK, then it seems the reference line colors are the same as the background colors. I’ll try this in practice, Is there an easy way to set the slice loc text colors to white?
Reference lines and background color can be set independently.
Yes, every aspect can be customized. It should be possible to set this updating the Qt stylesheet.
@jcfr - OK, Style sheet I can do. I tried changing the 3 lines you referenced in QREADS.py, but that’s for slice view background. I liked the original for those because dark is less distracting from the images. So, how do I change the line colors independently?
SLICEVIEW_BACKGROUND_COLORS = {
"Red": "#990000",
"Yellow": "#009900",
"Green": "#000099"
}
… also, at the moment, we don’t want the “save scene” prompt on close. Physicians here seem to hate prompts and prefer as little as possible.
Thanks @jcfr
@jcfr - Hello JC, Liqin did the new build and it seems SlicerQREADS is still looking for the splash screen. And crashes. How do we fix this?
Hello, I’ve been testing launching SlicerQREADS from QREADS and I think it has an acceptable launch speed which will improve a lot after we get rid of the splash screens.
However, it does not seem to be able to handle our image folder paths. For example, “C:\Abcdef\Ghijkl\Mnopqrstu\Vwxyz_12345\1.3.12.2.1107.5.8.15.101834.30000020080812425097400002372\27”. Why is this a problem? It was not a problem with FourPanesViewer.
When I move the data to a folder such as c:\TextImages, it works fine.
Found a case where the orientation is incorrect. Here are the test images: Dropbox - BadOrientation.zip - Simplify your life
The coronals are upside down and the superior orientation is still pointing up. Any Ideas?
I had a quick look and that is DICOM Secondary Capture format (screen dump) so geometry is often not well preserved.
In this case it loads correctly via the DICOM module but incorrectly with the regular Add Data. We always recommend the DICOM module for data that is known to be in DICOM format.
OK, I found the problem here. Folders cannot begin with a number
Not to worry, no PHI here, it’s a test patient from our QREADS test server.
Oh that’s great Steve. So the data orientation is not properly reflected in the direction cosines and other orientation header values?
But, I loaded the data in another DICOM viewer called Weasis and the orientation is correct.
There is position and orientation info available per-slice, and Slicer’s DICOMScalarVolumePlugin is parsing it correctly to form the same view as you see in Weasis. If you go through the Add Data module then the data is sent down to ITK for loading. It could be that because this particular data is a Secondary Capture, where orientation and spacing are optional, that ITK ignores the fields and use some other ordering logic. It might make sense to debug this with native ITK to see if this interpretation is correct.
In any case this particular dataset is probably not representative of real clinical datasets. But it does illustrate that testing with real data is important. By default Slicer defaults to ‘best efforts’ at loading data that is not well defined (e.g. is not fully conformant with the standard), but you may or may not want to that tighten up, depending on your data and the user expectations.
1 Like
Thanks Steve,
I will relay this to my team.
As you can see in the picture the reference lines are much more visible as compared to pictures I sent earlier in this thread. But, I need the background to stay dark. How can I set the reference lines colors separate from the image background colors?
Hello @pieper,
Could you share with me why you determined this to be secondary capture data? I’m afraid that most of our volumes except for the Head/Neck process where to sagittals and coronals get vertically flipped as if the axial slices are read (or stored) in reverse order. That makes this wonderful product unusable. I really hate to see this happen. Is this a known issue and could fixing it help others?
So, are you referring to any of these DICOM elements being wrong?
(0018,5100) - Patient Position : FFS
(0020,0032) - Image Position (Patient) : -249.5-369.5-80.7
(0020,0037) - Image Orientation (Patient) : 1\0\0\0\1\0
I’m just curious, how are you calculating the Z direction. I vaguely remember when I developed Mayo Image Studio, I think I calculated single frame spacing between slices by the difference between consecutive slices’ Image Position (patient) vectors, or the difference between consecutive slices’ slice locations and the sign of the differences gave me a positive of negative z direction. I don’t remember exactly. I never trusted the Patient Position element. Seemed to work fine I think.
But clearly the slices are ordered head-first in SlicerQREADS. I’m probably wrong though.
Please lets nail this down. Luckily I demoed only Head-Neck and the orientation was correct.
Thanks.