The fix is very simple for both methods, if we take a sample from the math parser (I’ve omitted the boundary for brevity):
DownRightPixel = (-j(-3,-3) + 9*j(-1,-1) + 9*j(1,1) - j(3,3))/16;
UpRightPixel = (-j(3,-3) + 9*j(1,-1) + 9*j(-1,1) - j(-3,3))/16;
DownRightPixel*weight1 + UpRightPixel*weight2
The quickest way is to switch the numbers of weight1 and weight2 but more correctly it should read:
DownRightPixel = (-j(-3,-3) + 9*j(-1,-1) + 9*j(1,1) - j(3,3))/16;
UpRightPixel = (-j(3,-3) + 9*j(1,-1) + 9*j(-1,1) - j(-3,3))/16;
UpRightPixel*weight1 + DownRightPixel*weight2
Where we take “UpRightPixel” to be the 45 degree interpolated value. The same needs to be done for the horizontal/vertical pass. In the other method it’s a case of referencing two images the other way around so every bit as easy.
Arbitrary channels is easy enough, in fact only support for opacity changed that. What I should really do is have a “native” command which doesn’t care about channels/opacity, then for the g’mic filter split the opacity and call the native command on those. That has to be done because of gradient averaging across channels.
3d volumetric
Hahah ok well without alterations it would work as is but with no interpolation between “slices”. Assuming you do a third pass in the depth plane it would be interpolating between previously interpolated values… it needs some thought!
Adding to g’mic stdlib is a great idea, but I still have cleanup to do. For instance I do a third unnecessary gradient amongst other things, it just made it much simpler to deal with in my head. If you fancy doing the tidy up for me though I’m more than happy