Done. https://github.com/OpenImageIO/oiio/pull/1017
On Fri Dec 26 2014 at 2:14:21 PM Larry Gritz <[email protected]> wrote: > OK, let's use the XX%xYY% syntax for nonuniform scale. Just update your > patch, and either send it to me or post a pull request to GitHub. > > -- lg > > > On Dec 24, 2014, at 1:31 PM, Justin Israel <[email protected]> wrote: > > I don't know why I didn't realize that the duplicate actions were already > supported. So that pretty much negates the need for my extra suggestion > since you can just write more action params. > > The float percentages syntax would be great, since it aligns better with > future syntax, like you had said. I'm happy to adjust my patch to cover > this different syntax. Looking forward to hearing your thoughts on the > extended features, once you have had a chance to look over some options. > > Thanks! > > On Tue Dec 23 2014 at 8:22:44 PM Larry Gritz <[email protected]> wrote: > >> On Dec 22, 2014, at 10:24 PM, Justin Israel <[email protected]> >> wrote: >> >> The ":" separator was only a suggestion. It would be good to hear what >> others think on that. Although I did think of it similar to an aspect >> ratio, without being confused for actually being an aspect, since I am not >> sure what 3:2 would imply. >> >> >> I would assume that '3:2' means an aspect ratio of 1.5. Like "4:3" >> commonly is used to describe the aspect ratios of old TV monitor's display >> area if there are square pixels (like 640x480). >> >> I'm trying to think "if I, or someone like me, saw that command line, >> without reading the documentation, would they be likely to correctly guess >> what it does." That isn't always possible (and there are some oiiotool >> operations that even I need to look up every single time because I find >> them confusing, despite having written them), but I think it's worth >> striving for. I think really my reaction was simply that the pattern "A:B" >> is associated with aspect ratios, not with x and y values. >> >> >> Would it be scaling the height while maintaining the width? Is it scaling >> the width to maintain the height? So I figured if you said 3:2, the only >> concrete values that could be derived are 3*x:2*y . Unless you are >> suggesting that the ratio might apply to some previously specified >> width/height. >> >> >> I guess we'd choose a convention: preserve the horizontal, or the >> vertical, or whichever is bigger, or smaller. >> >> >> Maybe the scales could be conveyed through a <float>%x<float>% >> >> >> I'd be ok with that: --resize 200%x50% would mean double the >> horizontal resolution and halve the vertical resolution and is the natural >> extension/combination of our two existing notations: "-resize <float>%" >> (uniform scale) and "-resize <float>x<float>" (absolute resolution). For >> that reason, this is my current favourite so far. >> >> >> I would probably prefer the <float>:<float> syntax to that, though. >> >> >> If we wanted to extend the syntax in the future to allow specification of >> aspect ratios, we will be disappointed to have already used the ideal >> notation for that. >> >> >> Maybe that was a bad example then, because I forgot that I could have >> tacked on a --fit operation after the resize to accomplish that task. But I >> don't think you can have multiple --resize or --fit operations under the >> current ArgParse impl, right? If that was the only possible case for >> needing subsequent transformations, then maybe the multiple "," support >> isn't needed. >> >> >> Sure you can! ArgParse doesn't have to work this way, but oiiotool uses >> a mode where It actually processes the commands left-to-right, calling a >> function for each command as it parses it, rather than just setting flags >> and running one function at the end. So this is perfectly legal: >> >> oiiotool input.tif -resize 50% -resize 200% -o blurry.tif >> >> That's actually a kind of cool way to remove the high frequency content >> (though probably less efficient than --blur). >> >> >> Perhaps related, I've also toyed with the idea of some kind of string >>> substation rules on the command line where you could access metadata >>> (including resolution) of the "current" image, and maybe even do simple >>> math expression with it. That's a much more invasive surgery, including >>> needing a bit of overhaul in the ArgParse class we use for command line >>> arguments. But it's an interesting direction for future work that would >>> make oiiotool even more flexible. >>> >> >> Honestly, I was thinking that very same thing, but I didn't want to >> suggest too much up front. ffmpeg has some neat expression support in its >> filter flags. oiiotool probably doesn't need quite as extensive of support >> for these expressions, but the ability to access context-specific values >> through symbols would be sweet. Like if I could have said: >> >> --resize "w/2 x h/4" >> >> So, scale the in-width down by half, and scale the in-height down by half >> and also another half for the anamorphic squeeze. >> >> Maybe cool things to have access to would be: >> w - input width >> h - input height >> ar - aspect ratio >> >> >> I'm thinking even more general than that... retrieval of any metadata. >> For example, why not be able to extract the "ImageDescription" and render >> it as text atop the image? >> >> I haven't thought it through enough to come up with the right syntax yet, >> however, and we need to be careful to make it easy for it to correctly >> disambiguate the metadata retrieval from the math expressions, and make >> sure neither could be confused for filenames. >> >> This is more for long-term. It's a big step and will be an important >> feature, I don't want to botch it by picking a syntax that we later come to >> regret. >> >> I'll look into ffmpeg as you suggest and see what it does. >> >> -- >> Larry Gritz >> [email protected] >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > 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 >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
