Release of G'MIC 1.7.1

Hello there,
I’m happy to announce the release of a new minor version 1.7.1 of the G’MIC image processing framework.

G’MIC is a full-featured open-source framework for image processing. It provides several different user interfaces to convert/manipulate/filter/visualize generic image datasets, ranging from 1d scalar signals to 3d+t sequences of multi-spectral volumetric images, thus including 2d color images.

The following is the full Changelog of the version 1.7.1, as compared to previous stable version 1.7.0.

New features:

  • [stdlib] New commands -inpaint_diffusion and -solidify implement a transport-diffusion algorithm for image inpainting/reconstruction.

  • [stdlib] New command -colorblind simulates different types of colorblindness by applying color transformations to an image.

  • [stdlib] New command -brushify which tries to repaint an image using a user-defined brush.

  • [stdlib] New command -argname which returns the indice list of image having specified name.

  • [stdlib] New commands -img2hex and -hex2img to encode/decode an image into/from a string of hexadecimal numbers.

  • [gimp] New filter Repair / Solidify reconstructs transparent areas in an image by interpolating neighboring pixels.

  • [gimp] New filter Artistic / Smooth abstract uses the Solidify algorithm to create smooth image abstraction.

  • [gimp] New filter Repair / Gradient [random] generates random color gradients all over the image. May be useful to generate colorful backgrounds !

  • [gimp] New filter Color / Color blindness simulates different types of color blindness vision.

  • [gimp] New filter Artistic / Brushify tries to repaint an image using a user-defined brush.

  • [gimp] New filter Frames / Frame [smooth] that adds a smooth frame around the image.

Improvements:

  • [core] Improve code to better manage huge images (>=4Gb of data), using 64bits offsets instead of 32bits when needed.

  • [core] Replace architecture-dependent typenames long and ulong that can be specified in file I/O commands, by int64 and uint64 respectively. So that saving/reading 64bits-integer image files does not depend on the architecture on which we are running G’MIC.

  • [core] Improve visualization of multiple images at once with command -window when the images have different number of channels.

  • [core] Improve onscreen visualization of images with weird ratios when using command -display.

  • [stdlib] Color profiles for all film emulation filters have been compressed using a smart CLUT compression technique, which transform our previous set of 83Mb of color profile data into a single file of 640Kb. As a result, you can apply any color LUT offline, as the file containing all the CLUTs are shipped with the G’MIC packages.

4 Likes

Panoramas tend to get huge quick, thank you for this improvement.

Since you made the update to multi-scale after releasing 1.7.0, I post this effort here. :slight_smile:

https://www.flickr.com/photos/34520999@N05/26072543361/sizes/o/

2 Likes

04/25/2016 : Final release !

Ubuntu packages should be ready in some minutes. :slight_smile:

1 Like

Thanks a lot Thorsten !

No trouble at all. :grin:

Thanks! I have been wondering if there is a Defringe filter in G’mic that I just haven’t found, or maybe it’s in the works?

I don’t think there is already something specifically to defringe images.
Could you post an example of image so we can see if something can be done using G’MIC filters already ?

Thanks. Didn’t respond sooner bc my notice went to the junk box…

Most of the time I can defringe enough first in Rawtherapee but sometimes more is needed, and/or needed selectively… There is an effective script for gimp, Darla’s Purple Fringe Fix - http://registry.gimp.org/node/185 - but it hasn’t been updated for gimp 2.9+, which I’ve been using a lot more lately… I can still use it but have to ok a bunch of messages about the wrong command names or whatever…

Anyhow, next time I encounter an image I want to further further defringe, I’ll try to remember to post it up…

@David_Tschumperle I’ve started to include 1.7.1 in PhotoFlow, also to take advantage of the compressed film emulation LUTs… now that this file is small and can be shipped with the photoflow sources, I am wondering if there is a way to tell G’MIC to look for this file in a custom folder, like /usr/share/photoflow

By the way, thanks a lot for this great improvement!

@Carmelo_DrRaw, yes, you should be able to find this file gmic_film_cluts.gmz usually in the following folders :

  • $HOME/.config/gmic/
  • /usr/lib/gimp/2.0/plug-ins/ (for users of GIMP 2.8).

if one user has already used the plug-in for GIMP, of course !

Well, in fact I would like to ship the compressed LUTs with photoflow and independently of the G’MIC plug-in, therefore the LUT file should be installed and searched in a place different from /usr/lib/gimp/2.0/plug-ins/ or $HOME/.config/gmic/

Would it be acceptable to add some sort of

set_user_data_path()

function to specify a custom location for the user data? Or maybe something like that exists already and I was simply not able to find it?

Thanks!

As this is a G’MIC-related file, I assume that the best place for this file is to put it in $HOME/.config/gmic/ (this is not a plug-in-related folder, but a folder to store G’MIC resource files).
You can ensure you have such a folder, by calling gmic::init_rc() as an initialization function. You can even specify your own folder if you want.
You can get the G’MIC resource folder by calling gmic::path_rc().

Still this is a user-specific folder, while I would like to provide a system-wide version of the LUT file that is automatically installed by the photoflow packages, in case the G’MIC plug-in is not installed as well. And in that case, I do not want to “pollute” the GIMP plug-in folders by writing something under /usr/lib/gimp/2.0/plug-ins/

So, in that case, install the file just where you want, and set the environment variable $GMIC_PATH with the path to this folder. It should be used by the library instead of the default path.

1 Like

Another solution : call gmic::init_rc() with your custom path as the argument before invoking a constructor of a gmic instance. Something as :

gmic::init_rc("my_custom_path");
gmic gmic_instance;

and it should use that custom path as well.

1 Like

This looks exactly what I need… I’ll test as soon as I can.

Thanks!