A few more technical details for this crowd: Larry's work on adding the new writable image cache was key to enabling support for huge images in Photospector.
The virtual texture engine in Photospector needs a tiled mipmap to work. Creating a mipmap for a gigapixel image on a mobile device requires that we downsample the image without loading the entire image into memory at one time (iPads only have 1GB of memory for the OS and all active apps). Worse, iOS has special permissions on the gallery image files which prevent us from directly opening them using OIIO. To work around these two problems Photospector starts by streaming the gallery image file to a local cache file which we then open using an ImageCache-backed ImageBuf. This extra copy of the file is pretty fast on the iPad's SSD. Then we use the new writable-IC and create an ImageInput which downsamples tiles on demand using the threaded ImageBufAlgo functions and write out the resulting miplevel. This allows us to create individual downsampled tiles rather than using the old make_texture path which read in the entire image and then downsampled each level in its entirety. Once we got that basic mechanism working, we found a big perf issue -- when tiles are flushed from the IC, we would need to recompute them using the special ImageInput we made, and, with a huge gigapixel image, we often thrashed cache and had to re-compute tiles dozens of times as we worked on the smaller levels in the mipmap. We fixed that by writing each tile to two files each time we downsampled it: once to the final, full mipmap, and a second time to a one-level tiled file for each level. Instead of recomputing each tile as it goes out of cache, we'd first look into the one-level tiled file and use that to stop the recursive descent through all the mipmap levels. Again, this results in more disk I/O, but with the SSD, it turns out that the performance difference is negligible even in the case that we do stay entirely in the IC without thrashing. After Photospector ships later this week, I'll be cleaning up the code we wrote for this new, low-memory-footprint make_texture path and sending out a pull request. I should also add that Photospector relies heavily on OIIO for image output, again using the streaming output to enable output of gigapixel-sized files. This works in tandem with the tiled rendering engine in Photospector which performs color correction using the GPU. We also use OIIO's metadata support for both input, output and display of the metadata. These are hugely important features that help bring real industrial-strength image management to mobile, and it is all thanks to OIIO! One last thing: sorry about the spelling error in the Gigapixel image. My mom, an English teacher, does not know about it yet, and I really hope she doesn't see that video before I get a chance to fix it! Many thanks to the entire OIIO team, and most especially to the MANY HOURS of work put in by Larry on these specific features as well as his gargantuan effort on OIIO in general. On Mon, Jul 15, 2013 at 11:37 PM, Larry Gritz <[email protected]> wrote: > Here's a fun blog post from our own Dan Wexler, about the new app he's > developing and its approach to handling very large images: > > http://www.the11ers.com/photospector/gigapixels/ > > (more general info on the app: http://www.the11ers.com/photospector/) > > -- > Larry Gritz > [email protected] > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
