That's it exactly: For texture mapping, the [0-1] domain of texture lookups map to the "display window", and texture "clamp" mode is equivalent to using texture coordinate to clamp(x, 0, 1). So when we introduced wrap modes to ImageBuf iterators, we made it behave the same way.
> On Mar 29, 2022, at 12:09 AM, Nathan Rusch <nathanru...@gmail.com> wrote: > > Hmm, I feel like I may be overlooking something obvious, but the canonical > scenario I'm imagining looks something like: > > ┌─────────────────────────────────┐ > │ │ > │ ┌───────────────────────┐ │ > │ │ │ │ > │ │ │ │ > * │ │ │ │ > Iterator │ │ │ │ > position │ │ │ │ > │ │ Display Window │ │ > │ └───────────────────────┘ │ > │ │ > └─────────────────────────────────┘ > Data Window > > In this case, it looks like the current `WrapClamp` behavior would result in > the iterator position above getting clamped to the display window, thus > skipping over a lot of pixel data. > > Now, even if my interpretation of the current code is correct, its entirely > possible that I'm just misunderstanding the purpose of `WrapMode`; it may be > that it was only really designed with a texture-oriented workflow in mind, > where display windows are (generally) all the matters. I just want to make > sure I understand when I can/can't rely on it. > > Thanks, > -Nathan > > On 3/28/2022 10:50 PM, Larry Gritz wrote: >> Wait, I think I said that slightly wrong. What I meant is: >> >> If we're known to be outside the data window (or do_wrap wouldn't be >> called), then there are only two cases: either we are still inside the >> display window (in which no wrap is necessary), or we're already outside the >> data window. So it all amounts to the same thing, if you follow. >> >> >>> On Mar 28, 2022, at 10:48 PM, Larry Gritz <l...@larrygritz.com >>> <mailto:l...@larrygritz.com>> wrote: >>> >>> I think this is correct. Here is the comment at the declaration of do_wrap: >>> >>> // Given x,y,z known to be outside the pixel data range, and a wrap >>> // mode, alter xyz to implement the wrap. Return true if the resulting >>> // x,y,z is within the valid pixel data window, false if it still is >>> // not. >>> bool do_wrap(int& x, int& y, int& z, WrapMode wrap) const; >>> >>> This is a private method, and so if it's only called when x,y,z is outside >>> the data window, then by definition the union of the data window and the >>> display window is... the display window. >>> >>> >>>> On Mar 28, 2022, at 8:30 PM, Nathan Rusch <nathanru...@gmail.com >>>> <mailto:nathanru...@gmail.com>> wrote: >>>> >>>> I was looking at the source of `ImageBufImpl::do_wrap` today, and I >>>> noticed that `WrapClamp` always clamps the input coordinates using the >>>> display window coordinates (`full_x`, `full_y`, `full_width`, >>>> `full_height`, etc.). >>>> >>>> I always assumed `WrapClamp` would clamp out-of-bounds coordinates to the >>>> available image area (i.e. the union of the data and display windows), but >>>> is that not the intended behavior? >>>> >>>> Thanks, >>>> -Nathan >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> >>> -- >>> Larry Gritz >>> l...@larrygritz.com <mailto:l...@larrygritz.com> >>> >>> >>> >>> >> >> -- >> Larry Gritz >> l...@larrygritz.com <mailto:l...@larrygritz.com> >> >> >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
