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
