Cornerstone loading performance for large(r) CT studies

319 views
Skip to first unread message

Marcel Swennenhuis

unread,
Jul 7, 2016, 10:45:05 AM7/7/16
to cornerstone platform
I looked at the Cornerstone demo. Working pretty well, though (at my PC with 150Mbit network) the loading of 109 images (demo-CT) took almost 10 seconds.
Does anyone have an idea and/or experience how this would work for larger CT-studies (let’s say 1000 images in a series for now). I think that 100 seconds would not be acceptable in practice.

JF Pambrun

unread,
Jul 7, 2016, 11:33:21 AM7/7/16
to Marcel Swennenhuis, cornerstone platform
Maybe the server has bandwidth or latency issues. 

I've done multiple tests and I can consistently download from the web, decode and display 300 JPEG 2000 compressed slices in less than 10 seconds. 
Without JPEG 2000 decoding and with the data available locally (or infinite bandwidth/low latency), I think the framework should be able to display a 1000 slices CT series in the 10 seconds ballpark.

On my pc, this test https://jpx.jfpb.net/ does 500 CT slices in 9 sec.

JF  

On Thu, Jul 7, 2016 at 10:45 AM Marcel Swennenhuis <marcel.sw...@j4care.com> wrote:
I looked at the Cornerstone demo. Working pretty well, though (at my PC with 150Mbit network) the loading of 109 images (demo-CT) took almost 10 seconds.
Does anyone have an idea and/or experience how this would work for larger CT-studies (let’s say 1000 images in a series for now). I think that 100 seconds would not be acceptable in practice.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cornerstone-platform/8b9651c8-8cbb-41be-826d-26be53b89ed8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Marcel Swennenhuis

unread,
Jul 7, 2016, 1:00:38 PM7/7/16
to cornerstone platform, marcel.sw...@j4care.com
Hi Jean-Francois,

thanks for the feedback. I tried your link on my Macbook (8GB memory, intel I5 2,5GHZ WITH 150Mbit network): 25 seconds for your test. When I "refresh" it is a little less, 20 seconds. But...I get the impression that your example has 1000 slices?
I also don't see the network being really loaded, so how many MB's is it really loading if we talk lossless JPEG?

Marcel

Op donderdag 7 juli 2016 17:33:21 UTC+2 schreef Jean-Francois Pambrun:
Maybe the server has bandwidth or latency issues. 

I've done multiple tests and I can consistently download from the web, decode and display 300 JPEG 2000 compressed slices in less than 10 seconds. 
Without JPEG 2000 decoding and with the data available locally (or infinite bandwidth/low latency), I think the framework should be able to display a 1000 slices CT series in the 10 seconds ballpark.

On my pc, this test https://jpx.jfpb.net/ does 500 CT slices in 9 sec.

JF  

On Thu, Jul 7, 2016 at 10:45 AM Marcel Swennenhuis <marcel.sw...@j4care.com> wrote:
I looked at the Cornerstone demo. Working pretty well, though (at my PC with 150Mbit network) the loading of 109 images (demo-CT) took almost 10 seconds.
Does anyone have an idea and/or experience how this would work for larger CT-studies (let’s say 1000 images in a series for now). I think that 100 seconds would not be acceptable in practice.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-platform+unsub...@googlegroups.com.

JF Pambrun

unread,
Jul 7, 2016, 1:28:19 PM7/7/16
to Marcel Swennenhuis, cornerstone platform
It has 500 slices.
The network is not really loaded because the images are streamed using JPEG 2000.
Only about 20-30kb are needed to display the first lossy layer (indicated by a red eye in the right corner).
Images are progressively downloaded up to losslessness (indicated by a with eye) in two more layers (about 50 and 90kb) when the user stops browsing for about 200ms.
Initial download size for the 500 slices is 19.07 mb, but it would increase to about 100 mb it you inspect every slice losslessly.
It is still much less then the 270mb required to download RAW dicom files.

The decoding process is very CPU intensive and it done on multiple threads. My workstation has twice the number of cores, hence twice the speed.
When you "refresh" the browser uses cached version of the images, this may explain both the 5 second gain and the low network requirements you have mentioned.
In chrome, you can open the DevTools with Ctrl+Shift+J and, in the options, enable "Disable cache (while DevTools is open)" to test it correctly.

Even, if it takes 10-20 seconds to download and decode the entire series, you can still start your navigation in less than a second an, on many systems, the loading process is faster than you can scroll.

Anyway, the takeaway is : if the pixel data is readily available, cornerstone can display it real fast.

JF

On Thu, Jul 7, 2016 at 1:00 PM Marcel Swennenhuis <marcel.sw...@j4care.com> wrote:
Hi Jean-Francois,

thanks for the feedback. I tried your link on my Macbook (8GB memory, intel I5 2,5GHZ WITH 150Mbit network): 25 seconds for your test. When I "refresh" it is a little less, 20 seconds. But...I get the impression that your example has 1000 slices?
I also don't see the network being really loaded, so how many MB's is it really loading if we talk lossless JPEG?

Marcel

Op donderdag 7 juli 2016 17:33:21 UTC+2 schreef Jean-Francois Pambrun:
Maybe the server has bandwidth or latency issues. 

I've done multiple tests and I can consistently download from the web, decode and display 300 JPEG 2000 compressed slices in less than 10 seconds. 
Without JPEG 2000 decoding and with the data available locally (or infinite bandwidth/low latency), I think the framework should be able to display a 1000 slices CT series in the 10 seconds ballpark.

On my pc, this test https://jpx.jfpb.net/ does 500 CT slices in 9 sec.

JF  

On Thu, Jul 7, 2016 at 10:45 AM Marcel Swennenhuis <marcel.sw...@j4care.com> wrote:
I looked at the Cornerstone demo. Working pretty well, though (at my PC with 150Mbit network) the loading of 109 images (demo-CT) took almost 10 seconds.
Does anyone have an idea and/or experience how this would work for larger CT-studies (let’s say 1000 images in a series for now). I think that 100 seconds would not be acceptable in practice.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cornerstone-platform/655b712b-eb0b-4dc1-87b3-6638a82a051f%40googlegroups.com.

Chris Hafey

unread,
Jul 8, 2016, 8:42:51 AM7/8/16
to cornerstone platform, marcel.sw...@j4care.com
Cornerstone is basically a diagnostic rendering engine written in javascript.  Since all rendering is done client side, it requires access to the full pixel data (16 bit).  The problems and solutions are therefore similar to those found in any other thin client viewer and bandwidth is usually the main limitation.  The browser has a few additional limitations:
1) Limit on the number of concurrent HTTP requests per domain.  This prevents you from saturating your network pipe.  Can be fixed by using multiple hostnames
2) Slow decompression speed for some codecs (specifically JPEG2000).  

Note that Cornerstone is architected to stream images and has a very good prefetcher - you should not have to load the entire study before allowing the user to view the study.

Chris
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-platform+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-platform+unsub...@googlegroups.com.

JF Pambrun

unread,
Jul 8, 2016, 9:10:32 AM7/8/16
to Chris Hafey, cornerstone platform, marcel.sw...@j4care.com

I think HTTP/2 will fix #1 and mostly eliminate the effect of latency. This will be great for large series.

JF


To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cornerstone-platform/b92c205f-654e-42db-b6f1-a480bcdc4db6%40googlegroups.com.

Marcel Swennenhuis

unread,
Jul 8, 2016, 9:36:54 AM7/8/16
to cornerstone platform, marcel.sw...@j4care.com
Using JPEG2000 was nice for the bandwidth (see answer JF), but due to the low decompression speed still takes a lot of time. One needs a real heavy-duty PC apparently.
What would be the alternatiive for faster decompression (probably creating higher bandwidth requirements?)

Op vrijdag 8 juli 2016 14:42:51 UTC+2 schreef Chris Hafey:

JF Pambrun

unread,
Jul 8, 2016, 9:52:59 AM7/8/16
to Marcel Swennenhuis, cornerstone platform
The lack of native image decoder with 16bit support in current browsers is the real issue.
The JavaScript JPEG2000 decoder will improve over time as JS engines, the Emscripten compiler and the codec itself improve. 

Transcoding to an alternative compression scheme on the server will add latency and compression is much more computationally intensive that decoding.
Maybe it is worth trying lossless PNG or WebP with the 8 MSB packed into the one channel (say R) and the 8 LSB into another (say B).

I hope this will help,
JF 

To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "cornerstone platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cornerstone-plat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cornerstone-platform/be177a5a-dc5f-4423-8aba-a2bff0d47575%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages