Spaces:

andreped

/

AeroPath

like 11

Running

Hello, @julien-c ! The backend of the AeroPath gradio web app is Raidionics, which is actually a standalone desktop application (see raidionics/Raidionics at GitHub). The reason why GPU inference is not enabled is because 99% of end-users (clinicians) just don't have access to dedicated GPUs or have CUDA runtime and all that stuff set up.

All our deep learning models are in ONNX format and we use ONNX-Runtime inference engine for fast CPU inference. We could support TensorRT IE, but I don't think it would benefit the average user. The same principle applied to the gradio web app.

The main bottleneck of the processing is actually due to 3D pre- and post-processing which is happening with basic Python libraries that only do the compute on CPUs, for instance resampling the volume to isotropic resolution. We are looking into methods to make this faster, but this will likely not happen on GPU, as our main user base would not benefit from it. I also think that it is nice to have it the way it is now, as the current solution also runs well on low-end devices, which clinicians tend to have.

Regarding caching examples, I thought I already did that. You can see that here in the corresponding GitHub repo code. If not, please let me know if you have any suggestions for improvements, @abidlabs ! :)

But note that I am updating a separate dataset repo right now, including several 100 GB of data with histopathological images. I was considering making a similar web app to enable people to test one of our pretrained models on their own data. In this case, due to the insane size of these images, having access to a GPU would definitely be relevant.

The data repo can be found here: https://huggingface.co./datasets/andreped/IBDColEpi/tree/main

Similarly to the AeroPath repo, we also made a desktop application to enable clinicians to run our AI models on their own data locally. The software is open-source and called FastPathology (see AICAN-Research/FAST-Pathology at GitHub).
But I REALLY want to enable people to test those solutions in the cloud through Hugging Face. As Gradio naturally cannot support these insanely large images (200k x 160k pixels), I have chosen to deploy a different software on Hugging Face for that. I have gotten OHIF running in HF (see andreped/ohif4hf at HF Spaces), with the great help of @radames . But I am also looking into Digital Slide Archive (see andreped/dsa4hf at HF Spaces), but that is not done yet. The neat thing with DSA over OHIF, is that I already have demonstrated that our FastPathology pipelines can be ran through DSA, thus enabling AI inference in the cloud (see andreped/FP-DSA-plugin on GitHub). So hopefully, in the near future, people can deploy AI models for histopathological image analysis directly in Hugging Face!

very cool, thanks for sharing!

Thanks @andreped this is super nice!

With regards to caching examples, the code currently only caches the selection/uploading of the file. In other words, only the upload_file() method is cached. You could also cache the volume_renderer() method, which would populate the entire demo as soon as the example is clicked. The easiest way would be to create a single new method, say upload_and_render(), which internally calls upload_file() and volume_render(), and assign upload_and_render() as the fn in the gr.Examples. You'd also have to update the input and output components in gr.Examples. If you do this, then setting cache_examples=True, will cache everything

With regards to displaying very large images, you're right, the default Image component is not designed for that. But if you're interested, this could be a really good use case for a Custom Gradio Component. To elaborate, in Gradio 4.0, we've made it possible for Gradio users to create their own custom components -- meaning that you can write some Python and JavaScript (Svelte), and publish it as a Gradio component. You can use it in your own Gradio apps, or share it so that anyone can use it in their Gradio apps. Here are some examples of custom Gradio components:

• A "Rich Textbox" that allows you to write bold/italics/colored text: https://huggingface.co./spaces/abidlabs/gradio_rich_textbox
• A "Folium Map Viewer" component that allows you to use interactive maps: https://huggingface.co./spaces/freddyaboulton/gradio_folium

You can see the source code for those components by clicking the "Files" icon and then clicking "src". The complete source code for the backend and frontend is visible. If you'd like to get started, we've put together a Guide: https://www.gradio.app/guides/five-minute-guide, and we're happy to help.

You could also cache the volume_renderer() method, which would populate the entire demo as soon as the example is clicked.

Oh, that's interesting. I have not really considered that. I will look into that soon. Thank for the tip!

With regards to displaying very large images, you're right, the default Image component is not designed for that. But if you're interested, this could be a really good use case for a Custom Gradio Component.

Amazing feature! We are looking into adding webGL support to FAST, or at least in some variant, which may be what we need to add rendering support. Alternatively, we could use OpenSeadragon to just make a proof-of-concept. I have made the pathology dataset available at https://huggingface.co./datasets/andreped/IBDColEpi

I will look into making a web demo to be hosted at HF Spaces very soon. Here it would be neat if the UI was made with Gradio and rendering was done with some other method, like FAST or OpenSeadragon. Will keep you updated if I get anything working!

If you'd like to get started, we've put together a Guide: https://www.gradio.app/guides/five-minute-guide, and we're happy to help.

I will for sure get started soon. Right now I am doing all this in my spare time, as I don't have allocated funding for this anymore, but I will let you know if I run into any issues. Thanks, @abidlabs ! :)