Feature Request: Other image formats for Textures (TIF, general array, etc.)

[banesullivan]

Forcing textures to be properites.ImagePNG is too restrictive. I'm working on a project now where I have several tif files that I need to associate with a SurfaceElement.

This is a very high priority for me... I really need the ImageTexture class to allow TIF files but as a quick/dirty workaround, could I cast a 3D NumPy array to an ImagePNG object?

[fwkoch]

@banesullivan - As the label suggests, we propose adding this functionality to OMF v2. We would not validating the image binary at all to allow any image type.

As a quick and dirty solution, there are a couple options:

• If you are coming from numpy, you can use pypng to read the data. See the example here: https://pythonhosted.org/pypng/ex.html#numpy-array-to-png-writing - (you should be able to use BytesIO for the file rather than writing to disk).
• Alternatively, you could use pillow to explicitly convert your image.

  from PIL import Image
  img = Image.open('my_image.tif')
  img.save('my_image.png', 'png')

Hopefully that helps?

(I've also used gdal for getting image data and geolocation from geotiffs, it that's helpful)

[banesullivan]

Thanks @fwkoch! I got it to work yesterday by converting the TIFs to PNGs with your code snippet.

I had tried this conversion initially but was using imageio.imread to read the byte stream from the OMF object. For some reason, imageio was not working for my images but pillow's Image.open did the trick (not sure why but thought I'd share for anyone else experiencing trouble with the textures).

I'd definitely like to see support for TIF images in the future but I'd also like to see support for general 3D arrays of the shape (*, *, 3), data type uint8, as this would enable just about any image to be used as a texture.

(I've also used gdal for getting image data and geolocation from geotiffs, it that's helpful)

Ah yes, gdal is great! I ended up writing a function that:

1. reads a TIF using both gdal and pillow
2. extracts the spatial reference using gdal
3. converts to a new PNG file using pillow
4. creates an ImageTexture element by passing the filename of the new PNG file
5. converts the ground control points from gdal to the origin and axis_* properties.

Thought I'd post in case someone else stumbles upon this issue

[fwkoch]

The idea of using numpy arrays for texture images was brought up again here - https://github.com/gmggroup/omf/pull/87#pullrequestreview-286238598

Given the current OMF v2 spec, these types of arrays will be somewhat supported in 2 ways:

• If the colors correspond to element geometry (i.e. per face/vertex/etc) they may be applied as an attribute. The new spec has more flexibility with explicitly applying n x 3, uint8 attributes.
• If the colors do not correspond to element geometry, arrays may be converted to PNG. pypng provides a relatively straightforward file writer: https://pythonhosted.org/pypng/png.html#png.Writer - this conversion could even be added as an implicit step in the Python client (i.e. allow users to specify image as array, but serialize to PNG).

For v2.0, GMG decided against supporting other image types. However, with the new zip structure, it would be very straightforward in, say, v2.1 to simply save other image types (.tif or even numpy array .bin). There just needs to be agreement and documentation on what is supported.

I'm curious if anyone else has thoughts about this (particularly using plain array as an image).

[banesullivan]

For v2.0, GMG decided against supporting other image types. However, with the new zip structure, it would be very straightforward in, say, v2.1 to simply save other image types (.tif or even numpy array .bin).

I really think there should be explicit support for TIFs in OMF as they are the most common format I see for ariel imagery, geological surface maps, and other things that would be applied as a texture.

[fwkoch]

Personally, I'm fine with that. Adding more image types would likely help with adoption of OMF. The only trade off is one more feature to support when implementing OMF. However, this probably isn't a big deal since TIF is a standard format, likely already supported everywhere.

Happy to add it, especially if there is buy in from other technical stakeholders (looking at you @CVasey, @dbrookes96, @rminhxm, @markgodresse, @jeremybutlermaptek, @bluetyson, @mike-berriman, @ryanpainter...)