On Jan 6, 2022, at 2:17 AM, Mark Boorer <[email protected]> wrote: > > Also late to the party, but I also find it weird that we have both a single > format/datatype in spec.format, but then also have per-channel > format/datatypes in spec.channelformats. There are large parts of the API > that don't cater to the per-channel case, and silently fail :(
> > I would prefer it if we found a nicer way to express the per-channel case. > Perhaps there could be only one spec.datatype attribute, but it is a vector > that can either contain a single datatype (for the simple case), or one entry > per channel for multiple datatypes. I hear you, but there was a method to the madness. I think we already have, in some sense, what you ask for -- `format` is "a single type that's good enough for all channels, if you want simple logic", and `channelformats` is "empty, if `format` is what every channel is, and n types if the channels in the file didn't all have the same type, and you really want to deal with all that." The idea was that 'format' was one data type that could hold any of the channels with minimal loss of precision (for example, it would be `float` for a file of mixed `float` and `half` channels), and simple apps could in almost all cases behave as if all channels were using the same type. In the very rare cases where an app wants to handle mixed-type images in a native per-channel-type way without automatically up-converting to the common best-fit type, they could use `channelformats` and implement more complicated per-channel logic. If we only had channelformats (as you suggest, adding that if all channels were the same, it would need only one entry -- which I'm not sure really simplifies anything from the app point of view), then EVERY bit of code using the OIIO APIs would need a fantastic amount of complexity to deal with each channel possibly being a different data type. That seemed like a big burden for what was supposed to be a simple API, and when most image file formats don't allow mixed data types at all, and even the ones that do usually were uniform types in practice for most images. I would like to hear more about what silently fails. The intent is that nearly all client code can behave AS IF there were only one data type, but they are also free to deal with the individual channels if they really felt strongly about it. > In any case, lots of code to refactor if we change the name. True, and something we should consider carefully. -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
