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
