|
Re: Is the const type qualifier only in CG?
Malcolm Humphreys <malcolmh...@...>
hmmm tried to do that last night, but something went left of field. I now have a branch thats up to date with imageworks/master but the commits are in the future.. doesn't really matter as I'm hoping to roll all the photoshop commits into one as their was a lot of unnecessary code in my initial commit.
toggle quoted message
Show quoted text
.malcolm On 19/01/2011, at 5:08 AM, Jeremy Selan wrote:
That's no problem at all. |
|
|
|
Re: Is the const type qualifier only in CG?
Jeremy Selan <jeremy...@...>
That's no problem at all.
FYI, this really easy to solve with the 'rebase' command. Say you have a branch and you want to incorporate all changes on spi/master. (I've already setup the spi remote, I am including my .git/config file as an example. copy the 'spi' remote if you'd like). git fetch --all (to get all branches up to date locally) git checkout photoshop (your branch name)If everything works, your new commits will be 'replayed' upon the latest spi/master tree, bringing you up to date. If the rebase doesn't work, you can always revert back with git rebase --abort. -- Jeremy On Mon, Jan 17, 2011 at 4:36 PM, Malcolm Humphreys <malcolmh...@...> wrote: Whoops, I should live by that mantra 'update or die'. I have a few |
|
|
|
Re: Is the const type qualifier only in CG?
Malcolm Humphreys <malcolmh...@...>
Whoops, I should live by that mantra 'update or die'. I have a few
toggle quoted message
Show quoted text
too many different checkouts of ocio, still a bit in svn land, goto to get used to using local git branches. This fixed this issue as well. :) .malcolm On 18/01/2011, at 10:30 AM, Jeremy Selan wrote:
Yes, if you look att Processor.cpp : 381, you'll see that on apple |
|
|
|
Re: Is the const type qualifier only in CG?
Jeremy Selan <jeremy...@...>
Yes, if you look att Processor.cpp : 381, you'll see that on apple
toggle quoted message
Show quoted text
platforms we always insert a sampling of the tex2 even if it's not needed. It appeared that without this, if the 3dlut was unused it would be incorrectly optimized away and the app would crash. In your shader you should see a line that looks like, "// OSX segfault work-around: Force a no-op sampling of the 3d lut." are you seeing this line and still having the crash? What platform are you on? -- Jeremy On Mon, Jan 17, 2011 at 3:27 PM, Jeremy Selan <jeremy...@...> wrote:
I already fixed this too; thought it was checked in last week. hold |
|
|
|
Re: Is the const type qualifier only in CG?
Jeremy Selan <jeremy...@...>
I already fixed this too; thought it was checked in last week. hold
for details. -- Jeremy On Mon, Jan 17, 2011 at 3:21 PM, Malcolm Humphreys <malcolmh...@...> wrote: I'm having an unrelated problem when using a noop processor eg. scene_linear -> data on the gpu. |
|
|
|
Re: Is the const type qualifier only in CG?
Malcolm Humphreys <malcolmh...@...>
I'm having an unrelated problem when using a noop processor eg. scene_linear -> data on the gpu.
toggle quoted message
Show quoted text
I'm getting a EXC_BAD_ACCESS when issuing glBegin(GL_QUADS). Having another shader for this case which doesn't reference 'tex2' fixes the problem. I have looked into it a little but it isn't clear why this is happening. I'll be trying to commit some code that shows this soon. .malcolm On 18/01/2011, at 9:13 AM, Jeremy Selan wrote:
No problem! Let me know if you have any troubles with the updated version. |
|
|
|
Re: Is the const type qualifier only in CG?
Jeremy Selan <jeremy...@...>
No problem! Let me know if you have any troubles with the updated version.
I should also probably update the ociodisplay program to query the glsl version, and select the best profile accordingly. -- Jeremy On Mon, Jan 17, 2011 at 1:46 PM, Malcolm Humphreys <malcolmh...@...> wrote: Oh snap, you have already fixed this. I haven't updated for a few days. |
|
|
|
Re: Review: Building/config related docs
Jeremy Selan <jeremy...@...>
Committed.
Thanks! -- Jeremy On Sun, Jan 16, 2011 at 4:38 PM, Malcolm Humphreys <malcolmh...@...> wrote:
|
|
|
|
Re: Is the const type qualifier only in CG?
Malcolm Humphreys <malcolmh...@...>
Oh snap, you have already fixed this. I haven't updated for a few days.
toggle quoted message
Show quoted text
Sorry for the list noise. .malcolm On 18/01/2011, at 8:38 AM, Jeremy Selan wrote:
Those who are having trouble with GLSL, are you on the most recent |
|
|
|
Re: Is the const type qualifier only in CG?
Jeremy Selan <jeremy...@...>
Those who are having trouble with GLSL, are you on the most recent
version of OCIO? I made a commit last week (which is in version 0.7.5), where on OSX the const keyword would be omitted for GLSL 1.0 (which is what should be used on OSX). If you see line 79 in http://github.com/imageworks/OpenColorIO/blob/master/src/core/Processor.cpp And I confirmed that the ociodisplay app works on my osx 10.6.6 install. (A macbook laptop). You'll see that in OCIO we currently distinguish the profile options between GLSL 1.0, 1.3, and GG. And that only the CG and GLSL 1.3+ profiles use the const identifier. My hope was that we could get by with the minimum language options necessary, and only add new glsl versions if/when new language features are necessary. -- Jeremy |
|
|
|
Re: Is the const type qualifier only in CG?
Malcolm Humphreys <malcolmh...@...>
Hi Mark,
toggle quoted message
Show quoted text
Thanks for the reply, well that makes sense why it hasn't really been an issue till now. How would you recommend to solve these types of issues? I can see two obvious ways. if/then blocks with it all mixed together like we are doing, or having it all separated out with cg, glsl_1.2, glsl_1.5 etc paths. It doesn't seem to be a clean way to do this and both are kind of sucky. .malcolm On 18/01/2011, at 8:09 AM, Mark Alexander wrote:
There is a const qualifier in GLSL, and it should work on other |
|
|
|
Re: Is the const type qualifier only in CG?
Mark Alexander <malex...@...>
There is a const qualifier in GLSL, and it should work on other
platforms without issue. The difference may be that OSX only supports GLSL 1.20 currently, which is far behind most of NVidia's and ATI's OpenGL implementations (GLSL 1.50 at least, more likely 3.30/4.10). Perhaps this is the reason 'const' is required. Having a shader compile across multiple GLSL versions and drivers can be tricky, and I've run into a lot of issues on OSX that are simply GL version related. Mark On Jan 16, 11:39 pm, Malcolm Humphreys <malcolmh...@...> wrote: Is the 'const' qualifier in glsl? I have to change the following to get the glsl shader to compile on OSX. |
|
|
|
Is the const type qualifier only in CG?
Malcolm Humphreys <malcolmh...@...>
Is the 'const' qualifier in glsl? I have to change the following to get the glsl shader to compile on OSX.
I'm cool to add another if glsl or cg block, just wondering if this could be something else. .malcolm diff --git a/src/core/Processor.cpp b/src/core/Processor.cpp index 2f0f83b..c22770f 100644 --- a/src/core/Processor.cpp +++ b/src/core/Processor.cpp @@ -81,7 +81,7 @@ OCIO_NAMESPACE_ENTER } else throw Exception("Unsupported shader language."); - shader << " const uniform sampler3D " << lut3dName << ") \n"; + shader << " in sampler3D " << lut3dName << ") \n"; shader << "{" << "\n"; if(lang == GPU_LANGUAGE_CG) |
|
|
|
Review: Replaced config->getRoleNameByIndex
Malcolm Humphreys <malcolmh...@...>
When building some UI menus, I wanted to get a list of defined roles. Config::getRoleNameByIndex() only returned the resolved colorspace name.
--snip-- Replaced config->getRoleNameByIndex (which returned the colorspace name, not the role name) with the following: - getRoleName(int): get the role name at index, this will return values like 'scene_linear', 'compositing_log'. Returns NULL if index is out of range - getRoleColorSpaceName(int): get the actual colorspace name at role index. Returns NULL when index is out of range - getRoleColorSpaceName(char*): get the actual colorspace name from a role name. Returns NULL if roles is not defined --snip-- https://github.com/malcolmhumphreys/OpenColorIO/commit/d7c8094f6aad57f980060e87d0f547ff36d844b7 .malcolm |
|
|
|
Re: Review: Building/config related docs
Malcolm Humphreys <malcolmh...@...>
LGTM
LGTM This is a good fix till we add boost/shared_ptr.hpp to ocio or replace it with tr1/memory in OpenColorTypes.h. Right now you need boost on linux to build. .malcolm
+1 .malcolm |
|
|
|
Context/per-shot grades
"dbr/Ben" <b...@...>
If I understand correctly, the Context allows you to set a search path including env-variables (e.g $SEQ/$SHOT), so you can define a FileTransform, and it'll look in the shot's directory before the "default" directory? (just figured this out after writing the remainder of this email, so it might right slightly oddly..)
I wonder, could (or does) the context system allow parameterised transforms? E.g in pseudo-YAML: context-values: ab: ab-123: slope: [2, 1, 1] default: slope: [1, 1, 1] displays: - !<Display> {device: sRGB, name: "Film Graded", colorspace: srgb8_graded} colorspaces: - !<ColorSpace> name: srgb8_graded family: srgb bitdepth: 8ui isdata: false from_reference: !<GroupTransform> children: - !<CDLTransform> slope: $slope offset: [0, 0, 0] power: [1, 1, 1] saturation: 1 - !<ColorSpaceTransform> {src: lnf, dst: lg10} - !<FileTransform> {src: filmemulation.spi3d, interpolation: linear} Possibly better to explain what I'm trying to achieve: Say I have grades for a several shots, which should be used to view the comp (a CDL grade, or printer light offset etc). I could create a group transform containing: the parameterised colour transform, the log'ification and display LUT. Then you'd just need a simple script to populate the config with grade values (e.g from Shotgun) The same concept could maybe be extended for, say, creating neutrally graded plates (a GroupTransform that linearises and applies a grade), but I can think of various problems/complexities with this, so it'd probably be simpler doing this with a modified version of the ocioconvert tool or something (as grading plates isn't a shot-specific thing, it's a scan specific thing, so the context would have to be based on file paths, which isn't something OCIO could really parse) Hmm, being able to have per-shot FileTransform's (using the Context dynamic search path) is probably enough, e.g: children: - !<FileTransform>: {src: grade.spi1d} - !<ColorSpaceTransform> {src: lnf, dst: lg10} - !<FileTransform> {src: filmemulation.spi3d, interpolation: linear} Although it would be nice to avoid writing a file per shot, and avoid turning a nice simple tuple3f into a LUT or transform matrix (then again, I've done per-shot LUT's in the past and it wasn't a problem, plus those files had to contain both the 1D grade and the 3D display LUT) Hope some of that made sense - sorry for the slightly long-and-rambling email! - Ben |
|
|
|
Re: Review: Building/config related docs
"dbr/Ben" <b...@...>
On 14/01/2011, at 7:23 AM, Malcolm Humphreys wrote:
Also a slightly-unrelated change, but for some reason when building on OS X, Boost was not optional, as Boost_INCLUDE_DIR was used in core, pyglue and testbed. Not entirely sure this is the right solution, but it works for me.. On 14/01/2011, at 4:41 AM, Jeremy Selan wrote:
Do you mean having the http://opencolorio.org site be generated from the latest version's Sphinx docs? Or the sphinx docs be accessible from the site's "Documentation" link? I think the former could be sensible - keep all the documentation in the git repository, so it is always in sync with the code, and make is simple to get the docs as they were for a given version Should be pretty simple to tweak Sphinx so it works nicely as a homepage (with a nice intro page instead of just the table-of-contents and so on) - Ben |
|
|
|
Re: Review: Building/config related docs
Malcolm Humphreys <malcolmh...@...>
rock and roll these docs are great. The only thing I can see is missing is a section on NUKE_PATH in the environment section. .malcolm On 14/01/2011, at 1:11 AM, dbr/Ben wrote:
|
|
|
|
0.7.5 Released
Jeremy Selan <jeremy...@...>
**Version 0.7.5 (Jan 13 2011):**
* ociodisplay enhancements * gpu display bugfix (glsl profile 1.0 only) * Makefile enhancements * Nuke installation cleanup * Doc generation using sphinx (html + pdf) Matching documentation (pdf/html) will be posted later today. |
|
|
|
Re: Review: Building/config related docs
Joseph Slomka <jsl...@...>
This makes sense as you get to release. The code gets the most frequent updates and the webpage represents the current used version.
toggle quoted message
Show quoted text
-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Jeremy Selan Sent: Thursday, January 13, 2011 10:11 AM To: ocio...@... Subject: Re: [ocio-dev] Review: Building/config related docs Oh, and an observation: we now essentially have two masters for the docs, the inline documentation, and the webpage version. My inclination is to treat the git version as the master, and then to do periodic html / pdf drops to the website. I'm thinking I could make docs and post them for every dot release. Thoughts? -- Jeremy On Thu, Jan 13, 2011 at 10:08 AM, Jeremy Selan <jeremy...@...> wrote: Looks good to me. |
|
|