Re: [ocs-dev] Re: An OCS by any other name?
Rod Bogart <bog...@...>
I must admit, I've been calling it OpenColorSPIce.
RGB On Fri, Jun 18, 2010 at 3:04 PM, Steve LaVietes <steve.l...@...> wrote: If it's the OCS part that matters:
|
|
Re: [ocs-dev] Re: An OCS by any other name?
Jeremy Selan <jeremy...@...>
Hah! :)
toggle quoted messageShow quoted text
On Fri, Jun 18, 2010 at 3:09 PM, Rod Bogart <bog...@...> wrote:
I must admit, I've been calling it OpenColorSPIce.
|
|
Re: [ocs-dev] Re: An OCS by any other name?
Malcolm Humphreys <malcolmh...@...>
Pending on how the can of worm goes.
toggle quoted messageShow quoted text
The main observation I had with the name OCS is kind of what people are saying here. I feel the name is wrong (with any project not just OCS) if your not using it in conversations with others, or if your spending large amounts of time explaining why it's not what it says on the tin. I would rather spend that energy (even if it is my hot air) in other areas like making the system more complete, usable and adoptable. I think OpenColorManagement maybe is setting the bar a little two high for the project. Unless we think it will be a complete end to end solution. I can also see the ICC will be not be jumping for joy either. ;) http://www.color.org "The purpose of the ICC is to promote the use and adoption of open, vendor-neutral, cross-platform color management systems." After looking at OCS it feels like it's aiming to achieve 3 main things: - a standard / protocol for describing colo(u)r transformation chains - caching / baking of these chains (various lut formats) - evaluation of these chains on the cpu / gpu If this is what the project is trying to achieve (which I think will be amazing) then I would vote for something more like OpenColorIO. Which not only aligns it self well with OIIO but for me it fits better with these 3 overall aims. Really I could deal with pretty much any name other than OpenColorSpace. .malcolm
On 19/06/2010, at 8:09 AM, Rod Bogart wrote:
I must admit, I've been calling it OpenColorSPIce.
|
|
Re: An OCS by any other name?
Jeremy Selan <jeremy...@...>
You've convinced me.
OpenColorIO is pretty damn good. ... and your summary is dead accurate as well. After looking at OCS it feels like it's aiming to achieve 3 main things:Let's ponder this for the weekend.
|
|
OpenColorSpace.h feedback
Malcolm Humphreys <malcolmh...@...>
Hi Jeremy and others, After looking at OpenColorSpace.h a bit today I have some feedback. First I just want to make sure I'm getting the concepts correct. Let me know if these summaries on the core classes are correct? class Config; is a top level configuration object that can be serialised into a .ocs file. Will also define the reference space (most likely scene linear) class ColorSpace; is a definition of color space with an operation chain to get from this space to the top level reference space. class Transform; is the base class for color transform operations class GroupTransform; manages an ordered list of color transform operations class FileTransform; is the base class for look up table transforms ops (Lut1D and Lut3D) I got a bit confused between Ops, Transform and GroupTransform when looking through the code. I can see how they will work just the concepts feel a bit mixed to me. I keep wanting to call a GroupTransform a Transform (or OpList or OpChain) and a Transform an Op. eg, Config ('fabricated') `- ColorSpace ('spacejam') `- Transform (to_reference) `- [ Op::Lut1D (), Op::Gamma (), Op::Foo () ] I don't think FileTransform should be in here. I'll send another email about Ops if this feedback is going in the right direction as I don't want to create two much noise. Family Can you give a brief description of what a family is? I can see 'family' referenced here and there but not currently used. Roles From the description: "ColorSpace Roles are used so that plugins, in addition to this API can have abstract ways of asking for common colorspaces, without referring to them by hardcoded names." I can see the need for an abstract way to tag colorspaces so that client apps don't need to deal with production details like the same ocs color space being called something slightly different on two shows. But it feels wrong for that abstract list of roles to be then hardcoded into the header. I would prefer to have a site-wide .ocs file which defines the possible roles (this file could also define site-wide color space but it wouldn't have too). Then in the local/show/project .ocs you would be able to link one of these abstract role names to a color space in that file/context. I would also like to be able to define new roles just in that project .ocs as well. These show roles would only be used with tools within that show that were written to support them. The long term idea would be to roll them back into the site-wide role definition (if it made sense to do so) but have some ability to test the roll in the show context. I could see my self using roles also for things like dealing with fixed production devices ie ROLE_STILLS_CAMERA1 but I'm not sure if thats what you had in mind. .malcolm
|
|
Re: [ocs-dev] OpenColorSpace.h feedback
Jeremy Selan <jeremy...@...>
yah, these summaries are correct. go to the google group, and check
out the 'internal architecture overview' doc. It's still a huge work in progress but provides a bit more of an overview. I have to run in a few, gonna do a super-quick reply... On another note that im about 50% done with the GPU design, and this will change the class design a bit yet a again. (It introduces a processor class, and all the ApplyTransforms go away. You instead do a instead, and processors have fcns like renderCPU(Img), getGPUShaderText, etc. It's actually much cleaner. The big distinction between transforms and ops are that transforms are client-facing, and ops never escape the library. I could ditch GroupTransform in favor of a transformVec, but it seemed useful to have to avoid all the trouble with returning a vector (windows dll crap). A family relates to bit-depthness, and though the concept is fully fleshed out in our internal spi library im still grappling with how to de-imageworks-ify it. For example, we use the colorspace 'lg10' for 10 bit file io, but the luts used dont have enough precision for 16 bit use. So we also have lg16 for that case. Also, lgh (h standing for half float). These are all in the lg family. It's actually called prefix in the SPI codebase. It would be cool if the concept could go away, but I havent yet figure out how to efficiently make that happen. Roles (their concept) are super useful to have in production because shows often names their colorspaces differently. We found ourselves wanting 'constants' for a whole bunch of em repeatedly, so thats why they're in the library. SCENE_LINEAR being an obvious one, where its useful to want to sometimes reference it by its 'concept'. They are also integral to the display pipeline (code not yet used), where they correspond to certain defaults. (in the display pipeline, fstop expose offsets default to a multiplier in SCENE_LINEAR, and this is how it's driven). The roles (and their API) are just strings though, so facilities are free to use new ones at any time using the same storage mechanism. (At SPI we add extra ones specifying each output media colorspace: quicktime, avi, omf, etc). On Sun, Jun 20, 2010 at 5:53 AM, Malcolm Humphreys <malcolmh...@...> wrote: Hi Jeremy and others,
|
|
Re: [ocs-dev] OpenColorSpace.h feedback
Malcolm Humphreys <malcolmh...@...>
On 20/06/2010, at 10:36 PM, Jeremy Selan wrote:
On another note that im about 50% done with the GPU design, and thisCool, sounds good. The big distinction between transforms and ops are that transforms areWe have started to write some of the plugins we had before for 3delight, mantra, nuke, shake and houdini & mantra for applying the ASC-CDL. At the moment they all use the same code, I was hoping to replace this with an OCS::Op::CDL() op. This I guess changes the requirements for Ops a bit, but I would like to use the same color math across client apps for the simple cases. For cases like 3delight and mantra were you just want to call a single simple Op per sample, having access to the Op directly would also reduce the overhead of setting up ImageDesc() so that you can evaluate a simple op. What I left out of my last post was the suggestion that Ops should be plugins. I have a few cases like non standard transfer functions and support for calling libs like truelight or cinespace as an Op which I don't think belong in the OCS core. Cortex already has an Op for truelight which you might find interesting http://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTruelight/TruelightColorTransformOp.cpp I think having some form of extendibility at the Op level will be needed for OCS to be widely adopted. It will be hard for people to take on if they can't replicate the workflow (broken or not) they have right now. A family relates to bit-depthness, and though the concept is fullyThat feels like you could drop the extra color spaces and make that part of the Transform() or TransformGroup(). This would make a ColorSpace() define how it would be represented in/at different bit depths. colorspace(name='lgh') to_reference(bitdepth='16f') ... op chain ... to_reference(bitdepth='16ui') ... op chain ... to_reference(bitdepth='10ui') ... op chain ... ... The other option would be to make that part of the Lut1D and Lut3D Ops, ie reading different luts for different bit depths. But after thinking about it I feel the to_reference(bitdepth='16f') would be better as you most likely will need different color op chains in certain situations which would get you back into having color spaces for different bit depths. Roles (their concept) are super useful to have in production becauseI still feel this should be in OCS configuration of some kind with an small api for listing and selecting roles in the current context. I don't think a change in configuration like renaming or adding a role should require recompiling of the OCS core. Give me a kick if this feedback is too much like noise. .malcolm
|
|
OCS 0.5.8 posted
Jeremy Selan <jeremy...@...>
Version 0.5.8 (June 22 2010):
* Support for .3dl * Support for matrix ops * Code refactor (added Processors) to support gpu/cpu model * Much better error checking * Compilation support for python 2.5 * Compilation support for OSX
|
|
Re: OpenColorSpace.h feedback
Jeremy Selan <jeremy...@...>
We have started to write some of the plugins we had before for 3delight, mantra, nuke, shake and houdini & mantra for applying the ASC-CDL. At the moment they all use the same code, I was hoping to replace this with an OCS::Op::CDL() op. This I guess changes the requirements for Ops a bit, but I would like to use the same color math across client apps for the simple cases. For cases like 3delight and mantra were you just want to call a single simple Op per sample, having access to the Op directly would also reduce the overhead of setting up ImageDesc() so that you can evaluate a simple op.I still believe that ops should not be part of the external API, though I think we can offer you a simple solution. We will expose a CDLTransform (note that it will be implemented without a native CDLOp, relying on the existing MatrixOffset and Gamma Ops). Have you seen the processor class in our recent checkin? It currently has an apply(ImageDesc & img) call. We can add an additional singlePixel variant that takes a raw float *. This will make it efficient to apply your cdl per-pixel with minimal overhead. What I left out of my last post was the suggestion that Ops should be plugins. I have a few cases like non standard transfer functions and support for calling libs like truelight or cinespace as an Op which I don't think belong in the OCS core. Cortex already has an Op for truelight which you might find interestinghttp://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTru... I think having some form of extendibility at the Op level will be needed for OCS to be widely adopted. It will be hard for people to take on if they can't replicate the workflow (broken or not) they have right now.I've been thinking a lot about op plugins -- I'm really on the fence -- but my current thought it to avoid it for 1.0. First, I fear that a plugin system, not done well, will lead to a lot of user confusion. I really want OCS files to be totally portable, where you dont have to think about versions or compatibility. I can picture a lead FX house coming up with an OCS configuration not realizing it's using an optional plugin format, distributing it, and then complications arising downsteam once they've distributed the profile. There would also be a whole range of issues related to plugin binary compatibility, registration, image quality, etc. Furthermore, I've always been strongly philosophically opposed to 'locked' LUT formats, and would like to discourage their use in interchange. (Locked lut formats are all pretense anyways, if you give me an API where I can process an image, I'll guarantee you I can fish the lut out. In fact, the OCS GPU pipeline takes advantage of this approach!) For 'broken' current workflows that people need to emulate, I'd love to attack them on case-by-case basis. I'd be really surprised if even the worst workflows we need to support would rely on ops we couldn't provide base level emulation of. It's an open source project, so if someone wants to add an additional 'custom' op so their workflow can be supported, I'd prefer that. Do you have any specific examples you could provide more info on? Finally, I'm worried about feature creep. My gut tells me that this could be a can of worms, and we're short on time for 1.0 already. There's a lot of intricacies in doing a proper plugin API, and I'd rather give it the time it deserves. How does a plugin system work with an .ocs bundle file? How does it work with GPU generation? What about multi-platform plugin support? What about Op reuse? In the long term, I'm totally open to reconsidering the idea; I feel it's just a bit too much to add to our plate right now. Thanks for the feedback! -- Jeremy
|
|
Re: An OCS by any other name?
Jeremy Selan <jeremy...@...>
FYI,
We've started the process for getting legal clearance on OpenColorIO. Bonus kudos to Malcolm Humphreys for suggesting the name! -- Jeremy
|
|
Re: [ocs-dev] Re: OpenColorSpace.h feedback
Malcolm Humphreys <malcolmh...@...>
Hi Jeremy,
On 23/06/2010, at 4:55 AM, Jeremy Selan wrote: I like to keep about 3 classifications for colour operations:We have started to write some of the plugins we had before for 3delight, mantra, nuke, shake and houdini & mantra for applying the ASC-CDL. At the moment they all use the same code, I was hoping to replace this with an OCS::Op::CDL() op. This I guess changes the requirements for Ops a bit, but I would like to use the same color math across client apps for the simple cases. For cases like 3delight and mantra were you just want to call a single simple Op per sample, having access to the Op directly would also reduce the overhead of setting up ImageDesc() so that you can evaluate a simple op.I still believe that ops should not be part of the external API, - transforms (eg, matrix multiplication) - transfer functions (eg, Rec709 -> Lin) - look up tables It's cool, I just need to get used to calling all of these transforms (which arguably they are all transformations of data) not ops. Might be good to update the todo's at the top of OpenColorSpace.h so they talk about transforms not ops. We will expose aSounds ok, but I was just using that as an example of why I think it would be nice to have Ops as plugins. ie. like what units are your CDL grade parameters in? we have them set in printer points so we can integrate with other grading systems. These workflow decisions I think should be kept out of the OCS core. I really like the idea of OCS largely being a protocol for describing and communicating these transformation chains. Its going to be a huge undertaking to try and conform everyones workflow, I would really call this a 'soft' long term goal. A 'hard' goal would be having OCS integrated on all major platforms and applications, with vendors sharing .ocs profiles, luts and transform plugins. It currently has anThats a great addition. I was also just thinking that renaming ImageDesc to TileDesc would make the interface a little more obvious (completely superficially) when used inside a 3d renderer. ie. with a renderman simd plugin where you have access to an entire grid of points (which you can't in mantra), I would happily call that a tile of data not an image.. really I can live with how it is, but a suggestion none the less. I agree if you can't do it well, leave it till you can.What I left out of my last post was the suggestion that Ops should be plugins. I have a few cases like non standard transfer functions and support for calling libs like truelight or cinespace as an Op which I don't think belong in the OCS core. Cortex already has an Op for truelight which you might find interestinghttp://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTru... I think having some form of extendibility at the Op level will be needed for OCS to be widely adopted. It will be hard for people to take on if they can't replicate the workflow (broken or not) they have right now.I've been thinking a lot about op plugins -- I'm really on the fence I really want OCS files to be totally portable, where you dont have toOther than yes it's easy to fish these functions out, thats not really what I was trying to get at. I would say your adding a 4th hard goal (not in list of 3 I sent out before) to OCS. - conform all color math operations between vendors I can see this being something that works against OCS uptake in the short term at larger lead vendors where I guess you would like OCS to be used throughout the pipe. You could slightly change this to a long term soft goal for OCS, where people can replicate their current internal workflow today with ocs profiles, internal ocs transforms and with custom developed in-house transforms. This would be a huge step in the right direction, over time I would hope to see either the in-house transforms are out in the open for everyone or they go away completely. It's an open source project, so ifThats to say the company wants to open source it. All I'm trying to get at is if you support transform/op plugins you remove a potential road block for OCS uptake, which I think is this most important thing for a project like this. Do you have any specific examples youWe use a different log transfer function designed to get scene referred values from a KodakLog file. This is also used throughout the viewing workflow to encode linear values from 3D for use with film emulation like cinespace or truelight. The other is used in conjunction with this log transfer function which some people are calling 'paint' transfer. This is used to encode a linear image into a 16bit 'sRGB like' space for things like matte painting in photoshop. On the round trip it has less than one cineon code value of loss which visually you can't perceive (the slight data loss is a compromise in getting something working in photoshop, which isn't a big deal when they are painting on the frame). We also create an icc profile so people can soft proof (ie. with the film emulation) their work while also in photoshop. It's not really my decision to make any of this opensource as it might have perceived value for my employers (as they pay me to re-develop them) or some other issues. For me (and I'm guessing others) it would be great to deal with these two separately ie. - using the OCS framework to describe/apply our colour pipeline - getting vendors dealing with colour math the same Finally, I'm worried about feature creep. My gut tells me that thisI agree, presenting something that isn't 100% coherent has the potential to add more confusion. Thanks for the feedback!No problem, happy to be involved in some way. .malcolm
|
|
OpenColorIO
Jeremy Selan <jeremy...@...>
The new name is approved, OpenColorIO it is.
Both github and the google group appear to allow project renaming, please email me directly if you can't find the group again. http://groups.google.com/group/ocio-dev/
|
|
Dynamic color configuration
srluka <srl...@...>
Jeremy, what are your thoughts on supporting a color pipeline that
queries the files and/or workspace for color information and uses that information to define the transformation to the reference space on the fly, as opposed to predefining all spaces in the config.ocs? For example, most of the images we (I) encounter can described by a basic RGB model consisting of a 1d encoding function and 3x3 color matrix. If they are all white-normalized, then the 3x3 matrix reduces to 4 x,y chromaticity pairs (RGBW). If it is possible, I would like to be able to handle all images that fall into this category with a single transformation that takes in a set of image dependent color parameters, as opposed to enumerating every possible case we might encounter in the config.ocs.
|
|
Re: [ocs-dev] Dynamic color configuration
Jeremy Selan <jeremy...@...>
Stefan,
This has been brought up before (previously by Rod), and it's a great question. Thinking out loud... From a purely technological standpoint, the API required to support a dynamic color workflow is basically in place. Colorspaces can be added, deleted, and modified at runtime. The only restriction is that they need unique names, but thats an easy problem solve. (Also left is to expose all of the transforms functions you'll need, but this is easy). But... From a design standpoint this approach would have pipeline implications. Any dynamic colorspace system would likely have custom logic, and I'd have concerns about the portability of such a system. My hope is to have support for OCIO in many applications (either as plugins or natively) right out of the box, and wouldn't want supporting dynamic colorspaces to throw a wrench in this plan. So what are the possible implementations? 1) If you only rely on custom (facility specific) OCIO plugins, you could use the embed the cleverness on your end, and use the existing dynamic colorspace interface to make all the right things happen. But this approach isn't ideal, as it would require each client to have it's own implementation of the clever bits (or link against something that does), and would prevent you from utilizing built-in OCIO support in commercial apps. (Which, if OCIO succeeds, will be really convenient). 2) Put ALL the intelligence in OCIO. Currently, if you have a colorspace, you've got all you need to know about it. But... what if colorspaces could have optional arguments? In your example, you could define a single colorspace that had a section of it that was computed based on the arguments. Chromaticities in, pixel processing out. But this makes writing a generic plugin for OCIO much more difficult. Consider our nuke support. Right now we have nodes that allow for color space conversion in the comp graph, and custom read-write nodes that use our colorspace processing instead of the built-in support. The UI for both cases is essentially a list of strings (the colorspace names) What would a plugin look like that supported dynamic colorspaces arguments? The colorspace conversion node would have to support dynamic parameters, and the artist would need an interface more complicated than a popdown to deal with the (potentially optional) options. (The args data could be endoded into a single string, but this would not make it more artist friendly, probably less so). I know of a few applications that support this level of plugin interface customizability, but not many. Also, the read and write nodes would need to be more complex, as they would be required to parse the file metadata, and populate the colorspace args appropriately. Though this task is not difficult, it is facility convention specific and would require a customized plugin. But we're going to have to tackle this issue anyways. In the current SPI color system, while we don't use dynamic colorspaces (we chose to avoid this for validation reasons), we do use dynamic Display Transforms. Specifically, on visual effects shows, different shot / sequences often have different artistic looks - specified by the DI house - and it's incredibly useful to be able to plug these into our pipeline. In a concrete example, we have Filmlooks that are constant across a show, and ones that aren't. In our image viewer, you can view images with "Film" - a generic look - or "Film Onset", which is a shot varying look that encompasses onset viewing parameters as manipulated by the client. It would be great if we could support both systems (your dynamic colorspaces, and our dynamic viewing luts) with one approach. 3) Why not a hybrid system? For example, I could envision a plug-in system (which I previously denounced in a prior email), whose inputs were a bunch of information (filename, file metadata, all environment variables, etc), and a plugin had the opportunity to interpret this information in a facility specific manner, and return a dynamically constructed colorspace. Because the inputs to the custom logic were on rails, the OCIO plugins could be standardized and have a chance to work right out of the box, but there would also be a customizable API that facility specific code could be written against. And, if you had to send support for any custom part out of house, the dynamic colorspaces could always be 'baked' to a non-plugin ocs system for export. This approach also feels cleaner because it would not require anyone to agree on what the "right" mapping is (across facility, I mean). In your example, what matrix will you use for the transform? It could be a simple chromaticity mapping, but maybe some other facility would need to support different white points, and thus would require a chromic adaptation matrix. Or, maybe you're converting wide gamut P3 to r709, and gamut mapping must be considered... My point is that only *you* know about the exact situational requirements for what transform is most appropriate, so the code turning a set of primaries into an explicit set of image processing operations is must be highly configurable, and will likely be specific to the use cases you find yourself working with. Another point for the hybrid plugin approach. In terms of timeline, we're not quite at the point where I can look at implementing a potential solution. I'm in middle of getting the GPU chunk running, and after that will be paying attention to better default configurations and adding additional client app support. (which should put us near siggraph). But, after that I think it would make sense to open this back up. Is there some sort of really simple solution I'm missing? :) -- Jeremy
|
|
Re: Dynamic color configuration
Jeremy Selan <jeremy...@...>
I thought of a simpler way to summarize the topic:
In dynamic colorspaces, the color transforms are dependent upon a set of potentially changing input arguments. Our ideal solution is one where the input argument handing is standardized so that OCIO can be supported out of the box in commercial tools. But, the logic that interprets input arguments would be structured to allow the use of facility-specific code and conventions. -- Jeremy
|
|
Re: [ocs-dev] Re: Dynamic color configuration
Rod Bogart <bog...@...>
Agreed. The issue isn't how to do the conversion, it is how to
toggle quoted messageShow quoted text
determine the input arguments. But OCIO has this problem anyway. There is no definition for how a given image can help influence what conversion is used. In a commercial tool, the conversion is chosen by the user, where the list of options is everything in the config. OCIO has routines to do a conversion if the "conversion name" is provided. OCIO could easily have routines to do conversions if the gamma-matrix-gamma is provided. Either way, commercial tools have to decide if the conversion hints come from the user, the filename, the header, the environment, or whatever. RGB
On Sat, Jun 26, 2010 at 5:19 PM, Jeremy Selan <jeremy...@...> wrote:
I thought of a simpler way to summarize the topic:
|
|
ocio 0.5.9 posted
Jeremy Selan <jeremy...@...>
Version 0.5.9 (June 28 2010):
* Renamed project, classes, namespaces to OpenColorIO (OCIO) * Added single-pixel processor path * Improved python path makefile detection * Continued GPU progress (still under development)
|
|
Re: Dynamic color configuration
srluka <srl...@...>
I view these as two separate problems. One is gathering color
toggle quoted messageShow quoted text
information. The other is performing color transforms. OCIO seems to be focused on the latter. I would like to see the OCIO API stay open enough to where we can use its color transform capability outside the confines of a fixed color pipeline. The hybrid approach Jeremy described may be just what we are looking for. Another thing I would like to maintain the option for, and that was hinted at in Jeremy's first response, is different mappings between color spaces. As an example, when converting two RGB spaces with different white points you have the option of preserving absolute colorimetry or performing some form of chromatic adaptation. With a static configuration, it seems like you have to pick one or the other since each half of the conversion is built into the color space definition. So you either have a chromatically adapted workflow, or you don't. Also, it's a little weird in the sense that the chromatic adaptation (if you were to use it) would have to be already built into each colorspace definition (ICC D50 anyone? or maybe you would prefer ACES D60?) but it may not be explicitly stated. I think this may be problematic so long as the colorspaces define the halfway conversion to the reference ("linear") space. There may need to be some additional option for defining the connection space if we expect to use anything other than a straightforward colorimetric transform.
On Jun 28, 10:44 am, Rod Bogart <bog...@...> wrote:
Agreed. The issue isn't how to do the conversion, it is how to
|
|
OCIO @ Siggraph
Jeremy Selan <jeremy...@...>
Friends,
So Siggraph is just around the corner, which means OpenColorIO is going public! Both this google group, as well as the git repo are now completely open to all. If you're attending Siggraph, please come check us out: Course: Color Enhancement and Rendering in Film and Game Production TUESDAY, 27 JULY | 9:00 AM - 12:15 PM | ROOM 502 A (my presentation time is tentatively 9:55 - 10:15, a portion of which i'll use to introduce OpenColorIO). Birds of a Feather : OpenColorIO WEDNESDAY, 28 JULY | 2:30 PM - 3:30 PM | ROOM 506 This will be a more informal, in depth look at OCIO and it's roadmap / integration schedule. Imageworks will also have an official OCIO press-release on Monday. If you're not able to make either of these, but are still interested in talking in person, please contact me personally. My schedule is flexible, and I'd love to meet everyone interested in this subject. Also - not related to OCIO - but for those interested in open source projects I'd highly recommend checking out: Panel: Large Steps Toward Open Source THURSDAY, 29 JULY | 9:00 AM - 10:30 AM | ROOM 408 AB The speaker are excellent, representing such graphics projects as OSL, Alembic, OpenEXR, PTex, etc. Cheers, Jeremy
|
|
Supporting 1D luts which are different per channel
Malcolm Humphreys <malcolmh...@...>
Hi,
I started looking at adding csp lut format to ocio. A csp lut allows a 1D prelut with a different number of points per channel. The current Lut1DOp only supports applying the same 1D lut to all channels. I'm wondering if this is something you were thinking of supporting in ocio? --snip-- Access LUT data via a gamma lookup Red channel has gamma 2.0 Green channel has gamma 3.0 but also has fewer points Blue channel has gamma 2.0 but also has fewer points 11 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 0.0 0.01 0.04 0.09 0.16 0.25 0.36 0.49 0.64 0.81 1.0 6 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.008 0.064 0.216 0.512 1.0 6 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.04 0.16 0.36 0.64 1.0 --snip-- .malcolm
|
|