NVIDIA Corporation (NVDA) Earnings Call Transcript & Summary

Hi, everyone. Thank you for joining us today for the Computer Vision Speaker Series. My name is Sirisha Rella. I work on the Computer Vision team here at NVIDIA. Before we begin, we wanted to cover a few housekeeping items. More information can be found in the upper-right corner of the window. All windows open on the screen are resizable and movable. If you have any questions during the webcast you can submit them to the Q&A window. We will try to answer these at the end of the event. A copy of today's slide deck and additional help materials are available in the resource list. We encourage you to download any resources or bookmark any links that you may find useful. Here are some tips that can help me this event as best it can be. To maximize the quality of those audio stream, please close any open applications aside from your browser window. Also, a good old-fashioned browser refresh can cure many ills. So if your audio sputters or the slide seems to be lagging, give that a try. You can also try opening this event in a different browser. If you encounter any other technical issues today, please let us know in the Q&A box, and we will help you troubleshoot. Now without further ado, I'll turn the event over to our speaker to begin the presentation.

Good morning, everyone. Today, we are going to talk about Decode Medical Images in AWS HealthImaging using NVIDIA's nvJPEG2000. Today with me, Steve Fu, he's a principal solution architect from AWS; then myself, Mahesh, I'm a team lead for NPP nvJPEG library. With me joining Zoheb. Zoheb, will help me out with understanding nvJPEG2000, architecture detail and performance number. So today's agenda, we are going to be talking about the image decoding, and then we will talk about introduction to AWS HealthImaging API, then we will talk about something about medical imaging AI use case, how it will be benefited, and then how the NVIDIA's GPU-accelerated solution help you to save some money, save some performance, then we do some performance comparison. So what is image decoding? So like there is like a lot of discussion going on with images, like what kind of medical images are suitable over the period of like JPEG lossless or JPEG-LS is the best solution. But typically it is having some issues, those are like non-scalable, not having [indiscernible] approach, then JPEG2000 comes -- but it is like low adaptation level because of various issues like open-source [ implementation ] not available, then there is a issue with some kind of licensing to overcome that. Additionally, there are some new features that are addressed with a high-throughput J2K that is likely resolution scalability, then region of interest accessibility, then dynamic range, high dynamic range, multi-channel image support. So we are going to talk about more in detail. And then additionally, the high-throughput J2K come up with a royalty free. So that is additional advantage. So with that, I will hand over the talk to Steve, so he will talk about AWS.

Thank you, Mahesh. I may share my screen. Hello, everyone. Steve Fu, Principal Solutions Architect with AWS. I'm going to talk about how this imaging decoding -- encoding/decoding technology in medical imaging field. AWS has a new service called AWS HealthImaging. It can deliver subsecond image retrievable from anywhere and very scalable performance image store on the cloud. With this image service, we want to make the image available. People can access it in a pretty subsecond So there are several use case using this medical imaging. The benefit people can get including, reduce the total cost of ownership with this image, lossless image encoding technology, people can save the storage cost and data transfer cost. People can access the image from anywhere with a flexible and fine-grained image access control on AWS. They can automate their infrastructure management and then use it -- use the data on the cloud for different downstream tasks. And we build this service with a broad partner network. So their PACS vendors, image viewers and VNA partners, they can build their platform, build their product with this service. How does AWS HealthImaging work? So the PACS viewer and the VNA vendors on premises, they can upload the data to the cloud. The data will land on Amazon Simple Storage Service, short for S3. It's a persistent store. Once the data landed in S3, AWS HealthImaging will have a major import job, import the data into HealthImaging data store. Once the data in the data store, the DICOM header and the pixel frame data will be stored separately. And there's a native API. The user can retrieve the data in a faster way. It can be used to support the downstream task, including AI/ML use case, data sharing and the federation use case or build clinical applications like image visualization, image viewer and other applications. So there -- AWS HealthImaging support different modality of medical imaging as long as they are in DICOM format, including ultrasound, X-ray, CT scan, and can be used for image archive as well. So there is a different PACS and VNA and analytics application. They can interact with AWS HealthImaging. You can have a single copy of data and support different workflow, including clinical workflow or research workflow. It is also DICOM-compliant and HIPAA-eligible service. We talk about the use case it can support, including the enterprise imaging use case to get the low-latency performance and also support AI/ML use case for large-scale data retrieval and use for long-term image archival and also support the multimodal data analysis. There's a different purpose-built data store on AWS. This is a typical AI/ML use case. People can be -- this can be enabled by HealthImaging and other AWS services and the rate on the cloud. So you can get the image from on-prem workstation and PACS, our VNA store onto the cloud, import it into AWS HealthImaging. From there, you can use a cloud-based data scientist platform called Amazon SageMaker. It has the interactive development environment, support of notebook, manage the training and model deployment. The SageMaker can read data from HealthImaging. If you want to do cohort analysis, recycle query and digest the data, you can get -- read the DICOM header from the HealthImaging and put them in Amazon S3 cloud data catalog using Glue and being able to query this data using the SQL compatible query service called Amazon Athena. For AI/ML, the most important step is to get the image pixel-frame data and decode it into computable [ culture rate ]. So this is important, decoding can be done -- there's different options you can do this decoding. So I will walk you through. So on the left, AWS HealthImaging store the DICOM header in JSON format and pixel frame in high-throughput JPEG2000-encoded format. So you can retrieve the DICOM header and the pixel frame in binary blob using the native API. Once you get the data, you can -- you have option to decode the pixel frame. In CPU, our NVIDIA has nvJPEG2000, you can decode the binary blob in GPU memory. So we would compare those 2 options and see what is the benefit you can get using the GPU decoding. You can run this lab in AWS data science platform called SageMaker. There's a couple of step you can create the SageMaker domain, launch the Sagemaker Studio and install the open-source library and the extension for visualizing the image -- medical image on AWS. We will have a demo later on. With that, I will turn it to Zoheb to talk more about nvJPEG2000. Thank you.

Thank you Steve. Hi, everyone. I'll go over the high-throughput JPEG2000 standard and how nvJPEG2000 goes about implementing it. So first, let's take a look at what high-throughput JPEG2000 does. It was introduced in 2019 as an extension to the JPEG2000 standard. The key difference in this new extension is that, it has a new block coding algorithm, which results in a 10x speed up compared to the existing JPEG2000 block coding. This applies for both encoding and decoding. The way it's designed is that it's a drop-in replacement for the existing algorithm. So it makes it easy for existing JPEG2000 codecs to implement. And this -- and it's significantly less complex. So this being one of the reasons for better performance. The trade-off here is that there's a slight loss in compression ratio compared to the existing JPEG2000 standard, which is about 5%, but this loss is offset by higher throughput when it comes to decoding. And since it's a drop-in replacement, it supports almost all of the advanced JPEG2000 features, especially like scalable resolution access, where you can decode only a lower resolution in place. And unlike the existing JPEG2000, which did have some royalty concerns, high-throughput JPEG2000 is royalty-free, thereby making it easy for newer software implementations. So this is a block diagram of how the high-throughput JPEG2000 encoder and decoder looks. The blocks on the top correspond to the encoder and the blocks on the bottom, which are just the inverse process, correspond to the decoding which correspond to the decoder. So the blocks on the top accept the input image and generate the high-throughput code stream, and the reverse is true for the decoder blocks. So in terms of the features that nvJPEG2000 supports, we -- the library supports decoding in single image and pipeline image mode. By pipelining, it's possible to decode multiple images using different CUDA streams, thereby increasing throughput. The image type that is supported covers both grayscale and color images with any width and height. The bit depth, the library supports up to 16 bits per channel with both lossy and lossless modes of operation. Coming to the high-throughput JPEG2000 features. The code blocks have to be -- all code blocks have to be high throughput without any refinement passes enabled. In terms of code block size, all powers of 2 core blocks are supported starting from 64x64 down to 16x16. All progression orders defined by the standard are supported. There's also no restriction placed on the number of resolutions or decomposition levels. The same applies to the number of tiles, and there's dimensions for both encode and decode. Let's take a look at the APIs that are available for -- as part of the nvJPEG2000 library. There is C API for both the tile and image decoding. nvJPEG2000 will decode an entire image and write it -- and write the result to output device buffers. Similarly, nvJPEG2k tile API will decode only a tile of interest and write the output to device buffers. So when dealing with JPEG2000 files with multiple tiles, it helps to use the tile API for higher throughput. Let's take a look at the Python interface here. So Python interface is like really easy to use and the result is written out to GPU memory. In this example here, we instantiate a decoder and encoder object and use the decoder object to read a JPEG2000 file. This example here only shows how to read the file from disk, but there are APIs which will -- which is possible to decode file from host memory as well. In terms of the high-throughput JPEG2000 performance on -- with nvJPEG2000, let's compare the performance against some known CPU implementation. For reference, we have a multi-threaded Kakadu decoder, and we also have OpenJPH, which is the high-throughput JPEG2000's reference software. When it comes to nvJPEG2000 performance, we have 2 sets of data points. One is with single image decoding and one is with batch image decoding. So -- and 2 types of medical images are used for this benchmark. The smaller 512x512 CT scan and the larger mammogram images. So with the CT scan images, in single image more the nvJPEG2000 throughput is around 6 to 8 FPS, which is lesser than multi-threaded implementation because the amount of parallelism that is possible to exploit is less here. However, this can be overcome by running the library in batch mode, where the throughput increases to 4619 FPS. Coming to the mammogram images. We see that in both single image and batched image cases, the performance is significantly higher than multi-threaded CPU implementations. With single image decode, the decode throughput is 169 FPS. And when it comes to the batch mode, this further increases to 402 frames per second. So in the graph here on the right-hand side, we are -- with the same data set, we've run tests on the various NVIDIA GPUs from -- starting from Volta architecture all the way to Hopper. And we see that for 512x512 CT scan images, the throughput is -- we manage to read 4,000 on all GPUs. And similarly, for the mammogram images, we can -- we see a similar speed up. Like that is -- the throughput reaches 400 FPS on most of the larger GPUs. The graph on the bottom right talks about the speed up relative to the multi-threaded CPU implementation. Even here, there is a similar performance speedup seen across all the GPU families. That's it from me. Over to Mahesh for the rest of this presentation.

Thank you, Zoheb. So now we will talk about the real-time performance number with AWS data set. So we have the image data set #1, which is a 99 brain MRI images. The pixel frames are like 25,000 frames are there. Over there, we saw that around 7.5x speedup in image set 1. And for image set 2, where we have the 298 brain MRI images, where the 76,000 pixel frames over there we found 8.1 frames per second. So overall GPU decoding speed is around 7x faster compared to CPU. So that's advantage for all the medical community to switch to high-throughput J2K with nvJPEG2000. So now I'm going to discuss about one more framework that is more like a medical open-network for AI. So in this, basically, with AWS MONAI and nvJPEG, the map we provide you to deploy your application through SageMaker. And that benefit you to usability like how to use specific application, then you can get high-performance application end-to-end-wise. And it will help you to get a debugging capability like if you want to debug and get some intermediate results. And it's like a production-ready environment, so that will cover all your MONAI application. So right now, I'm comparing one application that is typically segmentation of the lung. So this application, I'm considering to calculate end-to-end benefit, like how the typical end-to-end application for a typical session. So here, the DICOM data, DICOM images, which are encoded in the form of JPEG2k like high-throughput JPEG2k. We load the data then segment the particular section of the lung, and we classify with our data set. And once it is classified, we write down the output data into DICOM format so that way doctor can use for the diagnostic purpose. So when I compare this application end-to-end, for the GPU processing benefit and cost-benefit analysis, I have considered here Amazon EC2 G4 Instance, which is basically offering 1 GPU, which is T4 or the 4 GPU instance. So basically -- and for this analysis, I'm considering how much preservation cost per hour, then how much total cost you are spending per year and what is the GPU throughput you can get by switching to end-to-end pipeline. So if you take a look on the graph -- throughput graph, in the CPU see, if you see here in the CPU, you're required 37 frames per second to run end-to-end your pipeline. For this throughput, I have considered 500 hours of DICOM recording used to run through the end-to-end application. Same thing, if I run through the T4, I'm going to see 164 frames per second. And then if we have the 4 instances of the T4, it will be 653 per second. So it's typically like you can gain almost 5x speedup with respect to CPU to GPU switching. And here, we are talking about L4 GPU, which is our latest GPU from NVIDIA offering for cloud service provider. So that also you can see almost 3 to 4x more improvement over the T4 GPUs. So annual cost calculation-wise, I'm considering that how much time you were 500 DICOM data samples are used to get and how much money you have to spend to do all the analysis for a year. So if you compare one CPU, it's around $345 million you need to spend to come and analyze your entire medical segmentation algorithm. So that's -- and then if you switch back to the GPU T4, it will be $74 million. So the cost saving is tremendously high. And then in terms of the energy consumption-wise, it's the right side of the graph. It will be give you like how much total energy you save by switching back to the GPU. So with that, how to reach us. So there are like different way you can reach us. So I have put some of the QR code here. So with that QR code, you can able to reach out to us, AWS HealthImaging API or some kind of API references, the links are provided or you can use QR code. So MONAI AWS, like end-to-end deploy application, the GitHub pages pointed out. And then if anybody want to interest with nvJPEG2000 to explore more, we have the documentation and a good number of examples are listed into GitHub page. Happy to help with that. With that, we will switch back to the demo. And then after that, we will have some question answers. Thank you.

Let me quick share my screen for the demo. What I'm going to show you is Amazon SageMaker IDE. So SageMaker Studio is a cloud-based IDE based on Jupyter lab, so people already use together Jupyter Notebook. They should be -- the SageMaker Studio should look familiar to them. I'm using container running G4 instance. G4 with a NVIDIA T4 GPU and using the PyTorch. So through the Python API, we can interact with AWS HealthImaging to retrieve the data, including read the DICOM header and pixel frame data. So we already have a data store created. We will read the DICOM header first and then raise the pixel data later on. So we can retrieve all of the data using multi-threading approach, get the pixel frame data. Then we compare decoding using Open JPEG, which decode the pixel -- the high-throughput JPEG2000 pixel frame in CPU memory and also when decoding using nvJPEG2000. As you can see, the time difference, we record decoding process step in second. The GPU decoding can save a lot of time. From there, after decoding, you can see in the [ non-tier ] into MONAI library and train merchant learning model and revenue model influence on SageMaker. So that's for the demo. Thank you.

Thank you, guys. That was a great presentation. [Operator Instructions] Let's get started. Our first question is, is this available on Jetson? For example, is nvJPEG HTJ2k included in JetPack?

Zoheb, can you take care of that?

Sure. Yes. Currently, we don't support nvJPEG2000 library on JetPack, but that's something we will consider for a future release.

Awesome, awesome. Good to know. So our next question is, is Kakadu library using single CPU core or multicores?

For the benchmarking performance, it's using multicores. So it's multi-threaded CPU versus GPU performance that we compare.

Awesome. So next question is, does the library nvJPEG2000 support on Jetson AGX Orin?

Not at this time, but we will look at adding that sensor.

Yes, yes. I think it's similar to the first question, whether nvJPEG has a put on Jetpack and Jetson or not. So moving on to our next question. Do you have the frames per second of lossless versus lossy compression?

We didn't collect data for this since it was like medical imaging, and they mostly tend to be lossless. But I would imagine if somebody is interested in lossy, then it would be like significant -- like the speedup would depend on the amount of loss applied. But we don't have explicit data.

Yes. We did test with some of our random generated data for lossy and lossless. So we ran encoder, we generate our 2k and 4k images and then decode that performance. So that performance number is available, but it's generated by encoder and decoder at our end.

Okay, okay. Awesome. And also audience, I guess some of the performance numbers are also there on nvJPEG or the product pages on NVIDIA channels. Like you can -- and the documentation as well. You can take out some of the performance graphs on our documentation and -- on our web page as well. So moving on to our next question. The resolution of the medical images from different modalities are the most critical factor of the medical images for radiologists to see the details they are looking for. How do you make sure the details are not compromised with compression?

Yes. So the type of JPEG2000 encoding we use this lossless encoding. And we do have data validation after the data ingested in AWS HealthImaging. When we they do comparison, it's also we compare nvJPEG2000 codec and open JPEG decoding. They all produce the same data.

Awesome, awesome. I guess this is an interesting question. But I guess, depending on the use case where in health care, as the question says, the details are very important. They can go with lossless compression. And then maybe for any entertainment use cases or gaming use cases, I guess the lossy compression still might work. So I guess, yes, it's a very interesting question. So moving on to our next one. What's the appropriate edge device we can run this? Does the Jetson Orin Nano work for this or -- I guess Zoheb already answered this, that we currently don't support on Jetson, but would you like to add any more details in here?

That's something we can look into, I guess. We primarily have focused on cloud right now, but yes, Jetson is something we...

Awesome.

In addition to Zoheb comment, Jetson Orin is memory-wise, very low device. So certainly image like medical imaging use case is not covered because where the image data or the memory is hungry. So Jetson Orin is not -- Nano is basically low-memory device. But if you consider Orin with high memory throughput, we definitely try it on that.

Okay. Okay. Awesome. So next question is when making the choice of CPU or GPU, where is this processing occurring? If endpoint, is there a recommended endpoint hardware for workstations?

Yes. So I think what we have compare CPU, GPU on the cloud, it can definitely can be done on-prem. To do comparison the GPU, we use NVIDIA 810G GPU for the comparison in the demo example, yes.

Awesome. So our next question is, are the institutions expected to have their own PACS on-prem? Or is the intention to replace the PACS with AWS HealthImaging?

So the PACS system is -- you can still use your existing PACS system either on-prem or cloud-native PACS. So AWS HealthImaging is not going to replace PACS or VNA, right. Instead, we work closely with the partners, the PACS vendor and the VNA vendors to use AWS HealthImaging as a storage back end for the PACS or VNA.

Awesome, awesome. interesting. So it's basically AWS HealthImaging is complementing the PACS, and it's not the replacement. Makes sense.

Exactly. Yes.

So our next question is, is there any mechanism to make sure the accuracy of the data and transformation from one source to one destination like bits level checks on data?

I think we mentioned the high-throughput JPEG2000. Codec is a lossless encoding. So yes, it will be same data, just highly compressed, yes.

Awesome. So moving on to our next question. Is the header separated from the image to protect patient privacy?

So the data privacy can be handled by data encryption, network isolation. And there's also other security Guardrails items. The separation from the -- DICOM header from pixel frame is primarily for data consumption, right? So some use case, you just need the DICOM header, and some use case, you do need to get them consume them separately. So like AML, use workloads or other use case. So it's primarily for data consumption purpose.

Awesome. Awesome. So next question is, I'm looking for public entry annotated images of breast cancer to change my algorithms. I guess Mahesh, already shared a link through text chat. Guys, you can explore, know the Kaggle link that Mahesh has provided for free annotated or breast cancer image datasets. So moving on to our next question. Any thoughts on comparison between nvJPEG2K and nv...

Yes. I will take that one. So in recompletion -- data completion library. Those are not deal with images right now, but anyway, JPEG is basically focused on JPEG2000 standard. And then we are offering high throughput J2K and additional performance improvement on that. So there is no comparison between who a different library.

Awesome. So next question is, what are the benefits of high throughput J2K over TIFF for example?

It could achieve better compression.

Sorry. Sorry, sorry, go ahead. Can you repeat it?

Yes. So high throughput JPEG2K, like the algorithm is designed mainly for like images in mind, and it will achieve better lossless compression compared to TIFF. Like TIFF is more of a container format and your compression might depend on what the underlying compression is, whether it's LZW or ZLIB. And those are found to have like lower compression compared to high-throughput JPEG2000.

Awesome, awesome. Moving on to our next question. Okay. Are there any current deployments or live customers? What components are currently being used in production?

So at least for AWS HealthImaging, yes, we do. We do have a launching partner like medical image viewer. They build their product on AWS HealthImaging. And we are working closely with health care provider as well. For them it could be a data archive or research purpose, right, AI/ML. They can use this cost-optimized cloud storage for their large volume of data.

Awesome. So next question is, what is the tool you use to annotate the images? Steve, would you like to take that question?

Right. I think we primarily compare data decoding -- encoding and decoding speed. For data annotation with their open-source image viewer, which can be deployed on AWS, for example, 3D slicer or [indiscernible], open source they can work with AWS HealthImaging. For on-prem, yes, you can -- you also have other options, yes, to be realized as well.

Awesome, awesome. Yes, and then also, I guess there are some of the open-source annotation tools as well. And then recently, I've seen there are these new features, AI-based -- AI-assisted annotation that so many of the companies are providing these features, which is like reduces number of manual hours of labeling or annotating the data set. And I think, yes, you guys can explore -- audience can explore a couple of those options as well. So with that, moving on to our next question. I'm trying to understand how this would work in a distributed health care network. How is the support operated for this offering?

Yes. I can try to answer it. For health care network, the data archive and secondary PACS or secondary storage are very important, right? And also speed, performance is also very important. So using this cloud-based storage plus the high-speed decoding approach, so that can accelerate your research, right, from there, yes.

Awesome. Our next question is, health care is a highly regulated industry. How do you address images of a person space that may compromise a person's or patient's privacy?

Yes. So I can try to answer that. AWS HealthImaging is a HIPAA-eligible service, but there's also a shared responsibility, right? We do have a HIPAA lending zone program to help AWS customer to meet the HIPAA requirement and other security privacy compliance requirement.

Awesome. The next question is from [ Mayo Clinic ]. While training a deep learning, I believe you are suggesting that the data is encoded and then decoded before feeding it to neural network. Or do you suggest training on encoded images?

It will be the first option. You do have decoding. You need to decode into a [ Numpy array ] and Tensor to fit into the network -- deep network -- neural network training process, right? And that decoding, using GPU decoding, it can save time not only on data decoding, but also you don't need to copy data from CPU to GPU. That will be the benefit using the nvJPEG2000 here, yes.

Awesome. Yes, I think that makes sense, yes, in, I guess, in any typical computer vision Python as well, first we decode images, then we feed that to a neural network model for training and then while displaying it on the screen, we encode the images or, in some cases, we videos depending on the use case.

I can add one point there. Like if you have an encoded image for training, there is already some losses are there. So if you were training on [indiscernible] learning properly. And there are like some algorithms where people are working on it to improve that accuracy. But for medical domain, we advice start decoding. So that way, you can get losslessly correct pixel value, and then you can train your algorithm so you can get good accuracy.

I see, I see. Makes sense. So moving on to our next question. Does this work for histopathology images as well? These are very high-resolution images like 20,000x20,000.

I can answer that from AWS perspective. Right now, AWS HealthImaging only support DICOM -- only support image in DICOM format. We do have plan to support histopathology image. That's on the road map, yes.

Yes. On nvJPEG2K side, we do support histopathology images, but they're underrated tile more. So if you have that supporting multi-tile environment, so we do support a decoding capability.

There's also low-resolution decoding and region of interest decoding. Yes, there's various ways to handle very large images with the library.

Okay, okay. Awesome. And also, Mahesh, if I'm not wrong, we also do have NPP, which supports like data processing for large resolution images, right?

Right. So with NVIDIA, we have like image processing library known as NPP. So that will provide you a basic image processing or more returns with the larger data set.

Excellent. So next question is, how can I ensure that high-throughput J2K images match the original DICOMs?

Right. So the data ingest into AWS HealthImaging, we do a validation. And you can decode it. So in this comparison, we also decoded and compare it would be the same, same data after decoded on client side, yes.

Awesome. So next question is, what are the functionalities of MONAI besides image segmentation?

Yes. So we use MONAI a lot. I can try to answer it from AWS side. So MONAI has 3 primary component: MONAI Core, MONAI Deploy, MONAI Label. We have the solution, you can rate on the cloud on-premises. MONAI Core is for model training, MONAI Deploy is for EV model deployment and integrate with the image processing pipeline. MONAI Label, I think we have a previous question asked about data annotation. On the Label supports AI-assist the annotation. This is primarily useful for 3D segmentation.

Awesome. Makes sense. And Mahesh and team, would you like to add more details?

With MONAI like right now, we are already supporting 2 more applications. One is a segmentation that we covered and additionally, the translation of that tumor so that 2 applications are already available through a GitHub web page.

Awesome. Makes sense. So our next question is, will MONAI have a PyTorch data loader, which can read directly from an AWS HealthImaging repo?

Yes, we are working on -- so right now, we have an open-source code base on GitHub that can -- you can read -- there are 2 repo available. One is you can read the data, the pixel frame and DICOM header into and create a DICOM object. That DICOM object can see the MONAI deploy model inference, right? So that's available. And most recently, we also have a high-speed distributed data retriever on the AWS HealthImaging open source example. So if you look for AWS HealthImaging, GitHub example, there are several open-source projects. Well, then show how to download data, more scalable, right, using distributed approach from AWS HealthImaging. And from there, you can feed in the decoding and model training process.

Awesome, awesome. Zoheb, would you like to add anything to this question?

Nothing more. I have nothing.

Okay. So moving on to our next question. Is MONAI, a stand-alone library that can be deployed locally and not on cloud?

Yes, you can. Although we do have easy-to-deploy solution on AWS. MONAI Core and MONAI Deploy and MONAI Label. Yes.

Awesome. So basically, it can be deployed locally and on cloud and on-premise, as well right?

Yes.

Awesome. So next question is, how exactly having 4 GPUs increase the performance in more than 4x?

There are various factors were considered here, like how the data transfer and then how we split the algorithm between multi-CPU and multi-file base. So that help us to minimize the gap between data transfer. And everything is available on to GPU to accelerate processing. So that's the way. Then the network switches which we are having. Like all 4 GPU or on the same GPU environment. So that will minimize event overhead. So that help us to linearize our performance. And for this experiment, I'm considering 500 data sample. Those are like continuously reading. So that's why we gain some performance there.

Awesome. Make sense. So next question is, do we have a model that is already trained on the AWS HealthImages that we can use in transfer learning?

There are several open-source model, including MONAI model Zoo. That's a repository for open-source deep learning model, right? There's plenty of segmentation model available out there, yes. Any open-source model, you can plug in and running -- and retrieve data from HealthImaging for further finding our inference purpose, yes.

Awesome. Your next question is from [indiscernible] Enterprise. Is there any way to take advantage of high-throughput J2K NVIDIA decoder inside a browser? Mahesh and Zoheb?

Right now, the browser is not supported because the Chrome and other community are not providing the J2K or high-throughput JPEG decoding through the browser. So right now you have to use standalone version.

Makes sense. The next question is, is there any way to export data stored in AWS HealthImaging back to DICOM format to prevent vendor lock-in?

Yes. Yes, you can. We do have an open-source library. You can export DICOM Object, basically, retrieve the pixel frame header and using like open-source to tie DICOM library, you can put together a DICOM object.

Awesome. I think we covered most of the questions. And once again, thank you all for joining us for this event. An on-demand version of the webcast will be available approximately 1 hour after this event ends and can be accessed using the same link. That wraps up all our sessions of Computer Vision Speaker Series. Thank you again for joining us, and have a good one.

Thank you.

Thanks.

Thank you.