Franklin Koch

@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...

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...

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,...

@banesullivan - that would be very cool. A combo of notebooks on github, example code in readthedocs, and a reference .omf file for download would be amazing. Sounds like timing...

@dbrookes96 - You are right about no backwards compatibility. I think there are a couple options: 1. Bundle v1 as a submodule in v2 with some extra translation functions (despite...

Hi @michiboo - thanks for the interest! We would love to have your contributions! Please refer to the [contributing file](https://github.com/gmggroup/omf/blob/dev/CONTRIBUTING.md#code) for general information on how to contribute. Regarding this issue...

Hey @banesullivan: For OMF v1, this is technically supported by the file format, but no client library exists to expose this functionality. The binary file is saved as: ``` fixed-length-header...

The above scope of work was reviewed and agreed upon at a GMG Data Access and Usage Working Group meeting 17 July 2019.

@josephwinston - Thanks for the comment! GMG is currently putting together a Request for Proposals (with info about bidding process, etc) around the technical scope of work described here. I...

Yes - your interpretation is exactly what I have in mind - no `offset_w` means flat. I'll update the documentation.