Support of *.tiff files

[eragon12391]

In the Image interface in the Input, can you provide support for 'tiff files'

[aliabd]

Thanks for opening an issue @eragon12391.

@aliabid94 can you take a look at this?

[abidlabs]

@eragon12391 can you tell us a little more about your use case? It will help us design the UI if we have a sense of what kind of models you are interested in building UIs for

[tmabraham]

@abidlabs I don't need anything special in terms of UI, just need to be able to upload *.tif files. Does the TOAST UI image editor you guys have not support *.tif files?

[moznpan]

it looks like scikit-image is already a requirement and scikit-image does support loading of tiff files, but tiff files are often used as a special case of image file that has support for storing stacked images. I've most often run into tiffs doing satellite imagery work with rasters, where the data can have multiple channels, but also a dimension for each band/sensor (vegetation spectra, emissions), and of course your normal WxH. If you look at scikit-image's current imread function, you'll see that it expects a "key" for the image in the stack you want. Some of the examples they give have images that are

• (5, 3, 301, 219) == (band, channel, height, width) == BCHW
• (2, 3, 4, 301, 219) or NBCHW I'm guessing?

Point is - tiffs are weird exceptions that probably need some thinking to integrate and display properly. I think what @abidlabs was getting at was "if we load in tiff files that have more than one image stored, how do we display those while helping with your use case?"

I assume there probably won't be a one-size-fits-all approach for displaying tiff files short of assuming the best case as a single-band-single-image tiff file with channels being one of the standard (null or 1 for grayscale, 3 for rgb/bgr/hsv etc, or 4 for rgba) and the regular HxW.

The alternative would require some design choices in laying out all the other images and bands in a tilegrid, or some fancy js to stack and toggle between them probably.

I hope that helps @tmabraham @abidlabs @aliabid94

[dawoodkhan82]

@eragon12391 This is a feature we will add support. I'll update this issue when we do.

[luisoala]

hi @dawoodkhan82 thanks for the effort. i have a similar issues. is there any update or workaround for .tif/.tiff files?

[MichaelSNelson]

Bumping this as I am interested in using .tif files from research. RGB would be a start, as multichannel would likely be challenging :)

[abidlabs]

Reopening this issue. Perhaps we can tackle as part of #466. cc @pngwn

[aghand0ur]

Hello @pngwn @abidlabs @aliabid94
I am using gradio for an earth observation application:
http://geoai.cnrs.edu.lb/urbanmodels/

Users are trying to upload tiff images with no luck.
It would be extremely helpful to provide support for this format (widely used in the remote sensing community) as part of #466.

[pngwn]

What would support look like? Browsers don't generally support tiff images so short of providing a custom tiff viewer this isn't really possible. The image upload preview and static viewer are just image elements and will display whatever images they can natively.

Do we want a custom tiff viewer? What about other unsupported image types?

[abidlabs]

Probably not in core, but I think it's a good example of a community component, e.g. along the lines of #2031

[aghand0ur]

As a quick workaround, would it be possible for the time being to upload tiff files and pass it to the model without displaying it?
The user needs to download the output and display it locally or might use some tiff browser plugins such as:
https://github.com/my-codeworks/tiff-viewer-extension

[pngwn]

I'd expect that to already work. Will test and get back to you.

[abidlabs]

@aghand0ur if you don't need the image preview, you can use the gr.File component to upload or download the *.tiff file. See more here: https://gradio.app/docs/#file

[aghand0ur]

@abidlabs right, but it would be cumbersome to let the users choose between using the gr.Image or the gr.File components. I expect it might create some confusions for users.
This is why I suggested the following:

As a quick workaround, would it be possible for the time being to upload tiff files and pass it to the model without displaying it? The user needs to download the output and display it locally or might use some tiff browser plugins such as: https://github.com/my-codeworks/tiff-viewer-extension

[aghand0ur]

I'd expect that to already work. Will test and get back to you.

any update from your side @pngwn ?

[aghand0ur]

I'd expect that to already work. Will test and get back to you.

@pngwn @aliabid94 @abidlabs did you get the chance to test this issue?

[jaycecd]

I'd expect that to already work. Will test and get back to you.我希望这已经起作用了。将进行测试并回复您。

Hi, any progress on this issue?

[a-parida12]

Is there a way I can use the output of a cutom image converter that can be used to generate the preview for the tiff or any other image format as part of the gr.Image input box?

[abidlabs]

Not at this moment, but we are working hard towards enabling the creation of fully custom components based on our existing components. Will update when we support that

[abidlabs]

Hi @henryruhs that's a good workaround. I'm leaving this open because we are about to release custom components, and the logic you described could be encapsulated in a custom component for simplicity

[jaycecd]

@abidlabs In my opinion this issue could be closed as tiff is not a web format.

How to implement support in case you really need that:

1. Upload via gradio.File
2. Transform to JPG
3. Show in gradio.Image
4. Perform your operations on the source of gradio.File
5. Update the JPG and refresh gradio.Image

Nice solution, but this approach doesn't record the user actions with the image, such as drawing masks on the image.
@henryruhs

[abidlabs]

Hi! We've now 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
• A "Folium Map Viewer" component that allows you to use interactive maps

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. In particular, its very fast if you want to build off an existing component. We've put together a Guide: https://www.gradio.app/guides/five-minute-guide, and we're happy to help if you'd like to put together a custom component for this issue

[abidlabs]

I'll go ahead and close this issue since we are not planning to include this in the core Gradio library. But happy to help if you are interested in making this a custom Gradio component (feel free to ask questions in this issue).

[jaycecd]

Has anyone implemented a custom component?

[freddyaboulton]

Not yet as far as I'm aware! Please go ahead and let us know if you run into issues @jaycecd

[Atif-Anwer]

I was able to make a .tif preview interface for Gradio using rasterio and PIL. A MWE is given below for anyone who is stuck in a similar issue:

import gradio as gr
import numpy as np
import rasterio
from PIL import Image


def get_file_content(file):
	with rasterio.open(file) as src:
		# Read the image data
		image_data = src.read()
		image = Image.fromarray((image_data[0] * 255).astype(np.uint8))
	return (gr.Image(value=image, type="pil"))


with gr.Blocks() as demo:
	gr.Markdown("# Preview Images:")
	with gr.Group(visible=True):
		with gr.Row(visible=True):
			preview = gr.FileExplorer( scale      = 1,
						  glob        = "*.tif",
						  value       = ["./"],
						  file_count  = "single",
						  root_dir    = "./",
						  elem_id     = "file",
						  every= 1,
						  interactive=True
						)

			image = gr.Image(type="pil")
	preview.change(get_file_content, preview, image)

demo.launch(allowed_paths=["./"])