bug: oiiotool --offset syntax is not good with expressions

[lgritz]

On the Slack channel, Liam Collod wrote:

I am working with oiiotool and I have an issue with expressions. I am setting the --origin which relies on the x,y being prefixed by their sign. However both x and y are expression which means their result may be positive or negative without knowing in advance.

* --origin +{exprX}+{exprY} : If I add the + prefix and exprY result is negative, oiiotool will complain.

• --origin -{exprX}-{exprY} If do the inverse with a - prefix and exprY is negative, oiiotool will complain too.
• --origin {exprX}{exprY} And I don't add a sign prefix positive expression will fail  if exprY is positive.

How do I handle this ?

The only solution I found is to store the sign in an user variable using oiiotool --if conditions but that looks to be a quite complicated solution. (--if {exprx>0} --set xsign "+" --else --set xsign "" --endif --origin {xsign}{exprX}...)

[lgritz]

I think the simple answer is that this is just something we didn't consider: the collision of expression evaluation, --origin, and negative offsets / overscan. If you are only dealing with positive offsets, you could of course do +{my_x}+{my_y} , but of course that will be a malformed offset if either component is negative.

I think there are several potential fixes. One is to loosen the parsing of those offset specifications (or "geometry", to borrow X11's terminology, which is where the WxH+X+Y syntax came from, to the best of my knowledge), so that +-4 is understood to be -4.

OR, another way is to add a function to the expression syntax, like offsetstring(w,h) that assembles it into the right string whether positive or negative. (I'm open to suggestions about the name.)

OR, if we really want to swing for the fences (and do maximal work), we could implement a format() function as part of the expression syntax, fully general, so you can do --offset "{format('{:+}{:+}',X,Y}" (Let's move that discussion to the separate issue #5208.)

[MrLixm]

Hey, thanks for putting that in an issue.

I agree that supporting +-4 sounds like the most backward compatible solution and also intuitive for the user (that what I would have expected to be supported).

However I must mention that the way oiiotool expect offset is not very intuitive, I find using the sign as number separator rather odd. Why not using a comma , to separate x and y (eg: 1920x1080,6,-15) ? One could also think of a different "group" separator character like a pipe | (eg 1920x1080|6,15) or a semi-colon ; (1920x1080;6,-15) ? Just throwing out idea, not that it's even necessary but it could help makes things clearer for the user ?

I'll answer in #5208 for the last suggestion.

[lgritz]

You can also do "xmin,xmax,ymin,ymax". I totally forgot about that. Does --offset already accept "{X},{Y}" as-is?

[lgritz]

I wrote --offset but I really meant --origin

[lgritz]

You can also do "xmin,xmax,ymin,ymax". I totally forgot about that. Does --offset already accept "{X},{Y}" as-is?

I think it does not, but letting it accept this seems like the most straightforward solution, even better than +-x+-y

[lgritz]

However I must mention that the way oiiotool expect offset is not very intuitive, I find using the sign as number separator rather odd.

This syntax has been around and widely used for at least 40 years: https://www.x.org/releases/X11R6.8.0/doc/XParseGeometry.3.html#sect3

It's also used by Imagemagick and Graphicsmagick (presumably because their authors, like me, are geezers who learned it from X11 in the late 80s or early 90s): http://www.graphicsmagick.org/Magick++/Geometry.html

[MrLixm]

--offset already accept "{X},{Y}"

would be a cool solution too !

By the way we mentioned --origin which only expect 2 values, but I also had --crop or --resize in mind which had the same problem with the sign when you specify the full form with offset at the end {w}x{h}+{x}+{y}.

This syntax has been around and widely used for at least 40 years:

cool bit of history thanks for sharing !

[lgritz]

Yeah, all of those commands use the same underlying utility to parse those geometry strings, so I should be able to fix them all simultaneously.