[Cin] Cingg'divide mode, very divisive!

[Andrew Randrianasulu]

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-formulas.rest

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-5.1/cinelerra/overlayframe.h;h=13c2e4bd0b26b0b5994eea343e02bdd8a4c074be;hb=HEAD

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 ....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20221102/6262c46a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0032-Add-hackish-new-overlay-blend-modes.patch
Type: application/x-patch
Size: 8246 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20221102/6262c46a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20221102-141338.png
Type: image/png
Size: 171903 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20221102/6262c46a/attachment-0001.png>