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]] on behalf of Larry Gritz [[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 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 -- Larry Gritz [email protected]<mailto:[email protected]>
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
