Date   

Re: State of OCIO development re: CPU/GPU mismatches

Troy Sobotka <troy.s...@...>
 

Serious question, why not just publicly do a fork, and maintain it in the short term until the stewardship side of the official repository becomes clearer? At that point, the fork can be merged and everything carry on forward. If stewardship remains stuck, then the fork carries forward.

It seems win-win in this instance.

With respect,
TJS


On Wed, Sep 7, 2016, 9:55 PM Nathan Rusch <natha...@...> wrote:
Thanks for the information Dennis.

If we do end up trying to tackle the OpenGL code path ourselves, I would definitely be interested in the idea of using your changes as a starting point, and an OpenCL code path sounds like it could be an interesting addition to OCIO by itself anyway. I also wonder if the RV developers would be at all interested in taking a look at them.

Are those changes the kind of thing you would potentially be willing to share directly, rather than requiring them to be merged with the main repo first? I ask because the radio silence around the project is starting to get a little unnerving.

Thanks,

-Nathan



On Thursday, September 8, 2016 at 8:19:52 AM UTC+10, Dennis Adams wrote:
This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations (especially ACES when both 2D and 3D LUTs are being used).

We fixed this for our GPU processing pipeline and we were working on contributing it back to OCIO, but that effort got stalled (and it doesn't seem like there is anyone to take the pull request anyway). I'd like to gauge interest in what we did so we can determine if we should restart that effort. We added the ability to generate OpenCL 1.1 kernels which have the same processing steps as the CPU path and therefore produce very similar results (within numerical and math function accuracy). Benchmarked across a set of sample transformations it is, on average, 100x faster than the CPU path (ranging from 19x to 636x for the two dozen ACES transformations tested). However, our implementation is only beneficial to those using OpenCL, which is why I'm asking about interest. Notably, the technique we created could be for an accurate OpenGL path by someone needing OpenGL shaders instead of OpenCL kernels, and is only slightly more complicated for the caller than the existing GPU path, so even if you're not using OpenCL but are interested in an accurate OpenGL path, it would be a good starting point.

///d@
Dennis Adams
Sony Creative Software

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: State of OCIO development re: CPU/GPU mismatches

Nathan Rusch <natha...@...>
 

Thanks for the information Dennis.

If we do end up trying to tackle the OpenGL code path ourselves, I would definitely be interested in the idea of using your changes as a starting point, and an OpenCL code path sounds like it could be an interesting addition to OCIO by itself anyway. I also wonder if the RV developers would be at all interested in taking a look at them.

Are those changes the kind of thing you would potentially be willing to share directly, rather than requiring them to be merged with the main repo first? I ask because the radio silence around the project is starting to get a little unnerving.

Thanks,

-Nathan


On Thursday, September 8, 2016 at 8:19:52 AM UTC+10, Dennis Adams wrote:
This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations (especially ACES when both 2D and 3D LUTs are being used).

We fixed this for our GPU processing pipeline and we were working on contributing it back to OCIO, but that effort got stalled (and it doesn't seem like there is anyone to take the pull request anyway). I'd like to gauge interest in what we did so we can determine if we should restart that effort. We added the ability to generate OpenCL 1.1 kernels which have the same processing steps as the CPU path and therefore produce very similar results (within numerical and math function accuracy). Benchmarked across a set of sample transformations it is, on average, 100x faster than the CPU path (ranging from 19x to 636x for the two dozen ACES transformations tested). However, our implementation is only beneficial to those using OpenCL, which is why I'm asking about interest. Notably, the technique we created could be for an accurate OpenGL path by someone needing OpenGL shaders instead of OpenCL kernels, and is only slightly more complicated for the caller than the existing GPU path, so even if you're not using OpenCL but are interested in an accurate OpenGL path, it would be a good starting point.

///d@
Dennis Adams
Sony Creative Software


Re: State of OCIO development re: CPU/GPU mismatches

Dithermaster <dither...@...>
 

This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations (especially ACES when both 2D and 3D LUTs are being used).

We fixed this for our GPU processing pipeline and we were working on contributing it back to OCIO, but that effort got stalled (and it doesn't seem like there is anyone to take the pull request anyway). I'd like to gauge interest in what we did so we can determine if we should restart that effort. We added the ability to generate OpenCL 1.1 kernels which have the same processing steps as the CPU path and therefore produce very similar results (within numerical and math function accuracy). Benchmarked across a set of sample transformations it is, on average, 100x faster than the CPU path (ranging from 19x to 636x for the two dozen ACES transformations tested). However, our implementation is only beneficial to those using OpenCL, which is why I'm asking about interest. Notably, the technique we created could be for an accurate OpenGL path by someone needing OpenGL shaders instead of OpenCL kernels, and is only slightly more complicated for the caller than the existing GPU path, so even if you're not using OpenCL but are interested in an accurate OpenGL path, it would be a good starting point.

///d@
Dennis Adams
Sony Creative Software


On Wed, Sep 7, 2016 at 11:02 AM, Deke Kincaid <dekek...@...> wrote:
Without tetrahedral interpolation you can get better results by creating 65x cubes instead of the default of 32x that the example OCIO configs use (very easy to create with Hp's python script included with the ACES configs).  It's still not as good as tetrahedral interpolation but it is close enough for gpu playback.  Kevin Wheatley had some good slides & charts on this from his ACES presentation at Digipro if you have an ACM account.

A Retrospective on the Adoption of the ACES Technology at Framestore 
http://dl.acm.org/citation.cfm?id=2947695

-deke

On Wednesday, September 7, 2016, DBR - Ben <dbr....@...> wrote:
I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even simple pull requests unacknowledged)

If there is development happening, that is good.. but as one of the previously more active contributors to the project, it would sadden me the project has moved away from the "open-development" approach which encouraged me to contribute in the first place

(there was a nice part in one of the slides of an early OCIO presentation - http://www.tdforum.eu/pdf/2011ntfd_ocio_selan.pdf - "We really do our development in public/We’ve made some embarrassing mistakes/Integrity, not fear/Airing dirty laundry breeds trust amongst community")

Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code

If the problem is as I suspect (mentioned in linked ticket #394 - there is no tetrahedral interpolation in GPU code path) - I suspect the the reasons people seem so quiet about the issue are numerous.. In addition to the options you describe, also:

- I would imagine some footage is more prone than others to highlighting the issue (so depending on the project and how the footage is processed, people might just not notice)
- we heavily rely on RV's GPU path without encountering this issue, using a config based of the ACES 1.0.1 config, but with a custom simpler viewing transform which presumably avoids this issue
- a common theme in that ticket comment was people found a workaround (like baking out intermediate LUT's), which lessens the need to "make noise" about the issue


On 7 September 2016 at 19:21, Nathan Rusch <natha...@...> wrote:
Hello all,

This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide.

Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files.

Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse.

At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code.

Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging.

Thanks,


-Nathan

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


State of OCIO development re: CPU/GPU mismatches

Deke Kincaid <dekek...@...>
 

Without tetrahedral interpolation you can get better results by creating 65x cubes instead of the default of 32x that the example OCIO configs use (very easy to create with Hp's python script included with the ACES configs).  It's still not as good as tetrahedral interpolation but it is close enough for gpu playback.  Kevin Wheatley had some good slides & charts on this from his ACES presentation at Digipro if you have an ACM account.

A Retrospective on the Adoption of the ACES Technology at Framestore 

On Wednesday, September 7, 2016, DBR - Ben <dbr....@...> wrote:
I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even simple pull requests unacknowledged)

If there is development happening, that is good.. but as one of the previously more active contributors to the project, it would sadden me the project has moved away from the "open-development" approach which encouraged me to contribute in the first place

(there was a nice part in one of the slides of an early OCIO presentation - http://www.tdforum.eu/pdf/2011ntfd_ocio_selan.pdf - "We really do our development in public/We’ve made some embarrassing mistakes/Integrity, not fear/Airing dirty laundry breeds trust amongst community")

Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code

If the problem is as I suspect (mentioned in linked ticket #394 - there is no tetrahedral interpolation in GPU code path) - I suspect the the reasons people seem so quiet about the issue are numerous.. In addition to the options you describe, also:

- I would imagine some footage is more prone than others to highlighting the issue (so depending on the project and how the footage is processed, people might just not notice)
- we heavily rely on RV's GPU path without encountering this issue, using a config based of the ACES 1.0.1 config, but with a custom simpler viewing transform which presumably avoids this issue
- a common theme in that ticket comment was people found a workaround (like baking out intermediate LUT's), which lessens the need to "make noise" about the issue


On 7 September 2016 at 19:21, Nathan Rusch <natha...@...> wrote:
Hello all,

This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide.

Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files.

Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse.

At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code.

Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging.

Thanks,


-Nathan

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: State of OCIO development re: CPU/GPU mismatches

DBR - Ben <dbr....@...>
 

I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even simple pull requests unacknowledged)

If there is development happening, that is good.. but as one of the previously more active contributors to the project, it would sadden me the project has moved away from the "open-development" approach which encouraged me to contribute in the first place

(there was a nice part in one of the slides of an early OCIO presentation - http://www.tdforum.eu/pdf/2011ntfd_ocio_selan.pdf - "We really do our development in public/We’ve made some embarrassing mistakes/Integrity, not fear/Airing dirty laundry breeds trust amongst community")

Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code

If the problem is as I suspect (mentioned in linked ticket #394 - there is no tetrahedral interpolation in GPU code path) - I suspect the the reasons people seem so quiet about the issue are numerous.. In addition to the options you describe, also:

- I would imagine some footage is more prone than others to highlighting the issue (so depending on the project and how the footage is processed, people might just not notice)
- we heavily rely on RV's GPU path without encountering this issue, using a config based of the ACES 1.0.1 config, but with a custom simpler viewing transform which presumably avoids this issue
- a common theme in that ticket comment was people found a workaround (like baking out intermediate LUT's), which lessens the need to "make noise" about the issue


On 7 September 2016 at 19:21, Nathan Rusch <natha...@...> wrote:
Hello all,

This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide.

Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files.

Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse.

At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code.

Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging.

Thanks,


-Nathan

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


State of OCIO development re: CPU/GPU mismatches

Nathan Rusch <natha...@...>
 

Hello all,

This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide.

Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files.

Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse.

At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code.

Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging.

Thanks,


-Nathan


Re: ImageBufAlgo make_texture colorspace change

er...@...
 

I didn't check for ok in the code snippet I provided, but ok is True, and colorBuf.geterror() returns an empty string.


On Saturday, August 20, 2016 at 9:36:18 AM UTC-7, Larry Gritz wrote:
On Aug 19, 2016, at 11:38 PM, er...@... wrote:

 Still, I wish there was an error or a warning telling me I'm using colorspace names that don't exist. 


There is, you just weren't checking it:


import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
ok = OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
if not ok :
    print colorBuf.geterror()
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


--
Larry Gritz
l....@...



Re: ImageBufAlgo make_texture colorspace change

Larry Gritz <l...@...>
 

On Aug 19, 2016, at 11:38 PM, er...@... wrote:

 Still, I wish there was an error or a warning telling me I'm using colorspace names that don't exist. 


There is, you just weren't checking it:


import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
ok = OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
if not ok :
    print colorBuf.geterror()
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


--
Larry Gritz
l...@...



Re: ImageBufAlgo make_texture colorspace change

er...@...
 

I don't know where the ocio config could be coming from since I don't have an OCIO environment variable set, and I couldn't find any config files. When I run oiiotool --help it shows at the bottom:
 Known color spaces: "raw" (linear)                    
 Known displays: "sRGB"* (views: "Raw"*) (* = default) 
I was able to fix the problem by going to the OCIO website and downloading the default config files they provide. Then I set the OCIO environment variable to the Nuke config file. Still, I wish there was an error or a warning telling me I'm using colorspace names that don't exist. Or a way to find out what config file is being referenced.
Thank you Larry and Deke. I couldn't have figured this out without you.


On Friday, August 19, 2016 at 10:10:06 PM UTC-7, Larry Gritz wrote:
In OIIO 1.6, if OCIO is disabled (support not compiled at build time, or no OCIO configuration file is found at runtime), all it knows how to do is convert between sRGB or Rec709 and linear.

BUT... if OCIO support is compiled in and a config is found at build time, it 100% relies on OCIO for color space conversions, so if you use color space names not recognized by your OCIO config, it doesn't transform the values. 

I suspect that this is what's happening. You have an OCIO config file somewhere? (Presumably? Or else you probably wouldn't be asking about this on ocio-dev?)

If this is correct, I believe you have four choices:

* Use color space names corresponding to color spaces in your active OCIO config.

* Switch to an OCIO config that contains the color spaces you want to transform among.

* Disable OCIO by removing any config files and/or making sure you don't have an "OCIO" environment variable.

* Switch to OIIO master branch (the in-development 1.7 of the future), which has changed the behavior so that if OCIO doesn't recognize the color space names, it will still fall back on its inherent knowledge of sRGB <-> linear conversion. (This is not uncontroversial! But I think it's the common-sense thing to do.)


On Aug 19, 2016, at 7:14 PM, er...@... wrote:

I'm using OpenImageIO-1.6.14-cp27-cp27m-win_amd64.whl which I downloaded from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ . I found it too much of a pain to build the source for Windows. This didn't come with a config.ocio file, but I saw in the documentation: "If OCIO is not enabled (or cannot find a valid configuration, OIIO will at least be able to convert among linear, sRGB, and Rec709." 

I ran the oiiotool commands Larry suggested. 
For gray.tif,I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

For gray.exr, I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

So there is something wrong, but I don't know how to fix it.

On Friday, August 19, 2016 at 9:38:13 AM UTC-7, Larry Gritz wrote:
Phrases like "looks lighter in Nuke" always make me suspicious, there are too many ways things can go wrong.

Let's start from first principles.

oiiotool -pattern fill:color=.5,.5,.5 256x256 3 -o gray.tif
oiiotool -stats gray.tif

That should report min/max/average all 0.5.

Now run your conversion script on gray.tif, and 'oiiotool -stats' the resulting exr. What is the value? It *should* be 0.214041 everywhere if the conversion happened properly. If that is the case, then the problem is about how it is read or displays in Nuke.

There was a time when OIIO would, in cases where an OCIO config found, have color conversions *only* depend on OCIO. Color names that were not installed color spaces in your OCIO configuration would be errors and no color transformation would happen. If your output exr has values 0.5, that's probably the problem -- your OCIO configuration simply has no sRGB or linear color spaces defined.

IIRC, newer OIIO actually is a little smarter, in that if an OCIO exists but doesn't know how to do the requested transformation, it will see if the conversion is one of a few that it knows how to do regardless, and sRGB <-> linear is among them. But it needs to be a relatively recent OIIO for it to do that, if OCIO doesn't define those spaces.


On Aug 18, 2016, at 5:47 PM, er...@... wrote:

Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf = ImageBuf(src_path)
config = OpenImageIO.ImageSpec()
config.attribute('maketx:incolorspace', 'sRGB')
config.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-d...@....
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l....@...



--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l....@...



Re: ImageBufAlgo make_texture colorspace change

Larry Gritz <l...@...>
 

In OIIO 1.6, if OCIO is disabled (support not compiled at build time, or no OCIO configuration file is found at runtime), all it knows how to do is convert between sRGB or Rec709 and linear.

BUT... if OCIO support is compiled in and a config is found at build time, it 100% relies on OCIO for color space conversions, so if you use color space names not recognized by your OCIO config, it doesn't transform the values. 

I suspect that this is what's happening. You have an OCIO config file somewhere? (Presumably? Or else you probably wouldn't be asking about this on ocio-dev?)

If this is correct, I believe you have four choices:

* Use color space names corresponding to color spaces in your active OCIO config.

* Switch to an OCIO config that contains the color spaces you want to transform among.

* Disable OCIO by removing any config files and/or making sure you don't have an "OCIO" environment variable.

* Switch to OIIO master branch (the in-development 1.7 of the future), which has changed the behavior so that if OCIO doesn't recognize the color space names, it will still fall back on its inherent knowledge of sRGB <-> linear conversion. (This is not uncontroversial! But I think it's the common-sense thing to do.)


On Aug 19, 2016, at 7:14 PM, er...@... wrote:

I'm using OpenImageIO-1.6.14-cp27-cp27m-win_amd64.whl which I downloaded from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ . I found it too much of a pain to build the source for Windows. This didn't come with a config.ocio file, but I saw in the documentation: "If OCIO is not enabled (or cannot find a valid configuration, OIIO will at least be able to convert among linear, sRGB, and Rec709." 

I ran the oiiotool commands Larry suggested. 
For gray.tif,I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

For gray.exr, I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

So there is something wrong, but I don't know how to fix it.

On Friday, August 19, 2016 at 9:38:13 AM UTC-7, Larry Gritz wrote:
Phrases like "looks lighter in Nuke" always make me suspicious, there are too many ways things can go wrong.

Let's start from first principles.

oiiotool -pattern fill:color=.5,.5,.5 256x256 3 -o gray.tif
oiiotool -stats gray.tif

That should report min/max/average all 0.5.

Now run your conversion script on gray.tif, and 'oiiotool -stats' the resulting exr. What is the value? It *should* be 0.214041 everywhere if the conversion happened properly. If that is the case, then the problem is about how it is read or displays in Nuke.

There was a time when OIIO would, in cases where an OCIO config found, have color conversions *only* depend on OCIO. Color names that were not installed color spaces in your OCIO configuration would be errors and no color transformation would happen. If your output exr has values 0.5, that's probably the problem -- your OCIO configuration simply has no sRGB or linear color spaces defined.

IIRC, newer OIIO actually is a little smarter, in that if an OCIO exists but doesn't know how to do the requested transformation, it will see if the conversion is one of a few that it knows how to do regardless, and sRGB <-> linear is among them. But it needs to be a relatively recent OIIO for it to do that, if OCIO doesn't define those spaces.


On Aug 18, 2016, at 5:47 PM, er...@... wrote:

Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf = ImageBuf(src_path)
config = OpenImageIO.ImageSpec()
config.attribute('maketx:incolorspace', 'sRGB')
config.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l....@...



--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@...



Re: ImageBufAlgo make_texture colorspace change

er...@...
 

I'm using OpenImageIO-1.6.14-cp27-cp27m-win_amd64.whl which I downloaded from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ . I found it too much of a pain to build the source for Windows. This didn't come with a config.ocio file, but I saw in the documentation: "If OCIO is not enabled (or cannot find a valid configuration, OIIO will at least be able to convert among linear, sRGB, and Rec709." 

I ran the oiiotool commands Larry suggested. 
For gray.tif,I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

For gray.exr, I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

So there is something wrong, but I don't know how to fix it.


On Friday, August 19, 2016 at 9:38:13 AM UTC-7, Larry Gritz wrote:
Phrases like "looks lighter in Nuke" always make me suspicious, there are too many ways things can go wrong.

Let's start from first principles.

oiiotool -pattern fill:color=.5,.5,.5 256x256 3 -o gray.tif
oiiotool -stats gray.tif

That should report min/max/average all 0.5.

Now run your conversion script on gray.tif, and 'oiiotool -stats' the resulting exr. What is the value? It *should* be 0.214041 everywhere if the conversion happened properly. If that is the case, then the problem is about how it is read or displays in Nuke.

There was a time when OIIO would, in cases where an OCIO config found, have color conversions *only* depend on OCIO. Color names that were not installed color spaces in your OCIO configuration would be errors and no color transformation would happen. If your output exr has values 0.5, that's probably the problem -- your OCIO configuration simply has no sRGB or linear color spaces defined.

IIRC, newer OIIO actually is a little smarter, in that if an OCIO exists but doesn't know how to do the requested transformation, it will see if the conversion is one of a few that it knows how to do regardless, and sRGB <-> linear is among them. But it needs to be a relatively recent OIIO for it to do that, if OCIO doesn't define those spaces.


On Aug 18, 2016, at 5:47 PM, er...@... wrote:

Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf = ImageBuf(src_path)
config = OpenImageIO.ImageSpec()
config.attribute('maketx:incolorspace', 'sRGB')
config.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l....@...



Re: ImageBufAlgo make_texture colorspace change

Larry Gritz <l...@...>
 

Phrases like "looks lighter in Nuke" always make me suspicious, there are too many ways things can go wrong.

Let's start from first principles.

oiiotool -pattern fill:color=.5,.5,.5 256x256 3 -o gray.tif
oiiotool -stats gray.tif

That should report min/max/average all 0.5.

Now run your conversion script on gray.tif, and 'oiiotool -stats' the resulting exr. What is the value? It *should* be 0.214041 everywhere if the conversion happened properly. If that is the case, then the problem is about how it is read or displays in Nuke.

There was a time when OIIO would, in cases where an OCIO config found, have color conversions *only* depend on OCIO. Color names that were not installed color spaces in your OCIO configuration would be errors and no color transformation would happen. If your output exr has values 0.5, that's probably the problem -- your OCIO configuration simply has no sRGB or linear color spaces defined.

IIRC, newer OIIO actually is a little smarter, in that if an OCIO exists but doesn't know how to do the requested transformation, it will see if the conversion is one of a few that it knows how to do regardless, and sRGB <-> linear is among them. But it needs to be a relatively recent OIIO for it to do that, if OCIO doesn't define those spaces.


On Aug 18, 2016, at 5:47 PM, er...@... wrote:

Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf = ImageBuf(src_path)
config = OpenImageIO.ImageSpec()
config.attribute('maketx:incolorspace', 'sRGB')
config.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@...



Re: ImageBufAlgo make_texture colorspace change

Larry Gritz <l...@...>
 

Also, which version of OIIO?


On Aug 18, 2016, at 7:51 PM, Deke Kincaid <dekek...@...> wrote:

It depends on the colorspaces defined in your config.ocio file set by your $OCIO environment variable.  Which profile are you using from the examples or did you roll your own?

On Thu, Aug 18, 2016 at 5:47 PM, <er...@...> wrote:
Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf = ImageBuf(src_path)
config = OpenImageIO.ImageSpec()
config.attribute('maketx:incolorspace', 'sRGB')
config.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@...



Re: ImageBufAlgo make_texture colorspace change

Deke Kincaid <dekek...@...>
 

It depends on the colorspaces defined in your config.ocio file set by your $OCIO environment variable.  Which profile are you using from the examples or did you roll your own?

On Thu, Aug 18, 2016 at 5:47 PM, <er...@...> wrote:
Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf
= ImageBuf(src_path)
config
= OpenImageIO.ImageSpec()
config
.attribute('maketx:incolorspace', 'sRGB')
config
.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf
= ImageBuf(src_path)
colorBuf
= ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


ImageBufAlgo make_texture colorspace change

er...@...
 

Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf
= ImageBuf(src_path)
config
= OpenImageIO.ImageSpec()
config
.attribute('maketx:incolorspace', 'sRGB')
config
.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf
= ImageBuf(src_path)
colorBuf
= ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.


Re: 6th annual Open Source VFX Beer of a Feather

Larry Gritz <l...@...>
 

Wednesday July *27*

Sorry for the mixup.



On Jul 19, 2016, at 10:24 AM, Larry Gritz <l...@...> wrote:

6th annual Open Source VFX Beer of a Feather

For those of you attending SIGGRAPH 2016 in Anaheim, we will be once again holding an event for developers and users of VFX-specific open source projects. It's a great chance to meet the people on the other end of the mail lists!

When: Wed. July 26, 2016, 5-7pm <----- yes, a little on the early side

Where: OC Brewhouse
Hyatt Regency Orange County <----- NOT "Hyatt Place"
11999 Harbor Blvd.

How: Sponsors have charged up a tab, and we'll be able to get drinks and hors d'oeuvre until the funding pool runs out (after which you're welcome to stay and buy your own drinks). With proper food and drink in hand, relax and enjoy the company of your fellow open source developers.

Your generous sponsors:

ACES (Academy Color Encoding System)
Ahead.IO
Autodesk
DigitalFish
Double Negative
DreamWorks Animation
Industrial Light & Magic
Luma Pictures
Method Studios
Pixar Animation Studios
Sony Pictures Imageworks
Walt Disney Animation Studios
Weta Digital

Please direct questions to: lg AT imageworks DOT com

Please feel free to forward to your developers and the appropriate mail lists for other open source VFX projects you participate in.

Also, if your organization is not one of the sponsors but you'd like to be, contact LG and there's certainly time to help charge up a bigger tab (no contribution is too small).


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
--
Larry Gritz
l...@...


6th annual Open Source VFX Beer of a Feather

Larry Gritz <l...@...>
 

6th annual Open Source VFX Beer of a Feather

For those of you attending SIGGRAPH 2016 in Anaheim, we will be once again holding an event for developers and users of VFX-specific open source projects. It's a great chance to meet the people on the other end of the mail lists!

When: Wed. July 26, 2016, 5-7pm <----- yes, a little on the early side

Where: OC Brewhouse
Hyatt Regency Orange County <----- NOT "Hyatt Place"
11999 Harbor Blvd.

How: Sponsors have charged up a tab, and we'll be able to get drinks and hors d'oeuvre until the funding pool runs out (after which you're welcome to stay and buy your own drinks). With proper food and drink in hand, relax and enjoy the company of your fellow open source developers.

Your generous sponsors:

ACES (Academy Color Encoding System)
Ahead.IO
Autodesk
DigitalFish
Double Negative
DreamWorks Animation
Industrial Light & Magic
Luma Pictures
Method Studios
Pixar Animation Studios
Sony Pictures Imageworks
Walt Disney Animation Studios
Weta Digital

Please direct questions to: lg AT imageworks DOT com

Please feel free to forward to your developers and the appropriate mail lists for other open source VFX projects you participate in.

Also, if your organization is not one of the sponsors but you'd like to be, contact LG and there's certainly time to help charge up a bigger tab (no contribution is too small).


Building problems on osx 10.11

Ben De Luca <bde...@...>
 

Hi,
I am building on osx 10.11 and receive the following error at
compile time building 1.0.9 from here
https://github.com/imageworks/OpenColorIO/archive/v1.0.9.tar.gz

In file included from
/tmp/extract/tmpKUwr7l/OpenColorIO-1.0.9/src/core/AllocationOp.cpp:29:
In file included from
/tmp/extract/tmpKUwr7l/OpenColorIO-1.0.9/src/core/AllocationOp.h:33:
In file included from
/tmp/extract/tmpKUwr7l/OpenColorIO-1.0.9/export/OpenColorIO/OpenColorIO.h:38:
/var/folders/h8/9ghw01cx65ldhgwpk9scbp480000gn/T/tmpBN8ZlT/export/OpenColorABI.h:59:10:
fatal error: 'tr1/memory' file not found
#include <tr1/memory>

Before I look further has any one come across it? I couldn't find
any references on the list. I imagine the home brew folks have hit it
and will look there.


Re: OpenColorIO stewardship

nick....@...
 

Hi,

On Tuesday, March 8, 2016 at 4:33:21 PM UTC-8, Mark Boorer wrote:

The current re-factoring work is regrettably still not finished, as my other day-to-day production tasks at DNeg have become more pressing of late. I have some time for dev work booked out in the coming weeks though, so hopefully I will have something more to show soon. My greater goal is to have everything out, feedback gathered, and tested before the SIGGRAPH 2016 deadline in order to make the changes available in the VFX platform for 2017.

We are in the process of publishing the draft VFX Reference Platform for CY2017 so please can you give an update on when you expect this next release to drop and, if it's in time for vendors to incorporate into their 2017 releases, what version number it's likely to be released under so we can include it.

Thanks,

Nick

 


Re: proper FileTransform usage

Paul Miller <pa...@...>
 

On 3/8/2016 7:01 PM, Mark Boorer wrote:
Hi Paul,

When you say your FileTransform results differ from Nuke's, is this from
using a Vectorfield node, or an OCIO FileTransform node, or perhaps an
OCIO Display node entirely? Also what format of LUT are you using?

(I'd also recommend using INTERP_TETRAHEDRAL where possible)
Actually, what we found was creating an actual OCIO config out of the LUT file transform produced the proper results. Not entirely sure what the actual difference is under the cover.

761 - 780 of 2233