Re: Setting OCIO->Displays->Active in RV
Ravindra Korde
Hi Michael, No problem at all. I will check the links you provided & try to create it in RV. On Mon, Aug 19, 2019, 8:22 PM Michael Dolan <michdolan@...> wrote:
|
|
Re: Setting OCIO->Displays->Active in RV
Michael Dolan
Sorry for the late reply. It might be worth asking this question on RV's support site instead, since it pertains to their bundled OCIO package: Here are some really old developer docs about customizing OCIO in RV, which may or may not be a helpful starting point: On Thu, Aug 1, 2019, 10:47 PM Ravindra Korde, <rravindrakorde@...> wrote:
|
|
Re: SIGGRAPH 2019 - OpenColorIO Birds of a Feather
Pipeliner TD
thank you for sharing the presentation! Am Mi., 31. Juli 2019 um 20:44 Uhr schrieb Michael Dolan <michdolan@...>: Hello all, |
|
Re: Compile order for OCIO, OIIO, OpenExr?
Mark Boorer
> Is there a target to build only the OpenColorIO tools? -DOCIO_BUILD_APPS=OFF -DOCIO_BUILD_APPS=ON You will unnecessarily build the core lib twice, but reinstalling it over the top should cause no issues. On Thu, 8 Aug 2019, 19:39 Gonzalo Garramuño, <ggarra13@...> wrote:
|
|
Re: Compile order for OCIO, OIIO, OpenExr?
Larry Gritz
This is all my understanding, too. To recap:
OIIO's dependency on OCIO is fundamental (well, if you want all the color conversion functionality, which of course any studio user does).
OCIO's dependency on OIIO is limited. If you just need the OCIO libraries, OIIO is not needed at all. The ways that OCIO uses OCIO are strictly for ocioconvert, ociodisplay, and ociolutimage. ocioconvert is a historical quirk dating from a time when OIIO did not have OCIO support and there was an actual purpose to 'ocioconvert', whereas now you just want to use 'oiiotool --colorconnvert. ociodisplay is really just an example (and maybe ocioconvert is, too), and as examples, they don't need the full flexibility of an OpenImageIO-backed support of all possible data and file formats. So maybe a solution there is, say, to support OpenEXR only and use tinyexr (a header-only implementation of just exr core features). ociobakelut is a little more fundamental, though only used by power users. But again, if you're willing to stipulate that the baked LUT images are always openexr, maybe there as well using OpenEXR or even tinyexr will let us avoid pulling all of OIIO in. Also, it is worth noting that if these utilities were changed from C++ to Python, even if they still use OIIO, it would at least be a simple runtime dependency and not a circular build-order dependency. -- lg
|
|
Re: Compile order for OCIO, OIIO, OpenExr?
Sloan, Blake
Hi Steve!
OpenEXR does not (and should not) depend on OCIO.
I think I bring the OCIO->OIIO dependency up at every BoF.
What Mark suggests works but is a bit more complicated for shops using an automated build system (OCIO build may succeed but link to the system’s installed OIIO libs instead of the yet-to-be-built ones)
Build OCIO without ociorender Build OIIO against OCIO (make sure rpaths do not explicitly point to OCIO build directory) Build OCIO with ociorender against OIIO Install OCIO Install OIIO
OIIO’s dependency on on OCIO is, in my opinion, a necessary thing as it allows OIIO clients to manage color using OCIO.
OCIO’s dependency on OIIO is not essential and should be deprecated (I think its current custodians are in agreement). One of OCIO’s example executables (ociorender?) depends on OIIO for image file IO. This executable can either be
-blake
|
|
Re: Compile order for OCIO, OIIO, OpenExr?
Gonzalo Garramuño
El 8/8/19 a las 15:32, Mark Boorer escribió:
1. OpenEXRIs there a target to build only the OpenColorIO tools? -- Gonzalo Garramuño |
|
Re: Compile order for OCIO, OIIO, OpenExr?
Mark Boorer
1. OpenEXR 2. OpenColorIO 3. OpenImageIO 4. OpenColorIO tools The core OCIO library doesn't depend on OIIO, only the extra tools. On Thu, 8 Aug 2019, 19:24 Alex Hughes, <alex@...> wrote:
|
|
Re: Compile order for OCIO, OIIO, OpenExr?
Alex Hughes
From my understanding, OpenEXR can simply be built first. The OCIO and OIIO thing gets a bit more complicated for those two but I have never had complications where I would not build OpenEXR first -Alex On Thu, Aug 8, 2019 at 7:01 PM Steve Hwan <svhwan+opencgi@...> wrote:
|
|
Compile order for OCIO, OIIO, OpenExr?
Steve Hwan
I asked Larry a variation of this at DigiPro and he suggested I ask on this list, as the answer was mildly complicated.
I observed OCIO and OIIO had build dependencies on each other, so I was wondering if there was a recommended build order? (And now that I'm asking, I'll throw OpenExr into the mix for the question as well - are there any dependencies on OCIO? Or is it as simple as "Just build OpenExr first."?) -Steve |
|
Setting OCIO->Displays->Active in RV
Ravindra Korde
Hi All,
Every time after loading a ocio.config file in RV i have to go to the ocio menu & select displays to active. so I'm trying to set displays to active automatically as i load a config file, but i couldn't find anything it.
I have search for it in every .mu file in RV which supports to assignments.
Can anyone have any idea how to do it in RV?
|
|
SIGGRAPH 2019 - OpenColorIO Birds of a Feather
Michael Dolan
Hello all,
We held the OpenColorIO Birds of a Feather yesterday at SIGGRAPH in LA. Thank you to everyone who could join us! We directly followed the ACES BoF and both events had very good attendance. For those who couldn't be there, we recorded the meeting and will make the video available following SIGGRAPH. I opened the BoF with a project update covering our ASWF incubation status, related improvements to the OCIO build and CI systems, and a summary of Thomas Mansencal's work on the ACES 1.1 OCIO config. Doug Walker and Patrick Hodoul then outlined their progress and roadmap for OCIO v2, as well as discussing support for new pixel formats, ACES output transforms, CLF, and measurable CPU renderer performance gains. Lastly, Mark Boorer gave an overview of his work on the companion OpenColorMath library, covering its design, interface, and vision for where to take it next. The presentation slides are attached to this thread, where you can find a detailed outline of the information presented. Feel free to respond with any questions or points of discussion. I wanted to also give a big thanks to Emily Olin, John Mertic, and the rest of the Linux Foundation team for skillfully organizing this event (as well as 9 other open source BoF meetings for Open Source Day!). Thanks! |
|
Cancelled Event: OpenColorIO TSC meeting (weekly) - Monday, 29 July 2019
#cal-cancelled
ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
Cancelled: OpenColorIO TSC meeting (weekly) This event has been cancelled. When: Where: Organizer: Description: Meeting notes listed by YYYY-MM-DD.md format at: Join Zoom Meeting https://zoom.us/j/924729729 One tap mobile +16699006833,,924729729# US (San Jose) +16465588656,,924729729# US (New York) Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New York) +1 877 369 0926 US Toll-free +1 855 880 1246 US Toll-free Meeting ID: 924 729 729 Find your local number: https://zoom.us/u/abo9cwSMxj |
|
Re: TruelightTransform?
> A transform plugin API
When looking for the plugin keyword in the former ocio-dev from google group, I found several threads with some around ExpresssionTransform. Is that the same discussion? https://groups.google.com/forum/#!searchin/ocio-dev/plugin%7Csort:date/ocio-dev/n2t5I3gpY94/PSFJkdbTRS8J https://groups.google.com/forum/#!searchin/ocio-dev/plugin%7Csort:date/ocio-dev/IYAWizXEJfM/Q0kjpVkrSTYJ > Regarding TrueLight, it seems like we're in agreement that it should be removed. That's a good 'good first issue' defect :-) |
|
Re: R3D support?
Troy Sobotka <troy.sobotka@...>
It’s a proprietary binary blob with a license that is utterly incompatible. With respect, TJS On Mon, Jul 22, 2019 at 3:03 PM Alex Hughes <alex@...> wrote: Oof I posted this in OCIO not OIIO |
|
Re: R3D support?
Alex Hughes
Oof I posted this in OCIO not OIIO
Please ignore :S |
|
R3D support?
Alex Hughes
Hey I was wondering if OIIO supports reading r3d files.
I was looking through the release notes for libraw and that states that it could read r3d files. https://www.libraw.org/node/1299 However, that was in 2011 and I would imagine things could have changed since then. My oiiotool seems to seg fault when I try to read r3d files and I was wondering if ti was even supposed to support r3d or if my build was just broken in some way. I know Red likes to sell their SDK, but I was sort of hoping that LibRaw had an implementation that we could rely on. Thanks -Alex |
|
Re: TruelightTransform?
Michael Dolan
Thanks for your input everyone, and for the background Malcolm. A transform plugin API sounds like a good topic to resurrect. If there isn't an issue in GH (I did a quick search, but didn't see one), it would be worth starting one for further discussion.
Regarding TrueLight, it seems like we're in agreement that it should be removed. |
|
OCIO Birds of a Feather 2019
Michael Dolan
If you're attending SIGGRAPH in LA this year, we hope you'll join us for the OpenColorIO Birds of a Feather!
We'll be presenting updates on the ASWF adoption process, recent and upcoming work toward OCIO v2, and some other exciting developments from within the community. There will also be time for questions and discussion. If you can't make it, we'll be recording the event and will share the video following SIGGRAPH. The OCIO BoF is a part of Open Source Day at SIGGRAPH, which is being hosted by the ASWF. Our time slot is directly following the ACES BoF in the same room. Learn more about Open Source Day here: https://www.aswf.io/siggraph2019/ This is a great opportunity to connect face to face and learn how you can get involved in the project. It's been a very productive year, and next year is poised to continue that trend. Thank you to everyone who has participated. See you in LA! Event details: Tuesday, 30 July 2019, 3pm - 4pm Diamond Ballroom 7-10, JW Marriott |
|
Re: Ninja build fails, Unix Makefile build works
Gonzalo Garramuño
El 19/7/19 a las 11:13, Patrick Hodoul
escribió:
Hi Gonzalo,Patrick, thanks for the tip about jom (didn't know it existed). However, my problem was compiling on linux. -- Gonzalo Garramuño |
|