Cingg'divide mode, very divisive!
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 ....
A small mod can be applied to improve the Divide overlay *as long as no one objects*. (most like Gimp). Old projects can use a previous AppImage to get the previous results. The mod seems to fix the minor imperfections you can see in the following screenshots using the Overlay plugin. hhttps://cinelerra-gg.org/download/testing/divide_flowers.png (Top first layer order) In both Cinelerra 7 and Current CinGG, look at imperfection on upper right hand corner about 1/3 of the way down where there are 2 small red rectangles. And there are small dark blue squares scattered around in the light blue areas. These look wrong to me. https://cinelerra-gg.org/download/testing/divide_waterfall.png (Bottom first layer order) Entire left hand side just looks ugly for both Cinelerra 7 and current CinGG. I do not think anyone would want this output. https://cinelerra-gg.org/download/testing/divide_squares.png (Top first layer order) This test is interesting because all 3 look the same with no obvious imperfections.
чт, 10 нояб. 2022 г., 03:04 Phyllis Smith <[email protected]>:
A small mod can be applied to improve the Divide overlay *as long as no one objects*. (most like Gimp). Old projects can use a previous AppImage to get the previous results. The mod seems to fix the minor imperfections you can see in the following screenshots using the Overlay plugin.
hhttps://cinelerra-gg.org/download/testing/divide_flowers.png (Top first layer order) In both Cinelerra 7 and Current CinGG, look at imperfection on upper right hand corner about 1/3 of the way down where there are 2 small red rectangles. And there are small dark blue squares scattered around in the light blue areas. These look wrong to me.
can those be amplified compression artefacts? If you load same images into gimp 2.10.xx do you see them? And what exactly you suggest to change in code? :)
https://cinelerra-gg.org/download/testing/divide_waterfall.png (Bottom first layer order) Entire left hand side just looks ugly for both Cinelerra 7 and current CinGG. I do not think anyone would want this output.
https://cinelerra-gg.org/download/testing/divide_squares.png (Top first layer order) This test is interesting because all 3 look the same with no obvious imperfections.
Trying to learn how to use layers in GIMP right now -- probably will take all day. Simple one line change in cinelerra/overlayframe.h around line 72: OLD: (Dc > ZERO ? (Sc * mx) / Dc : ZERO)) NEW: (Sc > ZERO ? (Dc * mx) / Sc : ONE)) This new line is what I have been experimenting with. Switching from ZERO to ONE shows white instead of black. Switching order of Dc and Sc changes application order of Source over Destination. On Wed, Nov 9, 2022 at 5:14 PM Andrew Randrianasulu <[email protected]> wrote:
чт, 10 нояб. 2022 г., 03:04 Phyllis Smith <[email protected]>:
A small mod can be applied to improve the Divide overlay *as long as no one objects*. (most like Gimp). Old projects can use a previous AppImage to get the previous results. The mod seems to fix the minor imperfections you can see in the following screenshots using the Overlay plugin.
hhttps://cinelerra-gg.org/download/testing/divide_flowers.png (Top first layer order) In both Cinelerra 7 and Current CinGG, look at imperfection on upper right hand corner about 1/3 of the way down where there are 2 small red rectangles. And there are small dark blue squares scattered around in the light blue areas. These look wrong to me.
can those be amplified compression artefacts? If you load same images into gimp 2.10.xx do you see them?
And what exactly you suggest to change in code? :)
https://cinelerra-gg.org/download/testing/divide_waterfall.png (Bottom first layer order) Entire left hand side just looks ugly for both Cinelerra 7 and current CinGG. I do not think anyone would want this output.
https://cinelerra-gg.org/download/testing/divide_squares.png (Top first layer order) This test is interesting because all 3 look the same with no obvious imperfections.
Here is what GIMP shows: https://streamable.com/lulp9e and you can see that it does not have the 2 red rectangles in the 1/3 down right hand side and the blue rectangles in the middle area. I do see some small white areas in modded CinGG around the 2 blue flowers to the left but they are not distracting and it could be because I intentionally made the colored image larger than the flower image so that it was obvious. In other words the alignment is different between Gimp and CinGG. (I am often guilty of sending big files to the Mailing List so I need to stop!) On Wed, Nov 9, 2022 at 5:14 PM Andrew Randrianasulu <[email protected]> wrote:
чт, 10 нояб. 2022 г., 03:04 Phyllis Smith <[email protected]>:
A small mod can be applied to improve the Divide overlay *as long as no one objects*. (most like Gimp). Old projects can use a previous AppImage to get the previous results. The mod seems to fix the minor imperfections you can see in the following screenshots using the Overlay plugin.
hhttps://cinelerra-gg.org/download/testing/divide_flowers.png (Top first layer order) In both Cinelerra 7 and Current CinGG, look at imperfection on upper right hand corner about 1/3 of the way down where there are 2 small red rectangles. And there are small dark blue squares scattered around in the light blue areas. These look wrong to me.
can those be amplified compression artefacts? If you load same images into gimp 2.10.xx do you see them?
And what exactly you suggest to change in code? :)
https://cinelerra-gg.org/download/testing/divide_waterfall.png (Bottom first layer order) Entire left hand side just looks ugly for both Cinelerra 7 and current CinGG. I do not think anyone would want this output.
https://cinelerra-gg.org/download/testing/divide_squares.png (Top first layer order) This test is interesting because all 3 look the same with no obvious imperfections.
participants (2)
-
Andrew Randrianasulu -
Phyllis Smith