Yes, they largely overlap, and you should use whichever you find best suited to 
your application.

ImageInput allows a few low-level I/O operations that are awkward or impossible 
to do with ImageBuf.  As a few examples:

* ImageInput lets you read individual scanlines or tiles on demand. An ImageBuf 
looks and acts like an entire image, hiding the specifics of exactly when the 
reads occur.

* In most images, all channels use the same data format (in fact, for most 
image file formats, it's not possible to have "per-channel data types", but 
some allow it). An ImageBuf always behaves as if all channels have the same 
data format, and will "round up" the channels to the one with the most 
precision (for example, if you had an image file with uint8 R, G, and B, but a 
float Z channel, the resulting ImageBuf will appear to have 4 float channels). 
There is a way, if you want to, to ask ImageInput to leave all the channels in 
their original data formats, so you could truly read it as 
uint8,uint8,uint8,float.

* ImageInput lets you read subsets of channels, whereas when you use an 
ImageBuf, you have no choice but to read all the channels into the buffer.

I wouldn't expect ImageBuf to be faster than ImageInput (since, underneath it 
all, ImageBuf uses ImageInput for its I/O). It might be that, since ImageBuf 
tries to use ImageCache and read lazily (and keep data in the underlying 
ImageCache for use again), your use of ImageBuf is not really doing the I/O you 
think it's doing (at least, not inside your timing loop)! 



On Dec 21, 2014, at 9:23 AM, [email protected] wrote:

> Hello,
> it`s my first post on this list, so far openImageIO is really awesome, so I 
> wish to say thank you to all contributors.
> 
> I`m experimenting Image buffer vs ImageInput for reading images in different 
> formats.
> So far I have found that Image Buffer have similar functionalities that 
> ImageInput and a bit faster than it.
> So what is the pro of ImageInput against using Image Buffer ?
> 
> Kind Regards,
> Jeremy.
> 

--
Larry Gritz
[email protected]



_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to