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)? 

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?

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.

        -- 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

Reply via email to