search

NatronGitHub / Natron

Open-source video compositing software. Node-graph based. Similar in functionalities to Adobe After Effects and Nuke by The Foundry.
http://NatronGitHub.github.io
GNU General Public License v2.0
4.69k stars 342 forks source link

GMIC Inpaint (patch-based) is throwing an error and returning black #312

Open SilverWolf32 opened 5 years ago

SilverWolf32 commented 5 years ago

Problem

The Inpaint (patch-based) node is outputting black instead of the proper image. Natron doesn't crash, thankfully.

It gives this error in the log:

[23:20:04.541] GMIC_Inpaint_patchbased2: *** Error in ./ ***
Command 'fx_inpaint_patch':
Undefined argument '$13', in expression '$13' (for 12 arguments specified).

Expected behavior: It performs the proper inpainting and returns an inpainted image.

Actual behavior: It fails, returning a completely black image.

Example project: gmic-inpaint-test.redacted.ntp.zip

Steps to Reproduce

  1. Add and wire up a G'MIC Inpainting (patch-based) node.
  2. Click the refresh preview button, and check the log.

Versions

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/66287703-gmic-inpaint-patch-based-is-throwing-an-error-and-returning-black?utm_campaign=plugin&utm_content=tracker%2F83915136&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F83915136&utm_medium=issues&utm_source=github).
devernay commented 5 years ago

The bug is in openfx-gmic. Find out why the plugin thinks this function has 12 arguments. Check the parameters in the plugin interface and see which parameter(s) are missing.

devernay commented 4 years ago

Updated the sample project file for 2.3.15 (attached). Error is now (2.3.15-RC13):

[10:04:07.728] GMIC_Inpaint_patchbased1: *** Error in ./fx_inpaint_patch/*repeat/*local/ *** Command 'if': Invalid argument '-blur': Undefined variable 'blur' in expression '-blur'.

gmic-inpaint-test.redacted-2.3.15.ntp.zip

DestyNova commented 4 years ago

Some of the GMIC plugins work for me, but for others I get similar messages (including the above Undefined variable 'blur' error) in Ubuntu 20.04, using the snap package of Natron 2.3.15.

Here's a few I tried just now:

[01:10:54.167] GMIC_Ascii_Art1: *** Error in ./fx_asciiart/*repeat/*local/ *** Command 'if': Invalid argument '-blur': Undefined variable 'blur' in expression '-blur'.

[01:15:22.165] GMIC_Satin1: *** Error in ./fx_satin/*repeat/*local/adjust_colors/ *** Command 'check': Invalid argument '-50>=-100 && -50=-1(...)lur=-100 && 0

Maybe there was some version breakage in GMIC that made those scripts stop working?

devernay commented 4 years ago

First of all, the Natron developers do not recommend using the snap package, which is known to be buggy: we get numerous bug reports that are only due to using that package.

The G'MIC plugin has always been semi-working (and it is still beta), because all these effects were made mainly for the command-line and GIMP, and they do not all transpose easily to Natron. The parsing of the configuration file was made initially by @tobybear who did a great work, but it was not 100% finished, and parts broke with successive G'MIC updates.

I fixed many of the stuff that broke, as well as bugs in Tobias's original code (see https://github.com/NatronGitHub/openfx-gmic/commits/master). I would say about 50% of the effects work, but I had no time to test them all.

Recently, the G'MIC team decided that they should formalize better how they expose effects, so that they become usable in external apps. This was G'MIC 2.9.0. This was a great initiative from @dtschump and the G'MIC team, but unfortunately it broke openfx-gmic, which is thus still using G'MIC 2.8.4.

Someone has to spend some time on it to make it work again with G'MIC 2.9.x, but this is a lot of work since that also means removing the parsing code.

tobybear commented 4 years ago

Hmm, did the G'MIC API really change that much? At a quick glance, the 2.9.3 standard library still seems to be really similar to the older 2.8. Anyway, I plan on doing some updates in the next weeks to the OFX and AE plugins to get them to run with the latest G'MIC release.

devernay commented 4 years ago

@tobybear feel free to pull the changes and fixes I did to your plugins (available in https://github.com/NatronGitHub/openfx-gmic). I couldn't keep the AE plugin in sync, since I don't have AE.

devernay commented 4 years ago

This is the main thing that changed in 2.9.0 and affects the OFX plugin: (from https://discuss.pixls.us/t/release-of-gmic-2-9/16755)

[stdlib_290] New command parse_gui parses all #@gui filters available (e.g. all filters defined for the G’MIC-Qt plug-in) and outputs filter information in a format following a given output mode (json | list | print | update | zart).

tobybear commented 4 years ago

Yeah, but the additional parse_gui command does not break anything, it is yet another parser for the same command file, right?

The way I see it, there are now a multitude of parsers available for G'MIC:

  1. G'MIC's own parser (functionality is in add_commands() in gmic.cpp) This is used by G'MIC itself to parse the commands in a given file. This would probably be the most straightforward to use without duplicating functionality, but it relies on CImg, so an external parser would need that additional dependency, which is not good.

  2. New "parse_gui" command in gmic_stdlib.gmic. This is a parser done natively in G'MIC as a command, so it is very slow and not usable for realtime parsing. It does have the advantage of being built-in though, so could be used for generating per-release command lists, although I do not see a major advantage, since such a list (no matter if in JSON format or plain text or whatever) would require yet another custom parser to make them usable in another app. Sure for web applications it makes sense with JSON parsers already built in, but for many other applications it might be another unnecessary step. Besides, functionality seems to be broken for 2.9.2, the parameters for output mode and filter do not seem to map correctly and I can't get any usable output on the command line on Windows for that command.

  3. My own string-based parser for the G'MIC commands, used for After Effects, Premiere Pro and OpenFX plugin APIs. This exists in various versions: 3a) The one included in gmic-community. This is the oldest and as you correctly mentioned has bugs and contains unnecessary code since it was ripped out of my own, custom plugin framework 3b) The updated version your did in the openfx-gmic repository for Natron. This has several improvements, but still breaks on certain filters, and is no longer compatible with AE. 3c) My rewrite and cleanup of the parser, using regular expressions and supporting some more cases. This is not yet publicly released. I am currently working on a new version of this at the moment. All of these should for the most part still work for 2.9.x, as the internal format of G'MIC command files did not change.

  4. The gmic-qt parser, written by Sebastien Fourey. This is used for the Krita, Paint.net and digikam hosts and basically does what parser 3) does as well. It however is a bit more streamlined (using regex) and works for more syntax cases. Since it relies on the Qt framework, it is however not easily portable with this additional (and quite heavy) dependency, and Qt also often causes conflicts with host applications when used in a plugin.

I always liked the live-parsing approach, so you could update the G'MIC library and new filters would automatically show up, without needing to create an intermediate file, so at least for my own Adobe and OFX plugins based on G'MIC, I will likely go down this route.

devernay commented 4 years ago

It would be great if the license in your new version could allow its distribution with Natron (as did the previous one). Will it?

tobybear commented 4 years ago

I have my new parser based on regex working, and I also made another parser that uses the new JSON output format by G'MIC (using the RapidJSON lib, which has a MIT license). I am still waiting on a new version of G'MIC that fixes the actual parse_gui command so I can see what the supposed output can look like (I just tested with the json available on the website). Next step will be updating the OFX plugin, merging the old sources with the fixes in the ofx/natron repository and my own improvements I made in the meantime. As for the license, I don't have any problems with this part of my code being used in other projects, so yes, it will be the same or a similar license as before. The only thing we still have to make sure is that it doesn't infringe any other licenses/copyrights, like with the SDKs for OpenFX, Adobe After Effects and possibly third-party libraries being used. I am not sure how fast I can progress with the updated OFX plugin for G'MIC as I have lots of other things going on, but I suspect until the end of November I should have something to show.

tobybear commented 4 years ago

I have my new OFX plugin working in Natron on Windows already in an early stage. It now parses the filters from the JSON file generated from the G'MIC executable instead of of the old string-based method directly on the G'MIC standard library. This makes parsing of parameters a bit easier, but the JSON output in the current G'MIC version does not yet contain important information like the preview_command and the parameter visibility, so it is of limited usefulness. The OFX code itself is an amalgamation of the one in the community repo, the changes Frederic did in the openfx-gmic repo and my latest framework. Now comes the hard process of testing and ironing out bugs. There are always tricky issues like handling of the point parameter, which despite a specification OFX hosts do really different, especially Nuke/Natron VS. Davinci Resolve VS. Sony Vegas.

tobybear commented 3 years ago

FYI: I have revived the 5-year old thread over on pixls.us for keeping up to date and discussing my G'MIC OFX approach: https://discuss.pixls.us/t/gmic-for-openfx-and-adobe-plugins/452