I dont think anyone has replied to this yet...

I wrote up a long reply a few days ago about how ImageBuf assignment
operator for 'copy' is not a great use of a C++ operator, and that perhaps
we should remove it entirely in the trunk in favor of a series of
explicitly named functions.  The fewer functions on ImageBuf, the better.
Move em to Algo. :)

But then I had second thoughts (I realized how convenient it is to do
assignment) so I never sent the email.

So I guess I'm on the fence.

But I keep coming back to thinking that perhaps removing the assignment
operator makes sense.  What I keep mulling over is that it's deceptively
hard to use the assignment operator on ImageBuf's successfully.  For
example, the src and dst sizes must match.   So assignment wont always work
when writing ImageBufAlgos.   And if you're writing client code, what do we
expect them to write?  Is this the appropriate way to do a copy on
ImageBufs?

if(srcSize == dstSize) dst=src;
else { more clever code here }

Perhaps all of the cases LG has specified could be hidden inside a suitable
ImageBufAlgo::Copy(dst, src, clearoutside=false), which would be the
preferred way to Copy pixels, and could also explicity handle different
size images.  (This would copy src area into the overlapping dst region,
and clear the remaining unfilled areas and/or channels).  The documentation
would make this explicit.

And then another function ImageBufAlgo::AdoptSizeAndChannels(dst, src).
which first changes the allocation (if allowed).

This is all just brainstorming here. I may wake up tomorrow and regret this
chain of thought...   :)

-- Jeremy

On Thu, May 3, 2012 at 9:57 PM, Larry Gritz <l...@larrygritz.com> wrote:

> As discussed an another thread, I'm working on some mods to ImageBuf to
> allow it to "wrap" a buffer belonging to the application (as opposed to
> owning the memory itself or using an ImageCache), thus allowing all the
> usual ImageBufAlgo functions to work on app memory without copying.
>
> This means that an ImageBuf can be in one of our states:
>
> 1. uninit - uninitialized, stores no image at all
> 2. ImageCache - references a read-only image backed by the ImageCache
> 3. owned - holds a full image in RAM, owns its own buffer
> 4. wrapped - points to an application-owned buffer of fixed size and data
> type
>
> The difference between #3 and #4 is simply whether the IB itself owns the
> memory (and is responsible for freeing it), or if it just holds a pointer
> to the app's memory and isn't responsible for freeing it (and neither has
> the ability to resize it or change its data format).
>
> Also, to clear up some nomenclature, let's assume the following (private)
> implementation methods:
>
> clear() - mark self as uninitialized, free any previously-owned memory
> alloc() - mark self as local/owned, allocate enough local/owned memory for
> the image
> copy_pixels() - copy pixel values (sizes & data types must already match)
> convert_pixels() - copy pixel values with data conversion (size must match)
> refer_IC() - mark as IC-backed and refer to a particular IC entry
>
> OK now.  That was all preliminaries.  Here's the question:
>
>        ImageBuf src (...);
>        ImageBuf dst (...);
>
>        dst = src;    <---- what does this do?
>
> I need to know precisely what this means for each combination of
> {uninit,IC,owned,wrapped} for both src and dst.
>
> I think assignment should be deep copy (unless both are IC-backed
> already), the state of dst is sticky (except for assignment to and from
> 'uninit'), a wrapped buffer can't change the shape or type of its buffer
> (since it doesn't own it).
>
> So here's what I've got so far, you can see there are a few cases where
> I'm still not sure:
>
>
> src          dst             action
> -----------  ------------  -----------------
> uninit
>             uninit        clear()
>             ImageCache    clear()
>             owned         clear()
>             wrapped       ?? illegal?  nop?  or clear()?
>
> ImageCache
>             uninit        refer_IC()
>             ImageCache    refer_IC()
>             owned         alloc(), copy_pixels()
>             wrapped       convert_pixels() if same size, otherwise error
>
> owned
>             uninit        alloc(), copy_pixels()
>             ImageCache    alloc(), copy_pixels()
>             owned         alloc(), copy_pixels()
>             wrapped       convert_pixels() if same size, otherwise error
>
> wrapped
>             uninit        ?? clear()?  or alloc(), copy_pixels()?
>             ImageCache    convert_pixels() if same size, otherwise error
>             owned         convert_pixels() if same size, otherwise error
>             wrapped       convert_pixels() if same size, otherwise error
>
>
> Advice appreciated, especially about the cases with question marks.
>
>
> --
> Larry Gritz
> l...@larrygritz.com
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to