So, as Igor noticed CinGG's divide and subtract modes do not behave like they behaved in Cin HV/CV/CVE I digged into matter a bit and found few confusing (for me, amateur) things. First, it seems CinGG as of now implement divide mode just like Natron (2.5 from git). https://paste.pics/JJC90 But GIMP/Krita/Photoshop implement different algo, probably described here: https://github.com/psd-tools/image-blender/blob/master/wiki/Blend-modes-and-... basically it makes color white if one input (not one you divide to) was black. I think this is consistent with screenshot: https://paste.pics/JJC76 But moreover, according to documentation CinGG composites tracks a bit backward comparing to photo editors: Description The previous math forms are the only truly accurate description of each blending operation, but short descriptions are below where Source is the output from the next track and Destination is the output from the lower track stacking. Blending starts with new Source and combines it with the previous render stack output, which is referred to as Destination. The new output becomes the next Destination and the next up stack level becomes the new Source. Source is above; Destination is below. --- https://cinelerra-gg.org/download/CinelerraGG_Manual/Description.html So, in subtract and divide modes this *really* makes a lot of difference, like inverting (wildly altering) colors. By playing with automatically set keyframes I 'discovered' you can change compositing mode along the track - so this makes interesting dynamic effects possible. But I do not think reverting subtract/divide to their original form will be best solution. I hope another set of modes can be added, implementing at least previous algo, even if not exact ordering of compositing. (you always can swap tracks or use overlay plugin for different order?) I did similar (software-only ) patch ~year back, attached again (might need some tweaking for new sources). Problem is, I am a bit lost in this MACRO thing, so showing everyone how to put complex equation into our current overlayframe.h very much hoped for. Of course more ultimate idea is to put user-editable inputbox somewhere there, yet I not dare to think what will happen if user just added some A/B and B happened to be zero ..... at runtime, due to picture (so, macro somewhat must wrap around existing checking macro, and THIS definitely above my level ) https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra... One the bonus side, I made simple PSD file in GIMP (2.10.32) and it was openable in cingg via ffmpeg's decoder! of course I am not sure if ffmpeg ever will expose raw layers and metadata for making more complex composition work in applications using it possible, but hey, who knows the future! attached even screenshot from psd-tools repo because I am a bit paranoid about information disappearance ....
