On Oct 5, 2011, at 3:33 AM, Hugh Macdonald wrote: > I'm going to have to (I hope you don't mind!) disagree with you on what is > considered the "image" vs what is extra information.
Not at all! That's why I wanted to get this discussion out in the open. My hope is for a number of people to weigh in so that I can get a clear idea of whether my view out of step with everybody else. > You mentioned an image with a pixel domain of 0,0 -- 15,15, embedded in a > virtual canvas with the domain -10,-10 -- 25,25. Generally, in my experience, > the display window has the origin at (0,0). Yes, you're right, usually the display window has 0,0 origin. The data window may have origin >0 (a crop window or partial image) or <0 (overscan region). We need to consider both of those cases. > Another example might be a CG render that has had an AutoDOD applied. Each > frame has the same sized displayWindow, but differing dataWindows. The data > window will also move around the display window, based on where the CG > happens to be. If I were to take this image sequence and pass it through > oiiotool to convert it to, say, jpegs, we'd end up with an image sequence > with every frame being a different size. That's one way to look at it. The other is that your JPEGs would have all the pixels (and only the pixels) that have defined values, without losing any computed pixel values or substituting new magical pixel values for previously undefined regions. I think what it comes down to is that any time you're converting from a format that supports separate display/data windows, to one that does not, somebody needs to make a high-level decision about how to resolve the discrepancy (whether to pad/crop, or lose the display window metadata). I argue strongly that pad/crop should not be an automatic behavior of the low-level ImageOutput, but rather an option to ImageBuf and/oror oiiotool. I feel less strongly that the current behavior is a good default, and pad/crop should have a command, but I'm swayable on is point. > If I were doing this from scratch, I would probably have named > width/height/full_width/full_height slightly differently. I would have gone > with: > > full_width -> width > full_height -> height > width -> data_width > height -> data_height > etc I don't always like my naming of full_width/full_height, but I stand by width/height being the pixels -- that's what it means in virtually every format (TIFF being the exemplar that gave us many of our naming conventions, OpenEXR being the main one that picked new names for lots of things, but came along after OIIO's nomenclature was established). > I think that the default behaviour should be to generate images that all have > the same total image size (ie full_width/full_height). There should then be a > function (and flag in oiiotool) to say "I actually want to make the image > just the size of the data window", which will go back to how it is currently > working. Yes, and for the other choice too: "pad/crop to be the size of the full/display size." I think our only substantial disagreement is which should be the default. > As for the stash_spec() method, I called it that because the comment on > pretty much every "m_spec = userspec;" line was "stash the spec". Maybe > "set_spec" would be a better name. It was intended as a helper function to > stop the same code needing to be put in evert image writer that didn't > support data windows. Yeah, I understand. But I think "stash_spec", or even "set_spec" is not especially self-documenting. It really means "set the internal spec to the one the user passed in". But that's also what "m_spec=userspec" means, taking no more space and leaving no ambiguity about whether any other hidden operations are performed. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
