Date   

Creating mipmapped textures with OpenImageIO

John Coldrick <john.c...@...>
 

Profuse apologies if this is an inappropriate place to ask about OIIO, but I couldn't find a group for it specifically...

We've been starting to use oiiotool to prep texture maps for 3D, and recently I've been getting incorrect behaviour wrt mipmapping.  We were running this on Windows and I thought perhaps it might have been an obscure bug that slipped between the cracks since most folks are probably using it on Linux, but I recently compiled oiio on centos and got the same results.

If I have an exr file, already linearized, that I wish to mipmap I run:

$ oiiotool ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

and when I run iinfo on this I get 

mymipmap.exr : 2048 x 2048, 4 channel, half openexr


if I run:

$ maketx ./mymap.exr -tile 64 64 -d half -o ./mymipmap.exr

iinfo provides:

mymipmap.exr : 2048 x 2048, 4 channel, half openexr (+mipmap)


I've verified by testing with render packages that indeed oiiotool is not creating a mipmap and maketx is.


I've tested this with OpenImageIO 1.5.16, 1.5.22 and 1.7.1dev - same results.

Am I doing something fundamentally wrong?  Many thanks for your thoughts...

J.C.


Re: color picking role, used in Nuke?

lucien...@...
 

Hey guys,

thanks for you answers!

So one would grade aces material in Nuke by only looking at his viewer rather than picking a shade from the color wheel I guess.

Anyone wants to chime in, production experience of comping in Aces/AcesCG?

Cheers


Le lundi 9 novembre 2015 12:47:45 UTC-8, Troy James Sobotka a écrit :

Greetings Lucien. Fellow Vancouverite here.

I made a simple OCIO configuration to test whether or not colour pickers are colour managed. It is only a rotation of sRGB primaries so that it is deadly obvious whether or not the application is colour managing correctly.

If you are using a wider gamut reference, the colour primaries will be quite different, and as such, the pickers would need to be properly transformed to whatever display is currently in use. Chances are, the picker isn't, and is instead dumping ambiguous RGB values direct to the display, putting the primaries in whatever the display currently happens to be.

The test config should reveal it quite quickly. If the pickers aren't colour managed, then artists have no real clue what they are picking. This would, for example, result in picking rough sRGB display values by eye, while the RGB triplets represent something else entirely in the reference space.

Feel free to email me privately if you have issues with the configuration.

https://github.com/sobotka/OpenColorIO-Colour-Management-Test

With respect,
TJS


On Mon, Nov 9, 2015, 11:39 AM Deke Kincaid <deke...@...> wrote:
Nuke does not use the colorpicking role and it selectively uses the roles in general as there is no direct mapping for some of them.

On Mon, Nov 9, 2015 at 11:17 AM, <luci...@...> wrote:
Hi everyone,

Let me start by introducing myself, I currently work at Image Engine, Vancouver and previously I was at Framestore, London.

I'm looking at doing comp work with wider gamut sources and I'm wondering about the color picker color management in Nuke.

Does anyone have found if the color picking role is ever being used by Nuke?
Should I do transformation myself if not?Anyone has tips to do that elegantly?

Cheers

Lucien

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

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


Re: disabling specific channels during view

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

Thanks Matt - that code is pretty much what I already had. But the Nuke code doesn't handle a channelHot of 1,1,0,0 either. When I do this, it solos the alpha channel instead.

On 12/29/15 10:23 AM, Matt Plec wrote:
Hi Paul -

The Nuke OCIO Display node does that and also sets up a matrix transform for a swizzle with setChannelView() -- https://github.com/imageworks/OpenColorIO/blob/master/src/nuke/OCIODisplay/OCIODisplay.cpp#L337

One thing to watch out for: If I'm remembering right, this is applied before the view colorspace conversion in the display transform, so if there's crosstalk in that then you can still end up with non-zero values in channels you had zeroed out.



On Mon, Dec 28, 2015 at 9:05 AM, Paul Miller <pa...@...> wrote:
I'm trying to figure out how I can get just red and green to show up for example. I've tried setting channelsHot to [1, 1, 0, 0] in the MatrixTransform::View() function but that doesn't do the right thing. I've also tried setting lumcoeff[2] = 0 but that doesn't have any effect.

Any suggestions?

--
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 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: disabling specific channels during view

Matt Plec <mp...@...>
 

Hi Paul -

The Nuke OCIO Display node does that and also sets up a matrix transform for a swizzle with setChannelView() -- https://github.com/imageworks/OpenColorIO/blob/master/src/nuke/OCIODisplay/OCIODisplay.cpp#L337

One thing to watch out for: If I'm remembering right, this is applied before the view colorspace conversion in the display transform, so if there's crosstalk in that then you can still end up with non-zero values in channels you had zeroed out.



On Mon, Dec 28, 2015 at 9:05 AM, Paul Miller <pa...@...> wrote:
I'm trying to figure out how I can get just red and green to show up for example. I've tried setting channelsHot to [1, 1, 0, 0] in the MatrixTransform::View() function but that doesn't do the right thing. I've also tried setting lumcoeff[2] = 0 but that doesn't have any effect.

Any suggestions?

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


disabling specific channels during view

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

I'm trying to figure out how I can get just red and green to show up for example. I've tried setting channelsHot to [1, 1, 0, 0] in the MatrixTransform::View() function but that doesn't do the right thing. I've also tried setting lumcoeff[2] = 0 but that doesn't have any effect.

Any suggestions?


Re: OpenColorIO stewardship

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

It would be really good if we could also get the OpenColorIO-Configs up to date. 11 months is a little long for a simple update to the ACES config which Hp has had in his fork since it's release. Silly as it sounds, things like this actually prevent some software vendors from including the ACES 1.0 config with the official software distribution as it's not in the official release but a fork.  From the user POV this causes many people to use old & outdated configs and then they are confused about why it doesn't work right.


Re: OpenColorIO stewardship

Mark Boorer <mark...@...>
 

Hi Mark,

We have a number of large changes about to land in the public repository, and whilst I know it's frustrating to see the repo stagnant, by no means is the project dead.
My current goal is to put our humungous patch out into the public domain, seek feedback, and then assess how that affects the state of the existing pull requests / issues.
This patch should tackle a number of outstanding issues, primarily the plugin arcitecture, differences between the GPU and CPU code-paths, better unit testing, improved CMake code for cross platform builds, documentation, and repository structure. There are others working on new file-format plugins whose work I am hoping to integrate soon.

In addition, there is also a large amount of organisation happening behind-the-scenes to do with our official ACES implementation on the config side of things.

I am working towards having this ready for feedback by the new year, and once this is done we will hopefully see a lot more activity in the open again.

Cheers,
Mark



On Tue, Nov 24, 2015 at 3:31 PM, Mark Visser <mvi...@...> wrote:
Hi all, 

Development in the main imageworks/OpenColorIO branch seems to have stalled. The last commit is from September, 2014, and the number of issues and pull requests continues to grow.

What do folks think about creating an OpenColorIO github organization and centralizing development there? I know there are several active forks at other studios, but looking at the official repo and web site, the project would appear to be dead. I don't imagine downstream maintainers will pull from anywhere but the official repo, so any fixes and features made in other forks won't show up in Nuke/Maya/RV/etc.

best,
Mark

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


OpenColorIO stewardship

Mark Visser <mvi...@...>
 

Hi all, 

Development in the main imageworks/OpenColorIO branch seems to have stalled. The last commit is from September, 2014, and the number of issues and pull requests continues to grow.

What do folks think about creating an OpenColorIO github organization and centralizing development there? I know there are several active forks at other studios, but looking at the official repo and web site, the project would appear to be dead. I don't imagine downstream maintainers will pull from anywhere but the official repo, so any fixes and features made in other forks won't show up in Nuke/Maya/RV/etc.

best,
Mark


Re: LUT for linear exr to rec709

Andrew Britton <andrew.d...@...>
 

If it doesn't work, email me and I might be able help out. 


On Nov 11, 2015, at 5:40, Matt Keith <mttk...@...> wrote:

Thanks for the promt reply Andrew!

I'm out the office at the moment but I'll give this a go as soon as I'm back at my desk.

Matt.

On Wednesday, November 11, 2015 at 1:34:22 PM UTC, Andrew Britton wrote:
You should be able to create a LUT from that generator that performs both operations. Have you tried these settings?

Load preset - Advanced

"Camera Data"
Gamma - Normalized sensor linear
Range - Extended

"Conversion Parameters"
Scaling - Photometric

"Image Destination"
Gamma - video
Range - legal

"LUT Parameters"
3D - Forced
Bits - 16
File Format - Nuke (makes a .cube file if I remember right which maya/VRay can use)


image.jpeg



On Nov 11, 2015, at 5:07, Matt Keith <mtt...@...> wrote:

Hello all.

We are trying to adopt a more complete linear work flow in the 3D department of the vfx company that I work for.

The problem that we currently have is that 3D software ( in our case Maya rendering with Vray) renders out linear exr files. In order to use any of the LUT that are generated by the Arri LUT generator, (https://www.arri.com/camera/alexa/tools/lut_generator/) I need to apply a "pre" LUT to convert my linear renders into logc images that the arri LUT is expecting. Does anyone know how I can go about doing that?

Any advice greatfully recieved.

Kind regards,
Matt

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

--
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: LUT for linear exr to rec709

Matt Keith <mttk...@...>
 

Thanks for the promt reply Andrew!

I'm out the office at the moment but I'll give this a go as soon as I'm back at my desk.

Matt.


On Wednesday, November 11, 2015 at 1:34:22 PM UTC, Andrew Britton wrote:
You should be able to create a LUT from that generator that performs both operations. Have you tried these settings?

Load preset - Advanced

"Camera Data"
Gamma - Normalized sensor linear
Range - Extended

"Conversion Parameters"
Scaling - Photometric

"Image Destination"
Gamma - video
Range - legal

"LUT Parameters"
3D - Forced
Bits - 16
File Format - Nuke (makes a .cube file if I remember right which maya/VRay can use)


image.jpeg



On Nov 11, 2015, at 5:07, Matt Keith <mtt...@...> wrote:

Hello all.

We are trying to adopt a more complete linear work flow in the 3D department of the vfx company that I work for.

The problem that we currently have is that 3D software ( in our case Maya rendering with Vray) renders out linear exr files. In order to use any of the LUT that are generated by the Arri LUT generator, (https://www.arri.com/camera/alexa/tools/lut_generator/) I need to apply a "pre" LUT to convert my linear renders into logc images that the arri LUT is expecting. Does anyone know how I can go about doing that?

Any advice greatfully recieved.

Kind regards,
Matt

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


Re: LUT for linear exr to rec709

Andrew Britton <andrew.d...@...>
 

You should be able to create a LUT from that generator that performs both operations. Have you tried these settings?

Load preset - Advanced

"Camera Data"
Gamma - Normalized sensor linear
Range - Extended

"Conversion Parameters"
Scaling - Photometric

"Image Destination"
Gamma - video
Range - legal

"LUT Parameters"
3D - Forced
Bits - 16
File Format - Nuke (makes a .cube file if I remember right which maya/VRay can use)


image.jpeg



On Nov 11, 2015, at 5:07, Matt Keith <mttk...@...> wrote:

Hello all.

We are trying to adopt a more complete linear work flow in the 3D department of the vfx company that I work for.

The problem that we currently have is that 3D software ( in our case Maya rendering with Vray) renders out linear exr files. In order to use any of the LUT that are generated by the Arri LUT generator, (https://www.arri.com/camera/alexa/tools/lut_generator/) I need to apply a "pre" LUT to convert my linear renders into logc images that the arri LUT is expecting. Does anyone know how I can go about doing that?

Any advice greatfully recieved.

Kind regards,
Matt

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


LUT for linear exr to rec709

Matt Keith <mttk...@...>
 

Hello all.

We are trying to adopt a more complete linear work flow in the 3D department of the vfx company that I work for.

The problem that we currently have is that 3D software ( in our case Maya rendering with Vray) renders out linear exr files. In order to use any of the LUT that are generated by the Arri LUT generator, (https://www.arri.com/camera/alexa/tools/lut_generator/) I need to apply a "pre" LUT to convert my linear renders into logc images that the arri LUT is expecting. Does anyone know how I can go about doing that?

Any advice greatfully recieved.

Kind regards,
Matt


Re: color picking role, used in Nuke?

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

Greetings Lucien. Fellow Vancouverite here.

I made a simple OCIO configuration to test whether or not colour pickers are colour managed. It is only a rotation of sRGB primaries so that it is deadly obvious whether or not the application is colour managing correctly.

If you are using a wider gamut reference, the colour primaries will be quite different, and as such, the pickers would need to be properly transformed to whatever display is currently in use. Chances are, the picker isn't, and is instead dumping ambiguous RGB values direct to the display, putting the primaries in whatever the display currently happens to be.

The test config should reveal it quite quickly. If the pickers aren't colour managed, then artists have no real clue what they are picking. This would, for example, result in picking rough sRGB display values by eye, while the RGB triplets represent something else entirely in the reference space.

Feel free to email me privately if you have issues with the configuration.

https://github.com/sobotka/OpenColorIO-Colour-Management-Test

With respect,
TJS


On Mon, Nov 9, 2015, 11:39 AM Deke Kincaid <dekek...@...> wrote:
Nuke does not use the colorpicking role and it selectively uses the roles in general as there is no direct mapping for some of them.

On Mon, Nov 9, 2015 at 11:17 AM, <lucien...@...> wrote:
Hi everyone,

Let me start by introducing myself, I currently work at Image Engine, Vancouver and previously I was at Framestore, London.

I'm looking at doing comp work with wider gamut sources and I'm wondering about the color picker color management in Nuke.

Does anyone have found if the color picking role is ever being used by Nuke?
Should I do transformation myself if not?Anyone has tips to do that elegantly?

Cheers

Lucien

--
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 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: color picking role, used in Nuke?

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

Nuke does not use the colorpicking role and it selectively uses the roles in general as there is no direct mapping for some of them.

On Mon, Nov 9, 2015 at 11:17 AM, <lucien...@...> wrote:
Hi everyone,

Let me start by introducing myself, I currently work at Image Engine, Vancouver and previously I was at Framestore, London.

I'm looking at doing comp work with wider gamut sources and I'm wondering about the color picker color management in Nuke.

Does anyone have found if the color picking role is ever being used by Nuke?
Should I do transformation myself if not?Anyone has tips to do that elegantly?

Cheers

Lucien

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


color picking role, used in Nuke?

lucien...@...
 

Hi everyone,

Let me start by introducing myself, I currently work at Image Engine, Vancouver and previously I was at Framestore, London.

I'm looking at doing comp work with wider gamut sources and I'm wondering about the color picker color management in Nuke.

Does anyone have found if the color picking role is ever being used by Nuke?
Should I do transformation myself if not?Anyone has tips to do that elegantly?

Cheers

Lucien


Compatible software list

Alexandre Gauthier <immar...@...>
 

Hi,

Could you add Natron (www.natron.fr) as compatible software on the corresponding page on http://opencolorio.org/CompatibleSoftware.html ?
It is made compatible in a very similar way to how Nuke nodes do it. 
The following nodes are available: OCIOCDLTransform, OCIOColorSpace, OCIODisplay, OCIOFileTransform, OCIOLookTransform, OCIOLogConvert

All OCIO configs are bundled in Natron (Aces 1.0, Blender, Nuke-default,Spi-Anim, Spi-Vfx). They can be selected in the Preferences of the application, and the Blender profile is set as default.

cheers,

Alex


Re: SIGGRAPH 2015 - OpenColorIO Birds of a Feather

dennis...@...
 

Thanks for the meetup! Great discussion and I will be putting a lot of advice to good use.

Den


On Wednesday, August 5, 2015 at 4:49:43 PM UTC-7, Mark Boorer wrote:
Hi All,

For those of you attending SIGGRAPH 2015 in Los Angeles, we will be hosting a "Birds of a Feather" event for users and developers of OpenColorIO to get together and discuss anything and everything related to working with OpenColorIO.

I realise that this year has been a little quiet on the development front, but rest assured we have some exciting new features being worked on at present by a number of teams.

It'd be great to be able to put names to faces and to hear about any ideas, problems or solutions people have come up with.

The event takes place on Wednesday, August 12, 2015 from 3:00 pm till 4:30pm in the Los Angeles Convention Center, Room 512.

For those of you who are either not registered to attend the conference, or have other talks to attend, I encourage you to also participate in the Open Source VFX "Beers of a Feather" later that same day from 6pm till 8pm at Salvage (West 7th Street  http://salvagela.com/)

I hope to meet as many of you as possible!

-Mark


SIGGRAPH 2015 - OpenColorIO Birds of a Feather

Mark Boorer <mark...@...>
 

Hi All,

For those of you attending SIGGRAPH 2015 in Los Angeles, we will be hosting a "Birds of a Feather" event for users and developers of OpenColorIO to get together and discuss anything and everything related to working with OpenColorIO.

I realise that this year has been a little quiet on the development front, but rest assured we have some exciting new features being worked on at present by a number of teams.

It'd be great to be able to put names to faces and to hear about any ideas, problems or solutions people have come up with.

The event takes place on Wednesday, August 12, 2015 from 3:00 pm till 4:30pm in the Los Angeles Convention Center, Room 512.

For those of you who are either not registered to attend the conference, or have other talks to attend, I encourage you to also participate in the Open Source VFX "Beers of a Feather" later that same day from 6pm till 8pm at Salvage (West 7th Street  http://salvagela.com/)

I hope to meet as many of you as possible!

-Mark


5th annual Open Source VFX Beer of a Feather

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

5th annual Open Source VFX Beer of a Feather

For those of you attending SIGGRAPH 2015 in Los Angeles, 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 in person with people you've been working with on the other end of the mail lists.

When: Wed. August 12, 2015, 6-8pm

Where: Salvage, 717 West 7th Street http://salvagela.com/

How: Sponsors will charge 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:

Digital Domain
Double Negative
DreamWorks Animation
Industrial Light + Magic
Luma Pictures
Method Studios
Peregrine Labs
Pixar Animation Studios
SolidAngle SL
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).



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


Re: Add ExpressionTransform op

Marie Fetiveau <ma...@...>
 

Ok, thanks.

In the last commit of this PR (february 2015), an OCIO_USE_LLVM opt was added so I actually built this code without LLVM.

On Sat, May 23, 2015 at 5:10 AM, Malcolm Humphreys <malcolmh...@...> wrote:
We have been waiting for Mark to post headers for the new plugin API.

The idea is to keep the OCIO core free of heavy dependencies and for things like Expression, CTL and Truelight to be supplied by plugins (which are optional and can have heavy link dependencies).

Merging this pull request would force all the third party apps to start compiling and linking to LLVM.

.malcolm

On 22/05/2015, at 10:49 PM, Marie Fetiveau wrote:

Helloo,

Someone knows why it's on hold ?

Thanks,

Marie

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



--
Marie Fétiveau
Color / IO / Comp Pipeline TD
_____________________

      

761 - 780 of 2201