Date   

Re: OCIO - Path Forward

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

Absolutely pick the best thing, the only real benefit to what I am providing is I can give you exactly the environment that you want if its not provided by one of the cloudy tools. I don't believe any of them supported OSX. 

Its would be running on my virtual CI infrastructure.   

On 16 January 2017 at 23:52, Larry Gritz <l...@...> wrote:
I don't have any Jenkins experience, but Travis is pretty straightforward and I've really come to rely on it for my open source projects. It's a big boost to know before you merge something that it's been built and passes tests on a matrix of several platforms, compilers, and build options. Well worth the time investment to get it set up. Appveyor is also helpful as the rough equivalent on Windows.


On Jan 16, 2017, at 1:31 PM, Sean Cooper <se...@...> wrote:

@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins

On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
That would be great if you have the cycles!


--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: OCIO - Path Forward

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

I don't have any Jenkins experience, but Travis is pretty straightforward and I've really come to rely on it for my open source projects. It's a big boost to know before you merge something that it's been built and passes tests on a matrix of several platforms, compilers, and build options. Well worth the time investment to get it set up. Appveyor is also helpful as the rough equivalent on Windows.


On Jan 16, 2017, at 1:31 PM, Sean Cooper <se...@...> wrote:

@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins

On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
That would be great if you have the cycles!


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



Re: OCIO - Path Forward

Sean Cooper <se...@...>
 

@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins

On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
That would be great if you have the cycles!


Re: OCIO - Path Forward

Sean Cooper <se...@...>
 

That would be great if you have the cycles!


Re: OCIO - Path Forward

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

On the CI front I can provide windows Linux and mac systems plus Jenkins if you want. 



On Fri., 13 Jan. 2017 at 1:40 am, Sean Cooper <se...@...> wrote:
Whoops, try giving it another go

On Thu, Jan 12, 2017 at 3:39 PM, Deke Kincaid <dekek...@...> wrote:
You probably have to move the file to your personal gmail.  Google docs are not view-able outside of our domain either.

On Thu, Jan 12, 2017 at 3:38 PM, Deke Kincaid <dekek...@...> wrote:
You need permission

This form can only be viewed by users in the owner's organization.

Try contacting the owner of the form if you think this is a mistake. Learn More.


On Thu, Jan 12, 2017 at 3:33 PM, Sean Cooper <se...@...> wrote:
Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause!

https://goo.gl/forms/Lq9buvEJg2qzJzq03








--


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.











--


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: OCIO - Path Forward

Sean Cooper <se...@...>
 

Whoops, try giving it another go

On Thu, Jan 12, 2017 at 3:39 PM, Deke Kincaid <dekek...@...> wrote:
You probably have to move the file to your personal gmail.  Google docs are not view-able outside of our domain either.

On Thu, Jan 12, 2017 at 3:38 PM, Deke Kincaid <dekek...@...> wrote:
You need permission

This form can only be viewed by users in the owner's organization.

Try contacting the owner of the form if you think this is a mistake. Learn More.


On Thu, Jan 12, 2017 at 3:33 PM, Sean Cooper <se...@...> wrote:
Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause!

https://goo.gl/forms/Lq9buvEJg2qzJzq03

--
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: OCIO - Path Forward

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

You probably have to move the file to your personal gmail.  Google docs are not view-able outside of our domain either.

On Thu, Jan 12, 2017 at 3:38 PM, Deke Kincaid <dekek...@...> wrote:
You need permission

This form can only be viewed by users in the owner's organization.

Try contacting the owner of the form if you think this is a mistake. Learn More.


On Thu, Jan 12, 2017 at 3:33 PM, Sean Cooper <se...@...> wrote:
Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause!

https://goo.gl/forms/Lq9buvEJg2qzJzq03

--
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: OCIO - Path Forward

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

You need permission

This form can only be viewed by users in the owner's organization.

Try contacting the owner of the form if you think this is a mistake. Learn More.


On Thu, Jan 12, 2017 at 3:33 PM, Sean Cooper <se...@...> wrote:
Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause!

https://goo.gl/forms/Lq9buvEJg2qzJzq03

--
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: OCIO - Path Forward

Sean Cooper <se...@...>
 

Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause!

https://goo.gl/forms/Lq9buvEJg2qzJzq03


Re: OCIO - Path Forward

Sean Cooper <se...@...>
 

Thanks, yeah I should have linked the PR in the post. I'll try and get more eyes on that to test, though I'm sure it's fine, then we can pull that through to get things kicked off.

As for Labels, I'd just like to get a better organizational structure that guides users attention a little better. My gut feeling is pushing towards a slimmed down version of this: https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63#.3kx74xshg


Re: OCIO - Path Forward

dbr/Ben <dbr....@...>
 

This all sounds good to me!

I would be happy to help out auditing/tagging the issues in GitHub. 

The current labels seem fairly reasonable to me - "feature" for new things, "bug" for bugs, internal for non-user-impacting things, a label to flag API breaking changes, and "deferred" for future things. I'd probably add tags for performance improvements, docs, and build related issues. Then along side these, maybe tags for tag "easy" quick-to-fix issues, low/high priority tags)

Regarding CI, There is a pull request to fix up the TravisCI config (#415). It would also be worth investigating Appveyor to test on Windows also

Sent from my phone

On 12 Jan 2017, at 11:12, Sean Cooper <se...@...> wrote:

Hello all, and happy new year!

I'd like to start a formal discussion around the steps we will take to give OCIO a breath of life. Hopefully we can work to make 2017 a year of progress. So in that spirit I'd like to layout a general game plan for comment and discussion.

General Notes:
  • Reading through our last discussion I found it troubling that due to the stalled public development, conversations and progress seemed to have moved behind closed doors. To facilitate openness I advise all contributors to relegate conversation to either the GitHub issues or this forum. I have created an OpenColorIO Slack channel if there needs to be quick group conversation among contributors, but the majority of conversation should be relegated to this forum.
  • I have been granted ownership to the GitHub repo, and can accomplish administrative tasks as necessary. I do not intend to accept Pull Requests in isolation, both due to the need for public discourse and my unfamiliarity with the codebase.
  • Development should continue in a "master-only" fashion, based on the previous branch/merge patterns and at the suggestion of Larry Gritz

Game Plan:

  • Organization
    • Project Owners
      • This is no slight to the current owners of OCIO, but would it be worth it to revisit the current owners and identify their level of involvement moving forward (based on interest and free time available)? It could be beneficial to add vocal / active developers to the helm of the project. Discussion welcomed.
    • Issues
      • Need to create a better issue labeling scheme, and need to maintain it's use. Suggestions welcome.
      • Are issues irrelevant / duplicates?
      • Do PRs solve specific issues?
      • Asses difficulty in solving
    • Pull Requests
      • Are they still relevant?
      • Rank in order of usefulness
      • Determine order of integration
  • Repository
    • Continuous Integration
      • In order to begin pulling a larger volume of Pull Requests, we need to update the CI system in use.
      • Alongside this is a reevaluation of the OCIO unit tests
    • Make private forks public
      • Address private forks with additional features (Dennis Adams, Mark Boorer, etc.)
      • Get them posted publicly, work into pull request
  • Road to 2.0
    • What are the dream requests?
    • How do we want to interact with OCIO in 5 years?
    • What movements on the horizon do we need to begin working towards?
    • What features would improve adoption in modern software?
Order of Attack:
  • Issue Labels
  • Easy PR with greatest image quality impact
  • Website + Documentation
    • Up to date? Documentation still relevant?
    • Website on version 1.0.8
  • Continuous Integration
  • PR review
  • Issue solving
  • Live, Long and Prosper

Please join me in conversation about the future of OCIO! All of the above is open to suggestion and critique.

Sean

--
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: OCIO - Path Forward

Sean Cooper <se...@...>
 

A) Providing metadata on the chromaticities for each Display cluster, or possibly per View?
B) Providing metadata on the reference chromaticities.
C) Provide some form of metadata that differentiates the transfer function portion of a view transform from any other colorimetric transforms. This would be needed for colour pickers and other things, where one needs to know the colorimetry of the reference and the destination, as well as how to apply *only* the transfer function to the UI element, post transform. Gradient UIs, color pickers, coloured sliders, etc.

Troy, would you be able to wrap this into an Issue on GH? With the coming addition of labels, this will be classified as a feature request.

On Wed, Jan 11, 2017 at 5:03 PM, Troy Sobotka <troy.s...@...> wrote:


On Wed, Jan 11, 2017, 5:42 PM Sean Cooper <se...@...> wrote:
  • Road to 2.0
    • What are the dream requests?

On a practical "get things done with the library" sense, it would be excellent to deal with OCIO for colour managing UI elements.

Having spent plenty of time ramming into the problems, I believe that can be elegantly accomplished by:

A) Providing metadata on the chromaticities for each Display cluster, or possibly per View?
B) Providing metadata on the reference chromaticities.
C) Provide some form of metadata that differentiates the transfer function portion of a view transform from any other colorimetric transforms. This would be needed for colour pickers and other things, where one needs to know the colorimetry of the reference and the destination, as well as how to apply *only* the transfer function to the UI element, post transform. Gradient UIs, color pickers, coloured sliders, etc.

Many transforms are going to be of the transfer function variety, and it makes sense to tackle UI in the least invasive manner possible, hence limiting the metadata to the fewest possible areas makes sense? Per transform seems overkill unless a sane metadata structure can be arrived at that wraps up the needs.

With respect,
TJS

--
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: OCIO - Path Forward

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



On Wed, Jan 11, 2017, 5:42 PM Sean Cooper <se...@...> wrote:
  • Road to 2.0
    • What are the dream requests?

On a practical "get things done with the library" sense, it would be excellent to deal with OCIO for colour managing UI elements.

Having spent plenty of time ramming into the problems, I believe that can be elegantly accomplished by:

A) Providing metadata on the chromaticities for each Display cluster, or possibly per View?
B) Providing metadata on the reference chromaticities.
C) Provide some form of metadata that differentiates the transfer function portion of a view transform from any other colorimetric transforms. This would be needed for colour pickers and other things, where one needs to know the colorimetry of the reference and the destination, as well as how to apply *only* the transfer function to the UI element, post transform. Gradient UIs, color pickers, coloured sliders, etc.

Many transforms are going to be of the transfer function variety, and it makes sense to tackle UI in the least invasive manner possible, hence limiting the metadata to the fewest possible areas makes sense? Per transform seems overkill unless a sane metadata structure can be arrived at that wraps up the needs.

With respect,
TJS


OCIO - Path Forward

Sean Cooper <se...@...>
 

Hello all, and happy new year!

I'd like to start a formal discussion around the steps we will take to give OCIO a breath of life. Hopefully we can work to make 2017 a year of progress. So in that spirit I'd like to layout a general game plan for comment and discussion.

General Notes:
  • Reading through our last discussion I found it troubling that due to the stalled public development, conversations and progress seemed to have moved behind closed doors. To facilitate openness I advise all contributors to relegate conversation to either the GitHub issues or this forum. I have created an OpenColorIO Slack channel if there needs to be quick group conversation among contributors, but the majority of conversation should be relegated to this forum.
  • I have been granted ownership to the GitHub repo, and can accomplish administrative tasks as necessary. I do not intend to accept Pull Requests in isolation, both due to the need for public discourse and my unfamiliarity with the codebase.
  • Development should continue in a "master-only" fashion, based on the previous branch/merge patterns and at the suggestion of Larry Gritz

Game Plan:

  • Organization
    • Project Owners
      • This is no slight to the current owners of OCIO, but would it be worth it to revisit the current owners and identify their level of involvement moving forward (based on interest and free time available)? It could be beneficial to add vocal / active developers to the helm of the project. Discussion welcomed.
    • Issues
      • Need to create a better issue labeling scheme, and need to maintain it's use. Suggestions welcome.
      • Are issues irrelevant / duplicates?
      • Do PRs solve specific issues?
      • Asses difficulty in solving
    • Pull Requests
      • Are they still relevant?
      • Rank in order of usefulness
      • Determine order of integration
  • Repository
    • Continuous Integration
      • In order to begin pulling a larger volume of Pull Requests, we need to update the CI system in use.
      • Alongside this is a reevaluation of the OCIO unit tests
    • Make private forks public
      • Address private forks with additional features (Dennis Adams, Mark Boorer, etc.)
      • Get them posted publicly, work into pull request
  • Road to 2.0
    • What are the dream requests?
    • How do we want to interact with OCIO in 5 years?
    • What movements on the horizon do we need to begin working towards?
    • What features would improve adoption in modern software?
Order of Attack:
  • Issue Labels
  • Easy PR with greatest image quality impact
  • Website + Documentation
    • Up to date? Documentation still relevant?
    • Website on version 1.0.8
  • Continuous Integration
  • PR review
  • Issue solving
  • Live, Long and Prosper

Please join me in conversation about the future of OCIO! All of the above is open to suggestion and critique.

Sean


Re: LUT for linear exr to rec709

Sean Cooper <se...@...>
 

Hi Meiwa,

It's a bit hard to remotely debug from the info you've provided, but the general answer is that you'd want to bring your Linear source (presumably in Arri Wide Gamut primaries) into a V3LogC space. Depending on the tools at your disposal you should be able to do this in most grading applications and in Nuke's native "colorspace" node, or uses OCIO's ACES 1.0.1 config. Then use the ARRI Lut Generator, but coming from LogC source instead of Sensor Linear.

If you give a little more info I could try to shape my answer a little better.

On Tue, Dec 13, 2016 at 4:21 AM, <mei...@...> wrote:
Dear Andrew,

I have tried the lut generator, from normalized sensor linear to video, but it fails to get a correct outcome.
The output lut generate an over-expose image.
Is that because there is difference between "scene linear" and "normalized sensor linear"?

I have the situation here same with Matt, hope find out solution asap.

Thanks,
Meiwa

On Thursday, November 12, 2015 at 12:09:15 AM UTC+8, Andrew Britton wrote:
If it doesn't work, email me and I might be able help out. 


On Nov 11, 2015, at 5:40, Matt Keith <mtt...@...> 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-d...@....
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-d...@....
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: LUT for linear exr to rec709

mei...@...
 

Dear Andrew,

I have tried the lut generator, from normalized sensor linear to video, but it fails to get a correct outcome.
The output lut generate an over-expose image.
Is that because there is difference between "scene linear" and "normalized sensor linear"?

I have the situation here same with Matt, hope find out solution asap.

Thanks,
Meiwa

On Thursday, November 12, 2015 at 12:09:15 AM UTC+8, Andrew Britton wrote:
If it doesn't work, email me and I might be able help out. 


On Nov 11, 2015, at 5:40, Matt Keith <mtt...@...> 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-d...@....
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: link problem with Visual Studio 2012

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

On 12/5/2016 4:12 PM, Dithermaster wrote:
Is this 32-bit or 64-bit? If 32-bit, did you change the default calling
convention in your project (__cdecl vs __stdcall)? Undecorated headers
with .lib files that use the default convention will fail if you've
changed the default convention. In 64-bit this is moot since it's
all __fastcall.
No, 64 bit only.

I used the default cmake settings, though I did run cmake and build with cygwin in my path (so "patch" would work when building tinyxml).

I'll look into the v0 vs v1 issue - that looks like it may be the culprit.


On Mon, Dec 5, 2016 at 12:42 PM, Jeremy Selan <jeremy...@...
<mailto:jeremy...@...>> wrote:

Are you using the proper generated headers? Are you overriding so
version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to
be in v1 (corresponding to the major version).

See https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in
<https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in>

#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace
OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@


https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt
<https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt>
set(OCIO_VERSION_MAJOR 1)
set(OCIO_VERSION_MINOR 0)
set(OCIO_VERSION_PATCH 9)


set(SOVERSION ${OCIO_VERSION_MAJOR}CACHESTRING "Set the SO version
in the SO name of the output library")



On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...
<mailto:pa...@...>> wrote:

I'm in the twilight zone today. After a bad merge from
Mac->Windows, my application will no longer link against the
shared OpenColorIO.lib on Windows, using Visual Studio 2012.
This is the exact same set of headers and .lib I've been using
for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport)
public: static int __cdecl
OpenColorIO::v0::FileTransform::getNumFormats(void)"
(__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or
definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport)
char const * const OpenColorIO::v0::ROLE_DATA"
(__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport)
char const * const OpenColorIO::v0::ROLE_COLOR_PICKING"
(__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport)
char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR"
(__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake
on it, and rebuilt. I did have to make one change to
OpenColorABI.h, and that is to get it to use <memory> and
std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like
nothing is being exported from it.

Has anyone else experienced anything like this?

--
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...@...
<mailto:ocio-dev%2B...@...>.
For more options, visit https://groups.google.com/d/optout
<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...@...
<mailto:ocio-dev+u...@...>.
For more options, visit https://groups.google.com/d/optout
<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...@...
<mailto:ocio-dev+u...@...>.
For more options, visit https://groups.google.com/d/optout.


Re: link problem with Visual Studio 2012

Dithermaster <dither...@...>
 

Is this 32-bit or 64-bit? If 32-bit, did you change the default calling convention in your project (__cdecl vs __stdcall)? Undecorated headers with .lib files that use the default convention will fail if you've changed the default convention. In 64-bit this is moot since it's all __fastcall.

On Mon, Dec 5, 2016 at 12:42 PM, Jeremy Selan <jeremy...@...> wrote:
Are you using the proper generated headers? Are you overriding so version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major version).


#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@

set(OCIO_VERSION_MAJOR 1)
set(OCIO_VERSION_MINOR 0)
set(OCIO_VERSION_PATCH 9)


set(SOVERSION ${OCIO_VERSION_MAJOR} CACHE STRING "Set the SO version in the SO name of the output library")



On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...> wrote:
I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?

--
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: link problem with Visual Studio 2012

Jeremy Selan <jeremy...@...>
 

Are you using the proper generated headers? Are you overriding so version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major version).


#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@

set(OCIO_VERSION_MAJOR 1)
set(OCIO_VERSION_MINOR 0)
set(OCIO_VERSION_PATCH 9)


set(SOVERSION ${OCIO_VERSION_MAJOR} CACHE STRING "Set the SO version in the SO name of the output library")



On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...> wrote:
I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?

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


link problem with Visual Studio 2012

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

I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?

701 - 720 of 2227