Build correctly against OCIO 2.x (in progress) #2530
Conversation
And incorporate a build against OCIO master into the "bleeding edge" CI test, so we don't drift out of sync again.
|
Just to clarify, OCIO v2 won't be released for months. This is just ensuring that we can build OIIO against OCIO's master at all times. |
| return OCIO::BIT_DEPTH_UINT16; | ||
| if (type == TypeDesc::UINT32) | ||
| return OCIO::BIT_DEPTH_UINT32; | ||
| // N.B.: OCIOv2 also supports 10, 12, and 14 bit int, but we won't |
There was a problem hiding this comment.
Not sure exactly what you use this function for, but I just wanted to clarify something in case it may be helpful ... The OCIO BitDepth enum is unchanged from v1. What has changed is that we can now process image buffers that are not F32. However we did not add support for all of the BitDepths that v1 declared. The pixel types we support in v2 are UINT8, UINT10, UINT12, UINT16, F16, and F32. Note that we do not support (that is, are unable to process) the UINT14 or UINT32 pixel types.
There was a problem hiding this comment.
OK, that's good to know. I will adjust the comments.
Currently, the rest of OIIO's interface with OCIO assumes (from v1) that it can only handle float, so that's the only kind of buffer that's passed into this section. But when v2 is released, there are probably places where I can accommodate that without needing to do data type conversions first.
There was a problem hiding this comment.
In case it could help OCIOv2 now supports the channel ordering for PackedImageDesc:
enum ChannelOrdering
{
CHANNEL_ORDERING_RGBA = 0,
CHANNEL_ORDERING_BGRA,
CHANNEL_ORDERING_ABGR,
CHANNEL_ORDERING_RGB,
CHANNEL_ORDERING_BGR
};
…tion#2530) And incorporate a build against OCIO master into the "bleeding edge" CI test, so we don't drift out of sync again.
And incorporate a build against OCIO master into the "bleeding edge" CI test, so we don't drift out of sync again.