-1 for the middle ground (template internal, float external). It
will make the internal implementations harder to read, harder to
write, and harder to maintain. My preference is that we're going to
only expose float in the API, let's just keep it simple interally and
write it assuming float. If
On Sat, Jun 30, 2012 at 9:54 AM, Larry Gritz wrote:
> Another possibility: write the functions as templates (as we have),
> call them only for variations, leave them where they are (not
> a separate header), but then they are "shovel ready" if we ever want
> to expose them in some other way, or f
On Sat, Jun 30, 2012 at 10:17 AM, Jeremy Selan wrote:
> For all those who would like to expose either templated versions, or
> versions with non-float types...
I'm ok with either choice, just providing options.
> Do you have any specific clients of the API in mind? Can you provide
> details?
No
For all those who would like to expose either templated versions, or
versions with non-float types...
Do you have any specific clients of the API in mind? Can you provide details?
-- Jeremy
On Fri, Jun 29, 2012 at 4:54 PM, Larry Gritz wrote:
> Another possibility: write the functions as templat
Another possibility: write the functions as templates (as we have), call them
only for variations, leave them where they are (not a separate header),
but then they are "shovel ready" if we ever want to expose them in some other
way, or for people to copy into their own code.
So functionality l
On Sat, Jun 30, 2012 at 5:41 AM, Larry Gritz wrote:
> Still, I am haunted by a key question: does the support of all the
> types merely seem nice and general to us idealists, or does anybody
> actually want and need such functionality?
Ah, simplicity vs generality... always a hard call :)
Given
+1 for float only
On Fri, Jun 29, 2012 at 1:38 PM, Jeremy Selan wrote:
> +1 for float only.
>
> -- Jeremy
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
_
On Jun 29, 2012, at 1:30 PM, Stefan Stavrev wrote:
> I can't think of other solution for supporting all types.
>
> I would vote for small subset of types, but after some years, what if there
> are 100 or 200 functions that will need type specialization. Even having 4
> types will be a problem I
+1 for float only.
-- Jeremy
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
I can't think of other solution for supporting all types.
I would vote for small subset of types, but after some years, what if there
are 100 or 200 functions that will need type specialization. Even having 4
types will be a problem I guess, 4^3 for 3 input images and 4 types, is
still not small.
Unfortunately, that would require the iterators to be polymorphic, i.e. having
virtual methods rather than being templated and inlined. That would surely
ruin performance of the iterators.
I suppose we could make a separate, slow "all type" iterator, and have two
versions (perhaps via template
It would be amazing if all types are supported.
Analysis of the problem: The typical case is two input images A and B, and
one output image R. Each can be one of 11 types. The problem with the
current approach is that we have a cross product of the 11 types, resulting
in 11^3 madness. Can we get a
There are some questions about whether the growing (or for that matter,
existing) collection of ImageBufAlgo image processing utilities ought to handle
the full range of pixel data types OIIO supports when reading and writing
files. Resolving this problem is especially important for "binary" im
13 matches
Mail list logo
