Re: New header, 0.5.0, now posted
Jeremy Selan <jeremy...@...>
On Apr 22, 11:31 am, Larry Gritz <l....@...> wrote:
Random questions:Yah, the simple version is what we've had for 6 years. I added the
direction parameter for completeness yesterday. On second thought,
I'll drop it. ;)
Any reason why 'long' rather than 'int' in so many places? (I'm notI'm just super used to working in CPython land so often they look
natural to me. (Python's native 'Int' data type is long - so using
them all over makes writing python glue a tiny bit more braindead).
But this is not a great reason to use longs, i'll roll it back.
Any role for OpenCL in addition to GLSL and Cg?Sure, if anyone ever needs it it would make good sense. Does OpenCL
support accelerated 3d texture lookups? If so, it'll map well.
Otherwise, a bit more complex but still do-able. Probably not for 1.0
Do you think "FilmLook" might seem anachronistic in the future or hurtYah, I agree FilmLook is not very forward-looking. I like your ideas,
I'll probably steal one of em.
Yes, these names are redundant. I'll shorten them up. I think part
of the reason I went for a long name is that I've been looking at the
code for so long (at least a prior version) that I'm a bit dead to
it. Fresh eyes on an API help quite a bit.
ImageView will surely need pixel accessor methods.Not externally, is my hope. Once the user constructs an ImageView,
other than passing it in I dont want them to call anything on it.
Internally, I can decorate the Imp with any private accessors I'd like
What does ColorSpace::isData() do?Colorspaces that are 'data' are a bit special. Basically, any
colorspace transforms you try to apply to them are ignored. (Think of
applying a ColorCorrection to an ID pass). Also, in the Filmlook pass
it obeys special 'data min' and 'data max' args. I will document it
Thanks for all the comments! They are hugely appreciated.
Subscription settings: http://groups.google.com/group/ocs-dev/subscribe?hl=en