Ugh, sorry. I'm in the middle of production builds now, it's really the straight-out lanczos3 I need to get done today.
I will immediately return to fix radial-lanczos3 and disk and submit another PR. I think I'm ok backporting to 1.5 (I already tried the merge, it does so with no conflicts), but before doing so on the main repo I would like to leave it in master long enough to be more confident that I haven't broken anything or changed behavior that was ok before. If nobody complains about its presence in master after a couple weeks, I will backport it to 1.5. > On Oct 6, 2015, at 9:43 AM, John Haddon <[email protected]> wrote: > > I now realise I was a bit hasty earlier - catmull-rom and lanczos3 are fine > but the problem persists with radial-lanczos3, because although the filter > table is updated to say it's scalable, the constructor is still ignoring the > width/height arguments. > > Aside from that, do you think there's a chance of a backport onto RB-1.5, or > would this be classed as a change of behaviour rather than a bug fix? > > Cheers… > John > > From: Oiio-dev [[email protected]] on behalf of Larry > Gritz [[email protected]] > Sent: Tuesday, October 06, 2015 7:39 AM > To: OpenImageIO developers > Subject: Re: [Oiio-dev] Upsizing with a non-scalable filter > > Cool, great to have the confirmation, John. > > I've got a bit of an emergency here with lanczos3, so I'm going to commit > what I have immediately and get some builds to production, but then I'll take > a second pass at it and see what can be done about disk. > > >> On Oct 6, 2015, at 6:02 AM, John Haddon <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks Larry - that PR seems to do the job for me, and having the scaling >> done inside the filter rather than having to build in additional >> special-case scaling outside as I was considering seems much better from an >> implementation perspective. >> >> The disk filter does still actually display a similar problem, because it >> has a default width of 1, which is small enough that even when scaled it can >> fall through the cracks : >> >> oiiotool --create 10x10 3 --fill:color=1,1,1 0,0,10,10 --resize:filter=disk >> 100x100 -o test.png >> >> Unless you think that's worth bothering with, I think I'm quite happy to say >> "disk ain't for resizing" and omit it from the options in my particular use >> case. >> >> Thanks… >> John >> >> From: Oiio-dev [[email protected] >> <mailto:[email protected]>] on behalf of Larry Gritz >> [[email protected] <mailto:[email protected]>] >> Sent: Monday, October 05, 2015 5:54 PM >> To: OpenImageIO developers >> Subject: Re: [Oiio-dev] Upsizing with a non-scalable filter >> >> Funny you should mention this! (And sorry for the delay, I think this got >> lost in the post-SIGGRAPH coma.) >> >> I came across this again today on my side, and finally decided to make those >> fixed-width filters able to resize to whatever width is specified (with the >> default width being the "usual" one). It was just catrom and lanczos3 that >> were like this. >> >> Here's the PR for it: https://github.com/OpenImageIO/oiio/pull/1228 >> <https://github.com/OpenImageIO/oiio/pull/1228> >> >> In a practical sense, this seems to work just fine -- the results seem >> reasonably pleasing to my eye, and match some other software we tried. >> >> Want to give it a shot and see if it matches your expectations now? >> >> -- lg >> >> >>> On Aug 26, 2015, at 8:00 AM, John Haddon <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, >>> >>> First off, a confession. I'm not too familiar with image processing stuff, >>> so when I needed some resizing code for a tool I was writing, I based mine >>> heavily on ImageBufAlgo's resize(). Thanks for the excellent resource. >>> >>> In this tool, the user specifies both the image size and also the filter, >>> which led to the eventual realisation that OIIO's resize (and therefore my >>> homage) doesn't upsize with non-scalable filters, as demonstrated in this >>> invocation of oiitool : >>> >>> oiiotool --create 10x10 3 --fill:color=1,1,1 0,0,10,10 >>> --resize:filter=catrom 100x100 -o test.png >>> >>> It seems that when upsizing, the filter falls through the cracks between >>> source pixels, because the constructor for catmull-rom and lanczos filters >>> ignores the width, and the filter radius is therefore much smaller than the >>> sampling code expects. This means that much of the resized image is black >>> rather than the expected white. >>> >>> In my ignorance, I'm wondering what is the right thing to do here, from an >>> image processing perspective? Presumably I could just adjust for the fact >>> that the filter is created smaller than expected, and scale the lookup >>> locations on the way in, but is that meaningless? Are these filter types >>> simply not intended for upscaling? Would it be better to silently >>> substitute in a different filter, or perhaps to raise an error? >>> >>> Thanks in advance for any suggestions you could provide... >>> Cheers... >>> John >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
