Re: how to write .cube luts?

Dithermaster <dither...@...>

Yes. The RGB input value range to an OCIO 3D LUT is always 0.0--1.0. Those values get mapped to the LUT indexes (0 to 64 for a 65x65x65, or 0 to 32 for 33x33x33, or 0 to 63 for 64x64x64, etc.). The fractional (in-between) parts are used to interpolate the output values.

On Fri, Jul 13, 2018 at 10:22 PM <michael...@...> wrote:
Thank you. I hope I understand correctly, that rgb(0.1, 0.2, 0.3) in your example is not drawn from the range rgb(0-255, 0-255, 0-255) [because then, say rgb(255, 255, 255) would be mapped to the impossible (255*63, 255*63, 255*63)] but instead rgb(0.1, 0.2, 0.3) is drawn from the range rgb(0.0-1.0, 0.0-1.0, 0.0-1.0), such that 0.0 means 0/63 and 1.0 means 63/63. What else could it be? I'm surprised it's been so difficult to find info on how to write .cube lut files. Is there a reference book or article you can recommend? I'd like to know everything about luts. My searches have been frustrating, as I mentioned, so you've really been a big help. Thanks again!

On Wednesday, June 27, 2018 at 1:58:18 PM UTC-4, Dennis Adams wrote:
How does a 3D LUT work? Each numeric row has three entries, which represent R, G, and B output values, often 0.0 to 1.0 (but could be higher or negative for some cases).
Each row represents a position in the 64x64x64 input cube. The input R,G,B value (sometimes after running through a lg2 "shaper" if it is linear) gets multiplied by 63 (in the case of a 64x64x64 cube) and rounded to the nearest integer. Then the row number of r*64*64 + g*64 + b. For example, input of rgb={0.1, 0.2, 0.3} becomes rgb_index={6.3, 12.6, 18.9} which become rgb_index_int={6, 13, 19} which is row index 6*64*64 + 13*64 + 19 = 25427, if you are looking for the nearest element. It's actually more complex than that since tri-linear or tetrahedral interpolation is used, which means 8 or 4 elements surrounding the 3D position are looked up and interpolated to create the output RGB value.

///d@

On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
I've been searching for weeks and can't find a clear explanation of how

I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?

Thanks.

--
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...@....

--
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...@....

Re: how to write .cube luts?

michael...@...

Thank you. I hope I understand correctly, that rgb(0.1, 0.2, 0.3) in your example is not drawn from the range rgb(0-255, 0-255, 0-255) [because then, say rgb(255, 255, 255) would be mapped to the impossible (255*63, 255*63, 255*63)] but instead rgb(0.1, 0.2, 0.3) is drawn from the range rgb(0.0-1.0, 0.0-1.0, 0.0-1.0), such that 0.0 means 0/63 and 1.0 means 63/63. What else could it be? I'm surprised it's been so difficult to find info on how to write .cube lut files. Is there a reference book or article you can recommend? I'd like to know everything about luts. My searches have been frustrating, as I mentioned, so you've really been a big help. Thanks again!

On Wednesday, June 27, 2018 at 1:58:18 PM UTC-4, Dennis Adams wrote:
How does a 3D LUT work? Each numeric row has three entries, which represent R, G, and B output values, often 0.0 to 1.0 (but could be higher or negative for some cases).
Each row represents a position in the 64x64x64 input cube. The input R,G,B value (sometimes after running through a lg2 "shaper" if it is linear) gets multiplied by 63 (in the case of a 64x64x64 cube) and rounded to the nearest integer. Then the row number of r*64*64 + g*64 + b. For example, input of rgb={0.1, 0.2, 0.3} becomes rgb_index={6.3, 12.6, 18.9} which become rgb_index_int={6, 13, 19} which is row index 6*64*64 + 13*64 + 19 = 25427, if you are looking for the nearest element. It's actually more complex than that since tri-linear or tetrahedral interpolation is used, which means 8 or 4 elements surrounding the 3D position are looked up and interpolated to create the output RGB value.

///d@

On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
I've been searching for weeks and can't find a clear explanation of how

I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?

Thanks.

--
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.

Re: Homebrew version of OCIO not bringing all apps ...

jordi...@...

Plus now that I am trying to re-install so I can get ocioconvert I find myself with a build problem... attached.

On Wednesday, 4 July 2018 06:38:17 UTC+1, Peter wrote:
+1 for #1
It would be nice for OCIO to provide optionally built drop-in replacements for ocioconvert, ociolutimage etc as lightweight wrappers around oiiotool which map the command line arguments. Again, there'd be a runtime-only dependency on OIIO but it would prevent pipeline nightmares that happen when tools disappear between versions.

From: Deke Kincaid <deke...@...>
Sent: Wednesday, July 4, 2018 5:12 PM
To: oci...@...
Subject: Re: [ocio-dev] Homebrew version of OCIO not bringing all apps ...

I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.

So I vote for #1.

On Tue, Jul 3, 2018 at 5:01 PM Larry Gritz <l....@...> wrote:
The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?

The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?

#3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.

On Jul 3, 2018, at 3:37 PM, Liam <liam...@...> wrote:

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam

On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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...@....

--
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.

--
Larry Gritz

--
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.

--
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.

Re: Homebrew version of OCIO not bringing all apps ...

jordi...@...

Agreed, at the moment I have a couple of dependencies with the ocioconvert executable and the current situation is quite disruptive.

+1

jb

On Wednesday, 4 July 2018 06:38:17 UTC+1, Peter wrote:
+1 for #1
It would be nice for OCIO to provide optionally built drop-in replacements for ocioconvert, ociolutimage etc as lightweight wrappers around oiiotool which map the command line arguments. Again, there'd be a runtime-only dependency on OIIO but it would prevent pipeline nightmares that happen when tools disappear between versions.

From: Deke Kincaid <deke...@...>
Sent: Wednesday, July 4, 2018 5:12 PM
To: oci...@...
Subject: Re: [ocio-dev] Homebrew version of OCIO not bringing all apps ...

I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.

So I vote for #1.

On Tue, Jul 3, 2018 at 5:01 PM Larry Gritz <l....@...> wrote:
The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?

The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?

#3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.

On Jul 3, 2018, at 3:37 PM, Liam <liam...@...> wrote:

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam

On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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...@....

--
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.

--
Larry Gritz

--
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.

--
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.

Blake Sloan <bsl...@...>

Because of Deke's point that some applications for lut images require other 8-bit formats, I like 1 and 3.

My pitch in favor of #1 is that anyone using ociolutimage already has a build of OIIO somewhere (because of the build/runtime dependency). So it would seem that changing ociolutimage's parent package to OIIO would not require any significant changes to existing pipelines.

-blake

On Jul 4, 2018 1:41 PM, <ocio...@...> wrote:
Topic digest
 bsloan : Jul 03 02:06PM -0700 Re. the cyclic (two-way?) dependency between openimageio and opencolorio:   Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?   Is it just ocioconvert and ociolutimage?   Are there downsides?   -blake Larry Gritz : Jul 03 02:41PM -0700 I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.   So it's really only an issue of ociolutimage.   Three approaches have been suggested:   1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.   2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).   3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.   -- lg       -- Larry Gritz l...@... Liam : Jul 03 03:37PM -0700 Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.   I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?   Thx! Liam     On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote: Larry Gritz : Jul 03 05:01PM -0700 The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?   The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?   #3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.       -- Larry Gritz l...@... Liam : Jul 03 05:32PM -0700 Hi, thank you for allowing my previous post.   Making ociolutimage dependent on OIIO should be ok because the dependency is needed and the change is to resolve a cyclic dependency.   #3 seems good also and how long would it take to rewrite ociolutimage in Python? Who could do this? Would it support Python 2/3?   Thx! Liam https://github.com/LiamGFX https://www.imdb.com/name/nm9070367 https://www.linkedin.com/in/liamfernandez     On Tuesday, July 3, 2018 at 5:01:35 PM UTC-7, Larry Gritz wrote: Deke Kincaid : Jul 03 10:12PM -0700 I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.   So I vote for #1. Peter Hillman : Jul 04 05:38PM +1200 +1 for #1 It would be nice for OCIO to provide optionally built drop-in replacements for ocioconvert, ociolutimage etc as lightweight wrappers around oiiotool which map the command line arguments. Again, there'd be a runtime-only dependency on OIIO but it would prevent pipeline nightmares that happen when tools disappear between versions.   ________________________________ From: Deke Kincaid Sent: Wednesday, July 4, 2018 5:12 PM To: ocio...@... Subject: Re: [ocio-dev] Homebrew version of OCIO not bringing all apps ...   I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.     So I vote for #1.     -- 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.
 You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to ocio-dev+u...@....

Re: Homebrew version of OCIO not bringing all apps ...

Peter Hillman <peterm...@...>

+1 for #1
It would be nice for OCIO to provide optionally built drop-in replacements for ocioconvert, ociolutimage etc as lightweight wrappers around oiiotool which map the command line arguments. Again, there'd be a runtime-only dependency on OIIO but it would prevent pipeline nightmares that happen when tools disappear between versions.

From: Deke Kincaid <deke...@...>
Sent: Wednesday, July 4, 2018 5:12 PM
To: ocio...@...
Subject: Re: [ocio-dev] Homebrew version of OCIO not bringing all apps ...

I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.

So I vote for #1.

On Tue, Jul 3, 2018 at 5:01 PM Larry Gritz <l...@...> wrote:
The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?

The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?

#3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.

On Jul 3, 2018, at 3:37 PM, Liam <liamfe...@...> wrote:

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam

On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <b...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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...@....

--
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...@....

--
Larry Gritz

--
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...@....

--
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...@....

Re: Homebrew version of OCIO not bringing all apps ...

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

I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.

So I vote for #1.

On Tue, Jul 3, 2018 at 5:01 PM Larry Gritz <l...@...> wrote:
The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?

The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?

#3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.

On Jul 3, 2018, at 3:37 PM, Liam <liamfe...@...> wrote:

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam

On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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...@....

--
Larry Gritz

--
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...@....

--
Larry Gritz

--
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...@....

Re: Homebrew version of OCIO not bringing all apps ...

Liam <liamfe...@...>

Hi, thank you for allowing my previous post.

Making ociolutimage dependent on OIIO should be ok because the dependency is needed and the change is to resolve a cyclic dependency.

#3 seems good also and how long would it take to rewrite ociolutimage in Python? Who could do this? Would it support Python 2/3?

Thx! Liam
https://github.com/LiamGFX
https://www.imdb.com/name/nm9070367

On Tuesday, July 3, 2018 at 5:01:35 PM UTC-7, Larry Gritz wrote:
The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?

The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?

#3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.

On Jul 3, 2018, at 3:37 PM, Liam <liam...@...> wrote:

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam

On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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...@....

--
Larry Gritz

--
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.

--
Larry Gritz

Re: Homebrew version of OCIO not bringing all apps ...

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

The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?

The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?

#3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.

On Jul 3, 2018, at 3:37 PM, Liam <liamfe...@...> wrote:

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam

On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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.

--
Larry Gritz

--
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...@....

--
Larry Gritz

Re: Homebrew version of OCIO not bringing all apps ...

Liam <liamfe...@...>

Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.

I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?

Thx! Liam

On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:
I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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.

--
Larry Gritz

Re: Homebrew version of OCIO not bringing all apps ...

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

I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
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...@....

--
Larry Gritz

Re: Homebrew version of OCIO not bringing all apps ...

bsloan <bsl...@...>

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

Re: Homebrew version of OCIO not bringing all apps ...

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

fyi homebrew/science has been deprecated.  Luckily they migrated oiio/ocio into homebrew/core (default repo).

On Thu, Jun 28, 2018 at 4:34 AM Haarm-Pieter Duiker <li...@...> wrote:
That’s the correct approach. The build steps from the readme are copied below.

HP

## Building on Mac OSX

Use the following commands to build these packages on Mac OSX

• OpenColorIO
• brew install -vd opencolorio --with-python
• Update the homebrew repository of install scripts to make sure that OpenImageIO is included.
• brew tap homebrew/science
• Optional Dependencies for OpenImageIO
• brew install -vd libRaw
• brew install -vd OpenCV
• OpenImageIO
• brew install -vd openimageio --with-python
• CTL
• brew install -vd CTL
• OpenColorIO, a second time. ociolutimage will build with openimageio installed.
• brew uninstall -vd opencolorio
• brew install -vd opencolorio --with-python

On Wed, Jun 27, 2018 at 10:27 PM Michael Dolan <mich...@...> wrote:
To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own.

--
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...@....

--
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...@....

--
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...@....

Re: Homebrew version of OCIO not bringing all apps ...

Haarm-Pieter Duiker <li...@...>

That’s the correct approach. The build steps from the readme are copied below.

HP

## Building on Mac OSX

Use the following commands to build these packages on Mac OSX

• OpenColorIO
• brew install -vd opencolorio --with-python
• Update the homebrew repository of install scripts to make sure that OpenImageIO is included.
• brew tap homebrew/science
• Optional Dependencies for OpenImageIO
• brew install -vd libRaw
• brew install -vd OpenCV
• OpenImageIO
• brew install -vd openimageio --with-python
• CTL
• brew install -vd CTL
• OpenColorIO, a second time. ociolutimage will build with openimageio installed.
• brew uninstall -vd opencolorio
• brew install -vd opencolorio --with-python

On Wed, Jun 27, 2018 at 10:27 PM Michael Dolan <mich...@...> wrote:
To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own.

--
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...@....

--
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...@....

Re: Homebrew version of OCIO not bringing all apps ...

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

We should find a way to fix this cyclic dependency once and for all.

-- lg

On Jun 27, 2018, at 10:16 PM, Michael Dolan <mich...@...> wrote:

To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own.

--
Larry Gritz

Re: Homebrew version of OCIO not bringing all apps ...

Michael Dolan <mich...@...>

To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full functionality.

I typically build OCIO without the OIIO dependency; then build OIIO, linking against OCIO; then build OCIO again, linking against OIIO. The homebrew OIIO formulae depends on OCIO, so that may be contributing to this support being missing.

On Thu, Jun 14, 2018, 5:38 AM Abraham Schneider, <abraham....@...> wrote:
I tried to create the original ACES 1.0.3 config from the included python folder via the 'create_aces_config' tool on my Mac. To do that, I installed all necessary tools via 'homebrew' (like 'ctl') and especially OCIO like it's mentioned on the website: 'brew install opencolorio --with-python'

Unfortunately the 'create_aces_config' script won't run successfully because it can't find the tool 'ociolutimage'. Would be cool if the homebrew version of OCIO would install all the tools that are available in 'https://github.com/imageworks/OpenColorIO/tree/master/src/apps', so it would be easy to create the ACES reference config easily on your own.

--
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...@....

Re: how to write .cube luts?

Patrick Hodoul <patric...@...>

Just to highligth that ocio is expecting 'Red first' 3D luts.

Re: how to write .cube luts?

Dithermaster <dither...@...>

How does a 3D LUT work? Each numeric row has three entries, which represent R, G, and B output values, often 0.0 to 1.0 (but could be higher or negative for some cases).
Each row represents a position in the 64x64x64 input cube. The input R,G,B value (sometimes after running through a lg2 "shaper" if it is linear) gets multiplied by 63 (in the case of a 64x64x64 cube) and rounded to the nearest integer. Then the row number of r*64*64 + g*64 + b. For example, input of rgb={0.1, 0.2, 0.3} becomes rgb_index={6.3, 12.6, 18.9} which become rgb_index_int={6, 13, 19} which is row index 6*64*64 + 13*64 + 19 = 25427, if you are looking for the nearest element. It's actually more complex than that since tri-linear or tetrahedral interpolation is used, which means 8 or 4 elements surrounding the 3D position are looked up and interpolated to create the output RGB value.

///d@

On Wed, Jun 27, 2018 at 12:03 PM mc <michael...@...> wrote:
I've been searching for weeks and can't find a clear explanation of how

I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?

Thanks.

--
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...@....

Re: how to write .cube luts?

On Wed, Jun 27, 2018 at 1:03 PM mc <michael...@...> wrote:
I've been searching for weeks and can't find a clear explanation of how

I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?

Thanks.

--
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...@....

how to write .cube luts?

mc <michael...@...>

I've been searching for weeks and can't find a clear explanation of how .cube files are written. Please help me understand them.

I have a .cube file that was generated with 3D Lut Creator, with an image source of a HALD color image (64x64x64). No adjustments were applied to the image, so the .cube file should show input=output. But the decimal values in the lookup table mystify me. How were they generated? The decimal values, when multiplied by 64, do round to a number close to list position in the (64 64 64) list, but surely there's a precise algorithm to output those decimal values.

I've tried reading the OCIO C++ code to get the answer, but I don't really know the language. I want to write luts in Java. Can someone there help me?

Thanks.

 461 - 480 of 2170