Release of G'MIC 2.0.0

Software G'MIC
31

Just posted this at GIMPChat. This could be a feature, but, if you open up GRIP, it resets your presets in G’MIC and vice/versa (so if you changed any of the sliders in either one and then open the other one, it will reset the sliders as I mentioned). If you stay within the plugin universe (i.e stay in GRIP for instance) then the sliders will keep their position as you left them for the preset that you worked with. Just a head’s up. :slight_smile:

32

Minor issue (not exactly a bug) that seems to affect 1.8 pre and 2.0 pre x64 gimp - the update file is rewritten to disk each time the plugin interface is launched.

Also noticed something about retinex - seems odd to do a sum of logs when it amounts to log of the product, i.e. it could just be 3 * log([input]) - log([G1] * [G2] * [G3]). Maybe there’s some other reason I haven’t thought of.

33

Thanks Andy, I’ll try to fix that ASAP.

34

I could swear the update file overwrite was fixed for a while, but it seems to be back now! Sorry if you haven’t actually looked at it yet, I might be imagining things…

On another note, I had a thought about the old gimp <-> G’MIC zero opacity handling bug. Instead of trying to deal with the output not being written in fully transparent areas, it might be better to always “sanitise” the input when previously transparent regions might be revealed.

Example: with -remove_opacity, set other channels to 0 where the opacity was 0 beforehand.

Another choice is to do that automatically with every gimp input: where opacity = 0, set all channels to 0. There are downsides to that though and it’s a relatively rare problem.

Of course all this would be moot if they just fixed the actual bug :slight_smile:

35

They would like effects of gmic-zart for obsproject

36
  • 05/29/2017 : Final release ! :slight_smile:
10 Likes
37

You may retire, then.

38

Not before the final release of version 2.0.1 :wink:

39

Will there be a manjaro build? The one I have is an outdated pre-release version :grimacing: but I know it’s extra work. This version is a great step forward for G’MIC, thanks to all involved :wink:

1 Like
40

:champagne: Congrats! :tada:

Maybe Kdenlive could be second in line? =)

Cheers

41

Here it is : http://gmic.eu/files/linux/gmic_gimp_qt_2.0.0_manjaro64.zip
Because you’re worth it :slight_smile:

1092×761 118 KB

1 Like
42

Woohoo! thankyou :blush:
A nice present to come home to, working great!

43

Now applying 3DLUT.cube is not working. Output is only black image.

44

Interesting, could you upload the file somewhere so I can check and fix this ?

45

You can try this free LUT with any image.

46

Thanks. See also Convert .cube to png - #8 by David_Tschumperle for a discussion about this problem.
A fix is on the way :slight_smile:

47

sigh I just tried to install the GIMP plug-in for Windows 64-bit.

The procedure entry point could not be located in libwinpthread-1.dll

Both QT and GTK Windows 64-bit installers failed. I am running GIMP 2.8 and I hadn’t updated G’MIC since 1.7.9 so perhaps there is my problem.

I am not a programmer so please forgive my ignorance (we can’t all be experts at everything). Is it impractical to include all the required .dll files in the Windows installer? Where can end users obtain the correct .dll files?

48

This .dll issue is recurrent in Windows, but let me explain a bit why :

  • GIMP tries to locate plug-ins in a single folder, without any recursive search, so all plug-in binaries should be put in that folder .
  • A plug-in binary that needs .dll must then install them also in the same path.
  • As a result, it may create a lot of issues because these newly installed .dll will be also used by default by the other plug-in that are located in the same folder, and if they need another version of the same .dll, then it is a mess, making some plug-in unstable or crashing.
  • So, the list of .dll G’MIC tries to install is carefully restricted to a minimal set, to avoid .dll conflicts. That is the set of .dll packaged in the installer.
  • For an unknown reason, it appears your installation of G’MIC needs some function that is not present in your current installed version of the .dll libwinpthread-1.dll. Don’t ask me me why, I couldn’t tell you, maybe you are using an old version of GIMP ? This .dll is packaged with the executable, so it should work flawlessly.

So my suggestion :

  • First, uninstall your previous version of the plug-in. Be sure it is uninstalled (no older version should be put in one of the plug-in folder) before trying to install the new version.
  • Once you have double or triple checked this, try the safer way of installing the plugin : don’t use the installer but unzip the .zip archive somewhere in a separate folder (not in your plug-in folder), and go to GIMP / Preferences / Paths, and add this folder as a plug-in path for GIMP.

If this doesn’t work, then I’m afraid I cannot be of any help.
Things on Windows are always working randomly, and this is already a miracle we have succeeded to compile a version of G’MIC on this “system”.

49

That has been changed in git a week ago:

commit efae55a73e98389e38fa0e59ebebcda0abe3ee96
Author:     Jehan <jehan@girinstud.io>
AuthorDate: Wed May 24 12:02:52 2017 +0200
Commit:     Jehan <jehan@girinstud.io>
CommitDate: Wed May 24 17:33:15 2017 +0200

    app: allow plugin inside first-level directories of plug-ins folders.
    
    We don't search recursively but only at the first level. If a plugin is
    in its own subdirectory, the entry point has to be named the same (minus
    extension) as the directory. For instance my-plugin/my-plugin for a
    binary, or my-plugin/my-plugin.(py|exe|…).
    This way, a plugin can load shared objects (libraries, other script
    files, etc.) without polluting the main plug-ins directories, and in
    particular without interfering with other plug-ins.
    This is a first step to fix bug 757057 (DLL files which were used in
    various plugins).
1 Like
50

Yes I’ve seen that, and this is a really good idea :slight_smile: