On Tue Dec 23 2014 at 2:07:49 PM Larry Gritz <[email protected]> wrote:
> Hi, sorry again about taking a while to get to this. I've had a few extra > hassles on my plate this last week or so, you may have seen it on the news, > plus several days of being in bed with cold. But all better now! > > I'm fine with expanding the syntax for describing resolutions, and your > patch looks like exactly the right approach for how to implement it. > > Just a little bit of fine-tuning on the syntax maybe. > > I can live with the "xscale:yscale" syntax if that's what people want, but > I wonder if that might be confusing because ":" is usually used to denote > aspect ratio. Perhaps --resize 3:2 might be interpreted as "resize it to > achieve a 3:2 aspect ratio" (which may also be useful). Maybe as an > alternative: "xscale,yscale" (using comma)? > 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. 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. Maybe the scales could be conveyed through a <float>%x<float>% I would probably prefer the <float>:<float> syntax to that, though. > > This may conflict with your second example, which I admit I'm not > completely understanding. And, are you aware of the --fit command, and how > does the task you describe differ from fit? > 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. > > 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 ffmpeg has separate symbols for input/output width and height, so that you can access both the original w/h of the source, as well as the currently transformed w/h values. It only really makes sense if multiple expressions are allowed. Or if you want to be able to access the current w/h in a set of transformation flags, for working with offsets and stuff. Just brainstorming. If there aren't enough use cases then maybe its all overkill. > -- lg > > > On Dec 12, 2014, at 3:01 PM, Justin Israel <[email protected]> wrote: > > > Hi, > > > > I wanted to get some feedback on some ideas to improve on the support in > oiiotool for its geometry string parameters (i.e. --resize <param>) > > > > Concrete example: > > > > Lets say I have an image where I don't yet know its dimensions up front, > but I know it is anamorphic (either via naming conventions, or user input, > or a database, ...), and I want to produce a non-anamorphic conversion by > squeezing the height. In the current oiiotool I cannot see a way to perform > this transformation without knowing the width/height ahead of time, to > provide an explicit WxH argument. Maybe I missed something, and someone > will point out the way to do it. > > > > So, lets say the image is actually something like 2048x2304 (2:1 display > aspect), and I want to produce a 2048x1152 output. My idea was to add > support for the following syntax: > > > > --resize 1:0.5 > > > > This would allow the width and height to be independently scaled, > without maintaining the aspect ratio. I have attached a patch that adds > this functionality to the adjust_geometry() function. > > > > But I wondered if we could expand on the syntax even more? > > What I actually wanted to do in my concrete example is produce a 1K > non-anamorphic proxy image from my anamorphic source image. What if > multiple geometry arguments could be specified, using a comma to separate > them? I could then do something like this: > > > > --resize 1:0.5,1024x0 > > > > This would allow me to squeeze the anamorphic source and scale it to 1K, > all without knowing the original dimensions and needing to do the math > ahead of time to provide explicit values. > > > > Does anyone see any value in this, outside of my anamorphic example? Are > there are other suggestions or variations to how these transformation > options could be expanded? > > > > Justin > > > > <oiiotool_scale_per_dim.patch>______________________________ > _________________ > > 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
