Of those types, HALF is the only one you need to deal with (the others are
non-numeric types, and so can never be the types of pixels in an ImageBuf).
The C data type corresponding to TypeDesc::HALF is 'half'.
Look at the implementation of ImageBufAlgo::crop, for example. (crop only
takes one source image argument, however, so it's a little less complicated,
but you can see how it specializes by type)
Also, from your pastebin:
case TypeDesc::UCHAR :
case TypeDesc::UINT8 :
return over_impl_RAB<Rtype, Atype, unsigned char> (R, A, B, roi);
break;
There's no need to specify both of these, they are the same value. Just stick
to the '[U]INTnn' ones, don't worry about CHAR, SHORT, LONG.
On Jun 9, 2012, at 2:56 PM, Stefan Stavrev wrote:
> You are right Larry. Having a second look on things, it seems I forced myself
> into some OO design. It is still early to bother with design at this point. I
> will keep it simple now and have just one function for over and additional
> helper static methods.
>
> Anyway, about the functions you talked about yesterday over_impl, over_impl_R
> and over_impl_RA, for handling all internal pixel data types. I am trying to
> deal with all types in the enum BASETYPE for TypeDesc:
>
> http://pastebin.com/9trn5sNn
>
> I don't know how to handle these types:
>
> 1. TypeDesc::UNKNOWN
> 2. TypeDesc::NONE
> 3. TypeDesc::HALF
> 4. TypeDesc::STRING // std::string or char* ?
> 5. TypeDesc::PTR
> 6. TypeDesc::LASTBASE
>
> Stefan
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
