> 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.
This is already my struggle, but I can understand that many users don't care about the underlying datatypes as much. In my use cases, I need to minimise the conversions as much as possible, and would like OIIO to give me native pixels wherever possible. I agree it wouldn't really simplify from the app point of view, but it would mean I don't have to check 2 different attributes to read the same thing. Part of me selfishly thinks that although dealing with per channel data types would be more difficult, it is complexity that would be nicely contained inside of the OIIO library code. > 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. I opened a ticket about it a while ago, but haven't had a chance to do a deep dive: https://github.com/OpenImageIO/oiio/issues/2910 On Thu, Jan 6, 2022 at 7:26 PM Larry Gritz <l...@larrygritz.com> wrote: > On Jan 6, 2022, at 2:17 AM, Mark Boorer <markbo...@gmail.com> 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 > l...@larrygritz.com > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
