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
