Replies: 5 comments 2 replies
-
Have you managed to work this one out? I too would like to know the answer to this as it takes about 3-4 seconds to render 90 DICOM images. This wont help the load time, but storing the images in memory after you have processed them is a great way to make subsequent reads lightning fast. To speed up RenderImage(), the key is to break down the components of RenderImage() and to do them in parallel with something like C# tasks. I'm not sure what platform you're using, but you cannot create Textures in Unity in parallel (which is what I am using) so running the entire RenderImage() function on a thread is not an option. I've gotten pretty close by taking the raw pixel data from file.Dataset and creating textures that way but I can't seem to get the format of the image right as my images come out in red scale only. Any thoughts on this topic would be greatly appreciated! |
Beta Was this translation helpful? Give feedback.
-
I am having the same issue when the images are JPEG2000Lossless then it is very slow |
Beta Was this translation helpful? Give feedback.
-
I didn’t really have a ton of success with this. I used C# tasks to open the files in parallel which helped speed that up. In Unity, you can only render on the main thread so threads will not work to render. I am not sure if WPF has this limitation as I’ve never used it. If it does not have this limitation, you would be able to use Tasks to render your images in parallel, save them to a list of something and then display them from memory. That would be much faster if that can be done.As far as breaking the render function down to see what could be threaded, it was a ton of work that led to not much benefit because the render function does a ton of important stuff for you to make the image render correctly which was not easily reverse engineered.Sent from my iPhoneOn Mar 22, 2023, at 4:37 AM, Kevin Stephen Biswas ***@***.***> wrote:
Sorry I didn't find any solution to this problem yet. One thing I found is that the uncompressed formats are faster to render than the compressed formats. So, I decided to convert and store the uncompressed format. Which did speed it up. Unfortunately, the X-ray files which generally are larger take 00:00:00.10-00:00:00.20 to render. Which other takes 00:00:00.01. This delay is quite visible during the Window change.
I am using regular C# with WPF. I don't know much about Unity. But could you give me a bit of explanation or possibly some demo on how you break off the rendering code and execute it in parallel?
-Thanks
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
You might want to keep an eye on #1591 |
Beta Was this translation helpful? Give feedback.
-
The compressed images have to be uncompressed anyway to render them. That's probably what's taking up most of the time. |
Beta Was this translation helpful? Give feedback.
-
I am using the following render code. This is a slightly modified code because, in the actual code, I am getting all the files from the FTP server. CurrentWindowCenter and CurrentWindowWidth hold the current value of WL and WW. This value can be changed from the UI. I am showing the rendered WritableBitmap directly to the user using an image component inside a canvas.
But the rendering of the image is very slow. Especially for images with large file sizes such as X-Ray. So, the WW and WL change is also very slow since it also uses the render function.
I am not very knowledgeable about this. But is there a way to make the rendering or WW/WL change faster? Is there a way to skip the rendering of the image every time a WW/WL change happens?
Any advice in the right direction is appreciated.
Thanks in advance.
Environment
Fo-Dicom (4.0.8)
.NET Framework 4.8
WPF
Beta Was this translation helpful? Give feedback.
All reactions