admin
Ronounours 12:51pm, 9 June 2011
Hi.
I'm happy to announce the release of the stable 1.5.0.0 version of the G'MIC framework. There have been quite a lot of improvements in this version, I hope you will enjoy it as much as I am proud of it :)

Here is the Changelog :

New features :

- New command -x_shadebobs that launches a classical shade bobs animation.
gmic_shadebobs by Ronounours

- New multi-line text parameter widget allowed in the plug-in, with the 'text(1,"text")' parameter type.
- New 'paned' GUI, so you can easily hide or extend the filter tree, or the parameter table for each filter.
- In the plug-in interface, Faves can now be copied as another faves.
[https://www.flickr.com/photos/90104203@N00/5835194619/in/photostream]
- More flexibility is allowed for input/output of filenames. You can now specify the format extension of the filename you want to read/write even if the filename doesn't have this extension. For instance,

gmic tif:foo -o jpg:faa,76

will read the .tif file 'foo' (that has no .tif extension), and save it as a 76% compressed JPEG file 'faa' (with no extension either).
- New command '-uncase', to convert a string as its lower case version.
- Built-in commands are now stored in a more compressed way (still readable, but takes less bytes), reducing then the binary size a little bit.
- 'Convenient' functions are now documented in the G'MIC reference page.
- New command '-auto_gamma', allowing to normalize colors with respect to a specified reference 'neutral' color. Corresponding filter 'Colors/Auto-gamma' has been added as well in the plug-in.
[https://www.flickr.com/photos/90104203@N00/5890659926/in/photostream]
- New command '-fire_edges' and its associated filter entry in the plug-in 'Sequences / Edges on fire'. This command allows to create animations where image edges are on fire.
gmic_edges_fire by Ronounours


Optimizations / Modifications :

- Names of images are now better handled. When an image is obtained as a copy of another one, its label is now 'label~', where 'label' is the label of the initial image.
- Command '-mirror' can now mirror image along several axes at the same time, as in expression '-mirror xy'.
- Axes in command '-plot' and '-display_graph' have now slightly outlined labels, so that they remain visible even when a lot of curves are drawn behind.
- When specifying a 'label' as a selection during a command call, all images having this label are now part of the selection (was the first image only). Labels can then be used as kinds of 'tags' now, as in :

gmic image*.jpg -nm[0,1,3,5,8,-1] to_blur -blur[to_blur] 10

- Extended ASCII characters are now supported in .gmic command files.
- Found a small hack to enlarge the default size of the preview window (350 px instead of 200 px).
- In plug-in, filters that can be applied on different channels have nos the choice for channels R,G,B and A separatly.

Bug corrections :

- Command '-apply_channels' used for 'cb-cr', 'a-b' and 'c-h' channels was processing channels separatly instead of processing a 2-channel image. This is now corrected.
- Corrected bug in plug-in interface. When clicking on the 'expand' button, the last folder of the filter tree was not expanded if a Fave folder was present.
- Corrected bug preventing segfault when using '-split' along values.
- Corrected bug in plug-in, related to the reading of faves files.
- Corrected bug in command '-split', happening when splitting large images in a large number of blocs.
MOD
tom.keil 4 years ago
Is it big problem to allow .jpg and .tiff formats also in the plugin for -input and -output command.?
With that it would be easily possible to create G´MIC filters that work in a batch mode too.

And some video enthusiasts have asked me if G´MIC plugin can work under Cinepaint as well, I could not test because windows version always crashes?
admin
Ronounours 4 years ago
@Tom : yes, it is possible, but the main problem is that it will introduce another dependencies, and it will make the plug-in bigger in size (for functionalities that will be probably seldom used).

As most of the installation problems come from unmet dependencies, I'm not really enthusiast to add the JPG and TIFF support.
Moreover, if someone is interested by doing batch processing, then he should never use the plug-in. There is a command line tool 'gmic' dedicated to this task, which is really more powerful than the plug-in (for instance, it can manage 16bits tiff). I don't see any advantages in using the plug-in for doing batch processing.
MOD
tom.keil 4 years ago
Hi David, yes I also assume the command line version is the best option for this.
The one and only issue is preview, for artistic image processing (and complex filters) at least for me it is impossible to find meaningful settings without any preview.

The workaround could be to write the scripts for both command line and plugin version, then to find the settings using the preview of the plugin and copy and paste the settings into command line version for the batch processing. This should work, but does not sound so handy to me.
PhotoComiX 4 years ago
Also the command line may offer a sort of preview, i mean you may use a display that in most cases is equivalent

( I always tell to myself when i try to convince me to learn to use gmic from command line that the display can give some visual feedback
...still i found hard open the terminal )
admin
Ronounours 4 years ago
The preview that can provide the command line version is even better than the one from GIMP. It allows you really to explore your image data (see the floating point values, zoom in/out, and so on). There is even commands to plot graphs, vector fields, histograms, without any limitations on the number of channels or pixel value range.
Compared to this, the preview in the GIMP plug-in may look just 'ridiculous' :)

That is not really surprising. I used the built-in preview widget provided with the GIMP plug-in API (and it is quite limited), and the plug-in is constrained by the 8bits/channel bottleneck of the actual GIMP implementaion. I must admit I seldom use the plug-in, else than for doing more visual demos to other people..

So, I would really encourage anyone interested by the G'MIC framework to take a closer look to the command line tool 'gmic'. It is ways more efficient and flexible than the plug-in version (although I understand the plug-in has more success due to its GUI-ed nature).
noun0ion9 4 years ago
I may have found a bug... basically, scaling down is almost entirely broken -- it acts as if 'nearest' was the chosen method even when linear, cubic, or lanczos was used.

try entering the following:

-resize 50%,50%,100%,100%,N

in 'Custom Command',
where N is a number >1.
As far as I can tell, all N act as if you had selected Nearest-Neighbour.
admin
Ronounours 4 years ago
Downsizing should always use the 'average' interpolation method, it has been designed specifically for this purpose.
If you want to do a 50% reduction of an image with even dimensions, then no matter what interpolation method you use, it will always looks like nearest neighbor interpolation, since there is no interpolation in this case (the remaining pixel is the one that was at even coordinates in the original image). If you want to do an average of the pixels, then the 'average' resizing mode is your way to do (on the contrary, it sucks for enlarging images).
MOD
François Collard Posted 4 years ago. Edited by François Collard (moderator) 4 years ago
I guessed it was so, notwithstanding my bad math memories;)
I often used Adam Turcotte's NNH (Nearest Neighbor Histopolation) instead of Gimp built-in resizing plug-ins for scaling down, but I have just read the following:
NEAREST NEIGHBOUR HISTOPOLATION
The simplest histopolation method we will discuss is Nearest Neighbour Histopolation (NNH).
It is generally agreed that NNH is the optimal solution for scaling down (unless the image is indexed). The quality is excellent and the implementation is simple and fast.
In fact, when scaling down, both Adobe Photoshop and Gimp appear to use NNH despite (apparently) offering a choice of other resampling methods (and without making it clear that nearest neighbour histopolation/box filtering is used). This was discovered in the summer of 2006 when NNH was coded as a C filter and compared to other methods as part of an undergraduate summer research experience with Dr. Minglun Gong and Dr. Nicolas Robidoux.
MOD
tom.keil 4 years ago
Hi David, I might have found a bug in the new preview of the plugin.

It is great that you can now scale the size of the filter tree and the filter settings, mostly it is used to have a bigger preview image.

Works fine but it always starts with a very small preview image and very broad filter settings display. You can move it to the desired scales but when you call up G´MIC the next time and maximize all is set back again which is very unpractical when working with the maximized window.
admin
Ronounours 4 years ago
This is because of the default size of the GIMP preview widget, which is hardcoded to be 400 or something so.
There are few tricks that have been proposed to enlarge this default size, but I'm not sure how robust it is to do so.
MOD
tom.keil 4 years ago
I see, but it was bigger before the sections were scalable, maybe it is a fast way to make a tick box to have scalable/ unscalable sections. Now you first have to move the filter tree and filter settings to the right first every time you open G´MIC to see something useful which really hardens the practical handling.
PhotoComix_Mandala Posted 4 years ago. Edited by PhotoComix_Mandala (member) 4 years ago
I notice in my filter that maximize the preview modify the zoom factor

that is very impratical because when the ratio is 1:1 maximizing become doubled

i would like that if
gimp_dummy_preview(0)
th zoe chosen zoom factor will remain constant whatever the gui is maximized or not
admin
Ronounours 4 years ago
The zoom factor should remain constant, it has been designed for that. It is strange that it actually does not behave like that.
admin
Ronounours 4 years ago
* 2011/07/07 : Final update !
rabidcopy Posted 4 years ago. Edited by rabidcopy (member) 4 years ago
Thanks for the release.

However I don't like the expanded preview size.

Being someone limited to 1024x768 it doesn't really appeal to me as now the plugin interface hardly fits my screen. (when using any filters that expand the window to display all the settings properly it extends past my screen size so then I have to drag it around so I can't even see the whole preview)

It'd be nice to be able to size it down or choose the originally smaller size.
Groups Beta