Released version 1.1.1, https://github.com/0xC0000054/gmic-8bf/releases .
Changes:
- Fixed an issue with processing images that are taller than they are wide.
1 Like
Released version 1.1.2, https://github.com/0xC0000054/gmic-8bf/releases .
Changes:
- Fixed a crash when exporting a 16-bits/channel document with multiple layers.
1 Like
Hello, thanks for this new filter!
However, with the latest 1.1.2 version, I still notice some problem with a few filters.
PS: I’m using Affinity Photo as host application, but I assume that other hosts may face the same problems?
Issue 1
The first problem happens with filters where the output size is larger than the size of the input image layer. By definition, such issues occur e.g. with (some) Frame and Upscale filters. Actually, two of my favorite use cases for Gmic…
The returned image is (destructively) ‘cropped’ from the top left corner and is restricted to the size of the input layer.
Apparently, the 8bf filter is (in its current state) unable to resize the canvas of the document associated with the input layer.
As far as I can see, three options can be envisioned as solutions:
1/ Perform a resizing of the host document, and make it (at least) equal to the size of the (larger) returned layer. I believe that this should be the ‘preferred’ solution (i.e. also similar to what happens in Gimp as host). With such an approach, I also believe that it would be best to create a new layer in the host document. Otherwise (in case of just updating/overwriting the original input layer, as it happens now), this will e.g. create problems with adjustment layers and masks associated to the input layer in the original host document.
2/ Don’t send the filtered layer back to the host application document, but save the output to a new file (.PNG format), similar to what happens now when the output of the filter consists of multiple layers. Subsequently, these newly created files can then be loaded as extra layers (manually, by the user) into the original host document, or can be treated further as independent files.
3/ (at least ‘theoretically possible’ in Affinity Photo, unsure about other hosts). In Affinity Photo, it’s perfectly possible to import layers that are larger than the canvas size. As a user, you may indeed ‘place’ (i.e. add) image files of any size as new layers on a document’s canvas. If it would be possible to do this ‘automatically’ from within the 8bf plugin, this would of course be the ‘most streamlined’ solution.
Issue 2
Another problem in the current version of the 8bf plugin (also relevant in case of the second approach mentioned above!) applies to those filters that create new files (i.e. in case of multi-layered output).
Apparently, these filters also update (i.e. overwrite destructively) the original layer in the host document with the output layer corresponding to the 0.PNG file. This way, the original layer is lost, which is of course not how it should work. If layers are exported to separate .PNG files, the original input layer in the host application should remain untouched.
I hope the explanation above is sufficiently clear. If not, please don’t hesitate to ask.
Kind regards.
1 Like
You posted a number of questions / issues, I will try to answer them in order. 
Photoshop does not allow filters to resize the document or create new layers, other compatible hosts will have the same restrictions.
My Paint.NET G’MIC plug-in places the full-size image on the clipboard in addition to outputting the cropped image to the canvas.
I think users expect a filter to write something to the canvas if the click Ok, this is also the reason for the behavior you mention in issue 2.
This is not something an 8bf plug-in would have access to.
As I mentioned above, users may expect a filter to write something to the canvas if the click Ok.
But as the plug-in will normally show a folder picker, it should be clear to users that the images have been exported in most cases.
The issue I have with changing that behavior is that the “Last Filter” command would need to show a folder picker to make the new behavior clear to users.
Hello PDN_GMIC,
Thanks for your reply. That’s really superfast: 
!
From your reply, I understand that some ‘solutions’ are technically not possible with 8bf-filters. I’m no specialist, so, I fully accept your comments. This is especially valid for what you replied on the ‘solutions’ 1 and 3 of my original message.
However, please allow me to have a somewhat different opinion on your comments about the second option (also linked to what you replied w.r.t. my ‘Issue 2’).
I hope we may ultimately all agree that the current solution simply doesn’t work for filters where the size of the output is larger than the size of the input (cf. practical example below). As mentioned in my original post, typical examples of such filters are frames and upscaling. I’m personally not aware of other use cases of such increased layer size (I didn’t do an exhaustive check on all filters, but these two particular filter types are frequent personal use cases for Gmic).
To demonstrate my argument, I’ve included below some screenshots of a simple workflow, i.e. adding a picture frame.
Step 1/ Starting point: open an arbitrary image in the host application (Affinity Photo in my case)
Step 2/ Activate Gmic and apply a simple rectangular white border (10%) around this picture
Step 3/ Click the OK button in Gmic, and watch (enjoy) the result in the host application:
I hope it’s obvious that this is not the expected result (i.e. a destructively cropped image with an incomplete border only on the top-left side of the image)?
Similarly, in case of e.g. a *2-upscale filter, the current implementation of the 8bf-filter results in a ‘blown-up’ figure of the top-left quarter of the original picture…
Therefore, I don’t understand why such cases can’t be ‘solved’ in line with the second solution proposal.
If you would extend the current export mechanism (as far as I understand, now only used in case of filters with multiple output layers?) towards all filters whereby the height and/or the width of the output layer exceeds the corresponding dimension of the input layer, I assume that there will be a PNG file created with an image that doesn’t crop the border? From there onwards, any further edits are possible, either after (manually) adding this new PNG image as a separate layer into the original document, or by editing this PNG file as a separate, standalone image file.
I believe that such solution can be implemented without having an impact at the host application as such.
I personally would prefer (for filters with PNG output!) that the input layer of the host application would not be overwritten with the filter’s first output layer. Of course, this ONLY applies to filters for which PNG’s are created. ALL other (i.e. most) filters do update the input layer, of course.
I also believe that this can be simpler to understand for end users: either the result of the filter updates the input layer in the host application, or the result of the filter is written as PNG files to the filesystem. This distinction could, if deemed appropriate, be empowered with a simple warning / message box.
However, I admit that I can’t judge on what you mean specifically with the ‘Last Filter’ command. Affinity Photo doesn’t have such option. As far as I can see it, for those filters (see above) that should operate via the ‘PNG export’ output process, it also wouldn’t make any sense to re-run the filter once more, because it would further destroy the image…
Finally, may I also imagine/suggest some potential enhancement options to further streamline this PNG file creation process?
As it currently works (as far as I’ve understood till now), the multi-layer filters always create a series of files, automatically named: 0.png, 1.png, 2.png, etc. If the files are created in the same directory, any previous files with the same name are overwritten (the user can’t specify other filenames). Especially this auto-overwrite can create problems if one handles many pictures in a row. Wouldn’t it be feasible to have a more ‘meaningful’ naming scheme (e.g. based on the original document file name, and/or the input layer name, and/or the Gmic filter name).
Remark: I’m not sure that it is technically possible to derive e.g. the original document’s filename, but even then, just the Gmic filter name may already help to distinguish between the multiple PNG files.
Remark: In the Gimp Gmic filters (if I recall well), the returned layers can also have names based on the applied Gmic filter (including even Gmic parameter values).
As an even better (longer term) improvement option, one could also imagine a kind of ‘file policy’ parameter, whereby a user could specify (in a persistent way, e.g. via Gmic’s parameters) a preferred directory location, based on some options. I could think e.g. about a choice between: fixed directory, same directory as host document, a GMIC subdirectory of the host document directory.
Remark: I’ve no clue whether all suggested options are technically feasible and probably they may require extensions on Gmic side as well, but: let’s brainstorm/dream a bit…
This way, a user doesn’t have to select each and every time again the directory where the PNG files must be written…
Sorry for this long post… I appreciate a lot what you’ve achieved so far already with this bf8-variant of the Gmic filters. I only hope that it can still be further improved.
Kind regards.
The plugin has many limitations, which is why I use the CLI version. However, for the most part, they exist not because of G’MIC inadequacies but rather the host app not knowing what to do with the output. The community simply doesn’t have the resources to enable full G’MIC-host compatibility or control the behaviour of the host such as resizing the canvas or positioning layers. I have tried but it didn’t work.
What I tend to do is to export and then import the image after G’MIC processing, or prepare the canvas and layers prior to the processing so that the image would come out properly. Not ideal but workable.
I agree that the naming scheme for multiple output images is not ideal, but I am working with what the host application and G’MIC-Qt give me.
I like your idea of using the G’MIC command name as the file name.
The command name should be fairly short and according to the G’MIC Language Reference it cannot contain any special characters that would not be allowed in a file name.
This would require a new “output images” method to be added to the G’MIC-Qt host API, with the G’MIC command name as a parameter.
@David_Tschumperle may have further suggestions about this.
I agree, if the image has been resized the user should be prompted to save the image without modifying the current layer.
The 'Last Filter’ command is an option that Photoshop and some other hosts have that reapplies the last used filter with the same parameters without showing the user interface.
Currently this plug-in will remember the last selected output image folder and overwrite the existing images without prompting the user.
As that is a data loss issue I will be changing it to prompt the user for a new output folder.
I have considered writing a settings plug-in that would allow those options to be configured, but that would be a significant amount of work. I am also not sure if all hosts support multiple plug-ins in the same file.
Hello PDN_GMIC,
Thanks a lot for your reply! Please find below some further remarks/questions.
Placing a copy of the output file on the clipboard would be a very smart feature! Nevertheless, I assume that it’s only really useful with filters that generate a single PNG output file? In such cases, it may indeed further streamline the workflow because it eliminates the need to open a file browser and drag & drop the output file into the host application (CTRL-V will be faster…). However, I would suggest to retain the creation of the physical PNG output files as well (just in case… 
).
If you would consider to change the naming scheme of the .PNG output files, it might also be a good idea to include a kind of timestamp in the filename, to further reduce the risk of file duplicates, and thus overwrites (e.g. filtername-YYMMDD-HH_MM_SS-SeqNbr)?
Remark: ‘SeqNbr’ is only relevant in case of multiple output files for a filter, similar to the current 0, 1, 2, etc… filenames.
OK, thanks to clarify, now I understand
It’s not really clear to me what you mean exactly with ‘all hosts support multiple plug-ins in the same file’.
In my original ‘suggestion’, I considered the option to define a ‘generic’ output directory path, as something that should (preferably) be added to the (existing) settings dialog of Gmic-Qt. I would assume that such change is not part of your plug-in, but should be handled by the Gmic team (unless you can do it in a simpler way)?
Remark 1: Not all suggested directory path options might be easy to code (or technically even not feasible), but the option to just define a ‘fixed’ output directory would already help to simplify the workflow when editing images.
Remark 2: Last weekend, I noticed that there exists already a series of Gmic filters that have a dedicated button to select an output directory (filters in the group ‘Sequences / Animated’). For these filters, the output directory is apparently specified at the level of each individual filter. I would thus suggest to add such mechanism also at the level of the overall settings.
This ‘generic’ directory definition could then be applied for all filters for which your plug-in creates PNG output files. This would indeed avoid the need to specify an output directory every time again (certainly in combination with a revised filenaming scheme, cf. above) …
Anyway, many thanks again for your work on this filter.
I ended up adding a save dialog that will be shown if the G’MIC output is a single image that has been resized.
The Windows clipboard is more trouble than it is worth, it has limited support for images and the support varies between applications.
A timestamp is a good idea, I will add that.
My G’MIC-8bf settings plug-in would most likely be a second plugin in the GmicPlugin.8bf file.
I am not sure if all 3rd-party host applications support that feature of the plug-in standard, but every one I have tested does and a number of popular plug-ins use it.
With the current design of G’MIC-Qt, that generic directory would only work for the standalone version.
When G’MIC-Qt is used by a plug-in, it simply hands the plug-in a list of output images and lets it do whatever it wants.
I assume that this ‘fixed’ output directory would be the same for for all images?
Allowing separate directories for ‘single resized image’ vs ‘multi-frame animation’ is possible, just more work.
It looks like adding a ‘G’MIC-Qt Output Settings’ plug-in will be my next major project.
The way it would work is when the user configures a default output directory, it will be remembered and used without prompting the user to pick a folder or save a file.
I think that exists to allow the user to specify an output directory when using those filters from the G’MIC CLI, which would not have a global settings dialog.
Release version 1.1.3, Releases · 0xC0000054/gmic-8bf · GitHub.
Changes:
- Added a timestamp to the G’MIC image file names.
- Display the G’MIC-Qt input options for single layer images.
- Prompt the user to save the new image if G’MIC resizes it.
- Always show a folder prompt for multiple output images.
- Do not replace the current layer when G’MIC produces multiple images.
- Do not replace the current layer when G’MIC resizes the image.
- Fixed a few compatibility issues with some 3rd-party hosts.
- Various other bug fixes and improvements.
I downloaded the latest version (1.1.3). Affinity Photo is my host application. Unfortunately, I received a Windows security warning (see screenshot below).
Could you please have a look?
Many thanks.
Kind regards.
It looks like a false positive.
I submitted both the 64-bit and 32-bit versions to VirusTotal, it looks like Microsoft may have fixed that issue in their latest signature update.
64-bit: VirusTotal
32-bit: VirusTotal
1 Like
Dear,
I’m not at all familiar with the virustotal.com website, and thus, I also don’t understand very well how to use the services that it provides 
. Via the URL link in your last message (64-bit), I noticed yesterday evening that the overall .zip-file didn’t seem to indicate any direct problems. However, the included .8bf and .exe files were labelled with question marks (the warning yesterday was specifically targeted at the .8bf file). This morning, these ‘?’-symbols were no longer there… As a further test, I uploaded the .8bf file individually (i.e. unzipped), and it didn’t seem to report any problems anymore. I then updated my virus definitions and reinstalled the plugin in the appropriate Affinity directory. Since then, I haven’t received any further warnings (till now, at least…). So, I assume that the problems are gone, and that it was indeed most likely a false positive.
I also have some further (mostly cosmetic) suggestions for the 1.1.3. release of your plug-in:
The timestamps are indeed applied, but only for the scenario with multiple output files. For those cases where a popup window is shown due to the enlarged size of the output, the default input field for the filename is blank, and the user must manually enter a valid name. For the sake of consistency, I believe that it might be better that (also for these cases) a filename based on a timestamp would be auto-suggested by the plugin.
I notice that this selection box has indeed been added. However, based on your previous remarks, I assume that this option is only relevant with PS as host application? Is this understanding correct? At least, in case of Affinity Photo as host, any choice for this input option doesn’t seem to make any difference (i.e. only the ‘active’ layer is used as input for the filter).
This feature has indeed been added to the latest release of the plug-in. The pop-up window title (‘Save the Resized Image’) clearly indicates its purpose. I wonder whether it would be a good idea to change also the title of the popup window for selecting a folder (in case of multiple output files) into something that gives a bit more context (e.g. ‘Select Output Folder to Store the Multiple Output Files for this Filter’)?
PS: I have the impression that the directory for storing output files is persistent between multiple sessions (even after exit + relaunch of the host application). This is great!
Feel free to handle these suggestions as you like.
Thx again.
K.r.
I will do that.
That is correct.
I recently added a settings plug-in that allows the user to set a default output folder.
When a default output folder has been set, the plug-in will only display the folder picker or file save dialog if there was an error loading the default folder setting.
It should be possible to extend that to allow non-Adobe hosts to browse for a second input image. Although that approach would be an inconvenient hack, it would allow IrfanView, Affinity Photo and other 3rd-party 8bf hosts to use the Stylize filter.
That title does make more sense.
The OS handles that, I agree that it is a very nice feature.
Release version 1.2.0, Releases · 0xC0000054/gmic-8bf · GitHub
Changes:
Improved the plug-in launch speed with large images.
The save dialog will now have a default name for the resized image.
Added an Input/Output Settings for G’MIC-Qt plug-in, which provides the following features:
- The user can set an alternate source for the second input image that some G’MIC filters require.
- This allows G’MIC filters such as Stylize to be used in single layer documents or hosts that do not support providing layers to 8bf plug-ins.
- A default output folder can be configured for the filters that produce multiple images or resize the image.
- When this option is configured the plug-in will only prompt for an output file or folder if the settings cannot be loaded
See the Input/Output Settings for G’MIC-Qt section in the read-me for more details.
3 Likes
Release version 1.2.1, https://github.com/0xC0000054/gmic-8bf/releases
Changes:
- Reduced memory usage when exporting and importing images
- Fixed a few compatibility issues with PaintShop Pro.
1 Like
@PDN_GMIC, I’d like to thank you again for all the work you did on the 8bf interface of G’MIC-Qt. I’ve noticed your PR yesterday to the official gmic-qt repo, and this is a good occasion to say it again : Thank you !
I’ve already seen videos here and there showing how to install G’MIC-Qt for Affinity Photo, so people are starting to use it for sure. It’s definitely a great addition to the G’MIC project.
Do you have any stats of downloads of the 8bf plug-in so far ? Just curious 
Currently version 1.2.1 has 294 download of the 64-bit plugin and 91 downloads of the 32-bit plugin.
The total number of downloads across all versions is 1757.
1 Like
Release version 1.2.2, https://github.com/0xC0000054/gmic-8bf/releases
Changes:
- Fixed a compatibility issue with IrfanView that was introduced in v1.2.1.
- Improved the plug-in error handling.
1 Like
Verified that 1.2.2 does work with Irfanview. I had to remove all references to the previous plugin and re-add it to my plugins list for Irfanview but then all was well. Kudos to the additional development of this plugin since it does give the gift of G’MIC to many platforms.
As a side, cool that you can now run sequential operations while in the plugin like you can when in GIMP; originally you had to exit the plugin after each action.