what is the fastest way to load all subimages from animated WEBP file?

[klydeid]

here is what i tried, i use ImageInput::open() function to load the webp file in thread and read image data to a vector by using the function read_scanlines(int subimage...).
it will get what i want but a little bit slow for me.

what is fastest way to do this?
thanks.

[lgritz]

Well, first, let me give the disclaimer that webp is not a very commonly used format by most OIIO power users (it never comes up in a VFX or animation context, that I've ever heard), so it's possible that there are performance problems lurking that we just haven't noticed.

As general advice, I will say that the following applies to all image types:

• If you're reading the whole image, use read_image rather than read_scanline or read_scanlines calls individually.
• It will be faster if the "format" (i.e. data type) of the buffer you are reading into matches the data type in the file. That is, reading uint8 file pixels -> a uint8 buffer is faster than something that would require a data type conversion along the way (such as converting uint8 -> float).
• It will be faster if you are sure that the strides for the buffer you're passing for it to read to is "contiguous" -- i.e. tightly packed RGBRGBRGB... with no extra padding between pixels or between scanlines. (Contiguous is the default, if you are not passing explicit strides, but I thought I'd mention this just in case.)
• Also you mentioned that you read into a "vector". If you really mean a C++ std::vector, then you should know that std::vector always zeroes out the data when it is resized, so that means you may be writing 0 values in all that memory, and then immediately writing over it again with the pixel data. This can have a big performance impact, since not only are you touching that memory twice, but you may also be pushing other things out of L2 or L1 cache in the process. It is better to allocate a buffer with std::unique_ptr<T[]> buf(new T[size]), which will leave it allocated but uninitialized, then pass buf.get() to the ImageInput read functions.

Assuming all this is squared away, next I would recommend just benchmarking webp reads against other formats like TIFF or maybe PNG. Is it slow compared to other formats?

If it seems slow in comparison to other formats we support, then there are several other avenues to pursue. There may be improvements possible in our webpinput.cpp (glancing at it, I can think of several, but let's establish if this is the case before I go into a lengthy explanation). It could, I'm sorry, also turn out to be that we are doing fine on the OIIO side, but that the webp library we are depending on is not very performant. Or that the OIIO+webp is fine, but your app is where the trouble is. Or it could be that it's all written as good as it can be, but there's just a maximum rate at which the webp can be read from disk and decoded. But like I said, the first step is to try the general suggestions above, and then to benchmark against other OIIO-supported file types (as close to apples-to-apples comparison as possible -- same image, same channels, same data type).