Hi guys, I've been staying out of this thread because I don't have much of an idea on the "how other programs handle this" front... however -
On Wed, Oct 19, 2011 at 4:34 PM, Larry Gritz <[email protected]> wrote: > [...] Basically, it's a nightmare, would make hard-to-follow (and probably > buggy) code, and have a lot of the tricky bits replicated across many > different ImageOutput subclasses. No way. Hear hear :-) I agree with what you're saying from an API point of view - the individual ImageOutput classes shouldn't have to handle this. One comment: > c) Add a simple, single utility function to handle the auto crop/pad: > > ImageBufAlgo::FixToDisplayWindow (ImageBuf &img, const std::string &format) A possible alternative to this API would be to have class DisplayWindowFixup : public ImageOutput { /*...*/ } for those people who want ImageOutput to handle this kind of thing - they just need to wrap their ImageOutput in a DisplayWindowFixup class. For everyone else, no problems; nothing changes. It also puts any tile buffering logic in one place and means you can in principle avoid buffering the entire image if desired (I guess this is implied by the ImageBufAlgo::FixToDisplayWindow API?) I'm not sure whether the details of this API matter much, but it's one more idea to add to the mix in case people have a specific use case where having an ImageOutput do the work would be better. ~Chris _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
