Removing interactive versions for command 'resize', 'threshold', 'cut' ?

(G'MIC staff) #1

Hello there,
I’d like to get your opinion about something:

In G’MIC, some commands propose an interactive mode when no valid arguments are specified.
This is the case for commands crop, resize, threshold and cut.
For instance,

$ gmic input.png resize output resized_output.png

will display an interactive window that you can resize to set the new dimensions of the image.

After several years of G’MIC scripting, I have the impression that while the interactive mode is useful for one of these command (clearly, crop, I use its interactive mode quite often from the command line), it is a burden for the others.
Particularly, for command resize : this is one of the most used command in G’MIC scripts, and it will never throws an error. For instance, a usual error case is this:

$ gmic input.png resize 100%,{h/3},1,3

This is intended to divide the height of the input image by two, and it works, except when the input image has less than 3 rows. In this case, {h/3} is rounded to 0, and the argument passed to command resize is 100%,0,1,3 which is not valid, and thus, resize considers it has no arguments and opens an interactive window, which is clearly disturbing for the developer of G’MIC scripts.

So, I’m really thinking about removing the interactive modes from these commands, which also don’t seem to me to be used much in practice.
And if needed, I plan to replace them by other custom commands, like e.g. icrop, iresize, ithreshold and icut. This is possible, and it could avoid the problem of having bad arguments in G’MIC scripts without throwing an error immediately.

Do you have any suggestions on that ?
@KaRo ? Don’t you use the interactive modes for the cut or threshold commands ?
@garagecoder, @Iain, @Jerome_Boulanger, @grosgood, @rich2005, @Joan_Rake1, @Souphead, @McCap, @Reptorian, @samj, @afre, and others ?

#2

Same. Don’t typically use the rest. Interactive threshold and cut are amusing but aren’t intuitive; interactive resize doesn’t work for me.

1 Like
(Glenn Butcher) #3

I think your intuition on how the commands are used is pretty good, however, I’m continually surprised at how my intuition isn’t the same as others… :smile:

i’d go for the i-versions, leave the legacy syntax intact.

I’m experiencing a somewhat similar thing in rawproc syntax, e.g., converting from image dimension crop coordinates to percentages of the dimension so that the crop intent survives, say, a subesequent change in resize dimensions downstream. I’m retaining ability to process the old coordinates because I now have couple of years of images that rely on them. My customer base is quite small (me?), but he’s a picky fool…

2 Likes
#4

Speaking purely for myself, making separate interactive commands sounds ideal. The only experience I have of the interactive versions is when I least expected it!

1 Like
#5

iknowright? Surprises are unpleasant, esp. for users.

1 Like
#6

When I see an interactive window it’s because I have done something wrong. I would prefer a standard error message in this case.

1 Like
(Karsten R) #7

Hi David,
Yes I am using “crop” and “threshold” in some scripts in interactive mode, rarely or never “cut” and “resize” interactively.

I think an interactive only version or an “interactive” multi-function would be acceptable for me. Only the loss of these functions would be painful.

Regards

Karsten

(G'MIC staff) #8

I’ve just written command crop_interactive for that (shortcut zi).

(Karsten R) #9

Yeah, good. Maybe the selection window could be different from the one in display mode (in the interactive window). I would appreciate to get the coordinates of crop window in status.

(G'MIC staff) #10

threshold_interactive has been added too.
I’ll also add cut_interactive within a few days.

(Karsten R) #11

Very good! Just correct the crash if size changes (^D) are made before any threshold is set.

Is it to much to ask for initial values to set, for threshold as well as crop?

#12

Yes, that is a feature that I considered asking about. Also, if zi could crop to aspect ratio with a modifier key, specific mouse button or command parameters; that would be awesome. E.g., if input image is 3:2, zi could crop 3:2, 2:3, 1:1 or whatever is specified by the parameters.

(G'MIC staff) #13

Having those interactive commands defined as custom commands instead of native ones will allow more flexibility: I’ll start adding these commands only with basic features, but of course everything can be improved over time.

(Karsten R) #14

Understood! But what is actually in threshold_interactive the 100% of the threshold selected?

gmic m gmic_stdlib.gmic osteo +threshold_interactive +ge… {${}*iM#0}

At least neither 255 nor iM#0 is it!

Ok found it is {${}*(iM#0-im#0)+im#0} as i could have expected!

1 Like
(G'MIC staff) #15

I’ve renamed interactive commands to make their names shorter and coherent with the names of the other interactive commands, so : x_crop (shortcut xz), x_threshold and x_cut.
I’ll probably try to improve these commands over time particularly x_crop maybe with the possibility to zoom in/out (to be able to get 1-px precision for the crop), and to be able to refine the first selection after it has been done. Keeping a specified aspect ratio is also on my todo list :slight_smile: