In your example, is the native type float linear?
Presuming so, I would check two things. In your gpu version, make
sure that the gpu texture buffer you're loading into is floating
point. You'll want to make sure you're using something like
GL_RGB16F_ARB (as opposed to GL_RGB). If you were referencing the
ociodisplay app as an example, it unfortunately makes exactly this
mistake. (It's fixed though in my most recent code submission, not
yet rolled into the trunk).
The other thing to check is the allocation for the colorspace. The
allocation determines, if a 3d lut stage is necessary, how to perform
the allocation. For 'typical' HDR data, I would recommend something
like,
allocation: lg2
allocationvars: [-12, 6]
What this means is that the gpu should sample the colorspace using a
logarathimic allocation (code value proportional to stops), from
2**-12, to 2**6. I.e., anything less than 0.0002 or greater than
64.0 is clamped.
-- Jeremy
On Wed, Jan 12, 2011 at 9:13 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
While working on this ocio photoshop plugin I noticed a difference in the cpu vs gpu path.
Attached is a screenshot.
The image on top has been imported by the plugin already and processed on the cpu, while the dialog below is a GL canvas using the gpu path for preview.
I'm guessing this is the allocation we are using on the gpu?
.malcolm
