I tried to use afre’s (luminance-) contrast filter and it suddenly makes things transparent for some weird reason.
Not sure what other filters are affected if any.
Of course this filter is in the ‘testing’ category and from 2020, so maybe it just needs a small adjustment and it doesn’t affect G’MIC overall, and maybe the filter isn’t expected to remain stable over time.
I thought I’d mention it though, in case there was an ‘oops’ moment.
Thanks for letting me know. I will take a look.
Turns out I do not use split_opacity in any of my filters. The workaround would be to “Remove Alpha Channel” in GIMP and the equivalent elsewhere; otherwise, only apply afre_contrast on the RGB channels.
This wouldn’t be a option in Krita and Paint.net, but it’s not hard to change script accounting for that. My scripts, I try to accomodate BW, RGB, RGBA, CMYK, and CMYKA.
@Whatnot I have updated the filter to include an Ignore Alpha check box (only for this filter). Try refreshing your filters file in the next few hours.
If it does not update, you may have to use the latest version of the plugin.
I have been out of the scripting game for a long time, so I am not surprised if my filters are broken or have an unfinished algorithm.
Oh I see your remark about the checkbox, it’s not there (yet) so far for me, but I’ll see what it does if it shows up.
Now for the message I was composing:
Well the thing is that I’m pretty sure it didn’t use to affect transparency.
Or did all my use cases just miss it?
I noticed it the other day when I tried to use it in an action (which is a recorded set of commands basically) in photoshop through the 8bf filter interface, and because I was using it on a duplicate layer instead of the ‘background’ layer that has a lock on it be default in photoshop, I was suddenly confronted with a weird unwanted transparency.
Now if I use it on a freshly loaded image in photoshop where it has the default lock it did not have the issue.
So my solution was to do a ‘copy’ of the default image then apply the filter then ‘paste’ the unfiltered image as a new layer and then swap both layers.
Now obviously that is silly and was just me trying if I could outfox this issue.
However since I thought this transparency thing was odd and made no sense in a contrast filter (although as stated it’s ‘luminance’ based) I decided to report it here to see if it was a new bug maybe.
But obviously I can use any other contrast adjustment as an alternative, I just was surprised about that transparency thing
I’m not sure what the nature of the default ‘lock’ is in photoshop though, it is not like any of the lock option you have for layers, doing a ‘lock transparency’ doesn’t work to fix this, nor do any of the other lock options.
If anybody knows what that default ‘background’ lock in photoshop entails and how I can apply it to a layer please tell me.
edit: krita always does the transparency thing, regardless if it is the only image
Oh incidentally, my version of PS is very old, doesn’t even have AI! (the horror!)
I tried it on some other filters and it’s not just ‘contrast’ that has the transparency thing
But regarding the button you added to try, I forgot David posted:
I’ve started the work for next “major” release 3.6.0 of G’MIC.
Filters update is now disabled for 3.5.x versions.
And since the version I have is 3.5.5 we’ll have to wait for the 3.6.0 rollout.
I could have started with this instruction. Go to “Custom Code”. Paste:
shared 0,{s-2} afre_contrast. 200 rm.
Essentially, the shared 0,{s-2}…rm. construction limits the processing to all channels except for the last one, which in your case is alpha or transparency. You may use any command in between. Just remember to add a period after the name. In our case, it would be afre_contrast. with a parameter of 200. Note that the shared method may not work for all commands, particularly more complex ones.
Command names are not exposed in the GUI interface. Search the source for them: gmic-community/include/afre.gmic at master · GreycLab/gmic-community · GitHub.
Thanks afre, very clever, doing that does indeed fix the transparency oddity.
I should have thought of trying to limit the channels through commands, although I would have tried ‘apply_channels’ since that is one I
experimented with a bit, but I’m not sure how successful I would have been
I’m still wondering if David made some change that causes the issue in the first place though.
After playing around some more and comparing I notice that the output from that custom code version is not quite the same as the regular filter.
It seems the B channel is affected, the output in the plus has less blue and the output when the filter has a negative input makes it a bit more blue.
It’s an interesting thing to figure out, a puzzle.
I at this moment can’t figure why it would affect the blue channel, except that the blue channel being the last one might be a clue, does the transparency issue just move from channel 4 to channel 3 (blue)? I wonder if I can figure out a test to determine that.
I still don’t have enough GMIC stuff in my head to quickly do this.
If you don’t have alpha or transparency, the last channel would indeed be blue for an RGB image. In that case, do
afre_contrast 200
which would use all channels available rather than processing all but the last.
Why everything but the last? Because we can have something like CMYKA.