However, on my dev server at home I don’t mirror the OrthancStorage that I have in production, but I might be interested in importing the OrthancIndex DB (postgres in my case), and then doing some benchmarking when I have Orthanc configured to look for the DicomTags only with the OrthancIndex only and not in the Storage.
I realize I wont’ have access to the DICOM files themselves in that case, but just wondering if my queries will still return results and if I can do some benchmarking with just the OrthancIndex ?
Are you aware of the following configuration setting?
// Performance setting to specify how Orthanc accesses the storage
// area during find operations (C-FIND, /tools/find API route and
// QIDO-RS in dicom-web). Three modes are available: (1) "Always"
// allows Orthanc to read the storage area as soon as it needs an
// information that is not present in its database (slowest mode),
// (2) "Never" prevents Orthanc from accessing the storage area, and
// makes it uses exclusively its database (fastest mode), and (3)
// "Answers" allows Orthanc to read the storage area to generate its
// answers, but not to filter the DICOM resources (balance between
// the two modes). By default, the mode is "Always", which
// corresponds to the behavior of Orthanc <= 1.5.0.
"StorageAccessOnFind" : "Always",
I would guess that using the "Never" mode should allow you to perform queries without hitting the storage. The viability of this approach probably depends on your use case and on the contents of the "ExtraMainDicomTags" setting.
Well aware of that, but I didn’t really consider that as an option because that probably isn’t what is was intended for (i.e no OrthancStorage), but functionally that is probably what I am interested in.
I would say that I am still a little disappointed by how long a tools/find takes when I search the whole DB. I implemented that pagination and sorting for the studies and it works pretty well when I search a narrow range or a specific AssessionNumber, etc. I think I already have it set to Never, but what you are say is that I could do searching but not get instances/PixelData ?
I bench-marked it a little and it is definitely the tools/find that takes most of the time. The post-processing in Python doesn’t take that long at all, and I have to do a little post-processing on the RIS also, but that is fast.
Just checked: It is: “StorageAccessOnFind” : “Answers”, on one of them.
I did do that upgrade with the MainDicomTags and I am using the Housekeeper, so maybe I should turn it off (Never) and check again and see if anything breaks (i.e. I need to add some additional tags to the Tag list ?).
Kind of off-topic, but AWS has that HealthLake Imaging platform. The deliver:
(MetaData + HTJ2K Lossless Image Frames)
That is a non-standard format, but I was told browsers can actually decode that. I think it is much faster than other formats and they might even stream it. Just wondering if you guys are looking into that. If it isn’t standard, probably not a good idea, but it become a standard at some point.
When you say “That is a non-standard format”, could you please clarify whether you mean the combination of HTJ2K with metadata, or HTJ2K itself? If the latter, then I would take the liberty of reminding that HTJ2K is standard (Rec. ITU-T T.814 | ISO/IEC 15444-15). Sorry if I misunderstood what you meant.
I’m not an expert really. You would need to ask Amazon AWS/HealthLake Imaging.
There are libraries to decode that client side in a browser and I presume there are server side solutions. Is it supported natively in DCM ? There might be something peculiar about the way HealthLake imaging delivers the PixelData.
There is a supplement in the DICOM standard about that:
Well, at least you are an expert in medical imaging, unlike my poor self — just a guy with some knowledge and understanding of some IT solutions and standards and a patient with some experience of installing and using Orthanc for my own personal needs :). Seriously, I should probably apologize for saying amateurish things in discussions like this one.