...
Color: | Follow-up - discussion started Dec 6 Meeting | ||||
OCIO | Issue #102 PR #103 | BorisFX JP Smith to describe their OFX-OCIO mapping, intiially developed so Silhouette and Mocha look at same color. Objective is to have something. Comments from Assimilate and Filmlight who don't internally work with OCIO model, how is this used by plug-ins and host to communicate? | |||
comment by Pierre: There is ASC CDL which somehow requires to be encapsulated into a color space to make sense. There is also new ACES look-up tables and old ones. There is also simple needs such as knowing if input is linear or not without changing the output colorspace...Dennis Adams mention OSL also has questions about colorspace (it's also right now being somehow merged with MaterialX which also has similar issues), and I have a problem with all the new GPU API that collapse pixel color format and color. Also space (e.g. linear sRGB… - do we want piecewise format?). Finally pixel format (e.g. RGBA etc) - I think it makes the API simple but opened to suggestions, I have seen mess in some other API trying to define a lot of color format YUV 422 etc bla bla... However there is something about 10bit/12bit source with defined black and white point we might want to consider for 16bit short buffers? Finally because we (RE:Vision do things like color stabilization we could use if available AWB and AE data etc - this might fall in Meta-Data though not here. Also OCIO and ACES don't have the same white point (D60/D65 chromacities) | no action needed other than collect data points | ||||
colourspace | #PR 63 | also earlier (from which PR is derived): http://openeffects.org/standard_changes/colour-space-handling Discussion is how host and plug-in communicate color space we are in... | Deprecated - Issue Removed |
GPU On hold until implementation of #issue 98 exists and tag as tested or supported by some host. | Status: Ready to be continued | |||||
Action Item | Resolved | ?Issue #98 |
| Would be a good thing to carry over the example for Cuda, Metal and OpenCLGary has pushed new file | ||
list is growing: Metal, Cuda, Vulkan (GLSL, SPIR-V), OneAPI, DirectX. OpenCL etc - Note SPIR-V is only driver simplification, the API remains different even if SPIR-V, we cannot use OpenCL for compute in a Vulkan context | As per last survey, everyone supports at least OpenCL, can add to OpenCL list Digital Anarchy. | |||||
gpu utils | #issue 64 | remember we also have the GPU utils thread (its own PR) for any API like error code to be the same... | Pierre: Edited some typos, added dynamic opt-out option (documented but not a property in OGL suite) | |||
Would be a good thing to carry over the gain example for Cuda, Metal and OpenCL |
////////////////
Interaction - Overlays | over V1 released | As of December 6, Meeting - in hibernation for now | |||
Overlay Draw Suite | Resolved | #PR 97 | * remove typdef of a struct - we assume it's a C API inside a C++ compiler
| (PTM) Issue#99 (#100 on github), pull requested | |
Resolved | * either document this suite must be handshaked before Overlay suite or add a V2 kOfxImageEffectPluginPropOverlayInteractV2 conclusion: V2 is DrawSuite only | (PJ) - Overlay Interact V2 in kOfxImageEffectPluginPropOverlayInteractV2 | |||
Open question | Phil asks about custom UI support... as next in this bucket. Custom UI parameter have the same issue. | Looking for host that actually implements this. Right now the Overlay suite would work - no image display though. |
...