so I am officially confused! according to this https://emptyeasel.com/2008/11/14/layer-modes-part-three-difference-addition... color inversion in subtract mode IS normal thing. yet in original Cin something else happens .... may be Phyllis can replace our original red-green square images with full-color gradients + photo, so effect will be more natural? Or add this into new appendix ..... вс, 25 сент. 2022 г., 11:06 Andrew Randrianasulu <[email protected]>:

I found Graphics-softlight mode behaving visually close...but not sure how close to CinHV/CV subtract mode ...

вс, 25 сент. 2022 г., 10:24 Andrew Randrianasulu <[email protected]

...

:

...

I was trying to repeat tuto at

https://linuxvideoediting.blogspot.com/2022/01/transparent-text-effect-in-Ci...

so I loaded video, created empty new vid track, applied 'titles', 'blur' and 'invert video' to _empty track_, then set track's mode to subtract .... result was color inversion of original video on second vid track (

so I am officially confused!

...

according to this

https://emptyeasel.com/2008/11/14/layer-modes-part-three-difference-addition...

color inversion in subtract mode IS normal thing.

URL is really good to help understand.

...

yet in original Cin something else happens ....

may be Phyllis can replace our original red-green square images with full-color gradients + photo, so effect will be more natural? Or add this into new appendix .....

Good idea to add in appendix but I am not sure I could get it right.

more documentation, it seems Adobe products use shared code for this ....

https://www.rippletraining.com/blog/final-cut-pro-x/understanding-blend-mode...

Another good URL to look at. When coding all of the Overlay modes, Porter Duff explanations and example were used as the basis. Not sure if Gimp and PhotoShop use the same basis.

--quote---

Subtract

Subtract does what it advertises; the color values of one layer are subtracted from the other layer. This tends to have a net darkening effect. Pixel values can’t fall below zero, so negative numbers are rendered to black.

---end quote---

in older cingg code (from 4.6.mod era - earliest public code on Google code) I see such construct :

/data/data/com.termux/files/home/cingg-g~nelerra-4.6.mod/cinelerra/overlayframe.C 4762/69317 UTF-8 6%

break; \

case TRANSFER_SUBTRACT: \

r = (temp_type)output[0] - (temp_type)input1; \

g = ((temp_type)output[1] - (temp_type)chroma_offset) - \

((temp_type)input2 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

b = ((temp_type)output[2] - (temp_type)chroma_offset) - \

((temp_type)input3 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

if(r < 0) r = 0; \

if(g < 0) g = 0; \

if(b < 0) b = 0; \

r = (r * opacity + output[0] * transparency) / max; \

g = (g * opacity + output[1] * transparency) / max; \

b = (b * opacity + output[2] * transparency) / max; \ break; \

---

so it basically had specific guard against going negative. Not sure if our implementation does the same just in different place?

I see no specific handling of it in macros ...

overlayframe.h [----] 38 L:[ 53+ 0 53/615] *(1572/17155b) 001[*][X]

// ADDITION<--->[(Sa + Da), (Sc + Dc)]

#define ALPHA_ADDITION(mx, Sa, Da) (Sa + Da)

#define COLOR_ADDITION(mx, Sc, Sa, Dc, Da) (Sc + Dc)

#define CHROMA_ADDITION COLOR_ADDITION

// SUBTRACT<--->[(Sa - Da), (Sc - Dc)]

#define ALPHA_SUBTRACT(mx, Sa, Da) (Sa - Da)

#define COLOR_SUBTRACT(mx, Sc, Sa, Dc, Da) (Sc - Dc)

#define CHROMA_SUBTRACT COLOR_SUBTRACT

but apparently you can add some comparing here ...just .. it went from two-stage process to single stage for untrained eye and I am not sure where to put those ifs?

...

вс, 25 сент. 2022 г., 11:06 Andrew Randrianasulu <[email protected]

...

:

...

I found Graphics-softlight mode behaving visually close...but not sure how close to CinHV/CV subtract mode ...

вс, 25 сент. 2022 г., 10:24 Andrew Randrianasulu < [email protected]>:

...

I was trying to repeat tuto at

https://linuxvideoediting.blogspot.com/2022/01/transparent-text-effect-in-Ci...

so I loaded video, created empty new vid track, applied 'titles', 'blur' and 'invert video' to _empty track_, then set track's mode to subtract .... result was color inversion of original video on second vid track (

may be Phyllis can replace our original red-green square images with

...

...

...

full-color gradients + photo, so effect will be more natural? Or add this into new appendix .....

Good idea to add in appendix but I am not sure I could get it right.

may be download images from said website via "download" button, then place them on tracks and render single frame for each of those 30 different composition modes on top track? sorry if this sounds big, I can try this idea myself, just then I will generate whole folder of images for you to pick up and integrate into manual. < oh Andrew, come on, you just too lazy for even minimal work - my conscience >

It does sound big but quite interesting to me and not a problem with TeX editing. I think I will have time in October to get serious and then have you proofread?

or you mean whole TeX editing? I should try to retest if my pdf generating setup still work ....

...

...

more documentation, it seems Adobe products use shared code for this ....

https://www.rippletraining.com/blog/final-cut-pro-x/understanding-blend-mode...

Another good URL to look at. When coding all of the Overlay modes, Porter Duff explanations and example were used as the basis. Not sure if Gimp and PhotoShop use the same basis.

...

--quote---

Subtract

Subtract does what it advertises; the color values of one layer are subtracted from the other layer. This tends to have a net darkening effect. Pixel values can’t fall below zero, so negative numbers are rendered to black.

---end quote---

in older cingg code (from 4.6.mod era - earliest public code on Google code) I see such construct :

/data/data/com.termux/files/home/cingg-g~nelerra-4.6.mod/cinelerra/overlayframe.C 4762/69317 UTF-8 6%

break; \

case TRANSFER_SUBTRACT: \

r = (temp_type)output[0] - (temp_type)input1; \

g = ((temp_type)output[1] - (temp_type)chroma_offset) - \

((temp_type)input2 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

b = ((temp_type)output[2] - (temp_type)chroma_offset) - \

((temp_type)input3 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

if(r < 0) r = 0; \

if(g < 0) g = 0; \

if(b < 0) b = 0; \

r = (r * opacity + output[0] * transparency) / max; \

g = (g * opacity + output[1] * transparency) / max; \

b = (b * opacity + output[2] * transparency) / max; \ break; \

---

so it basically had specific guard against going negative. Not sure if our implementation does the same just in different place?

I see no specific handling of it in macros ...

overlayframe.h [----] 38 L:[ 53+ 0 53/615] *(1572/17155b) 001[*][X]

// ADDITION<--->[(Sa + Da), (Sc + Dc)]

#define ALPHA_ADDITION(mx, Sa, Da) (Sa + Da)

#define COLOR_ADDITION(mx, Sc, Sa, Dc, Da) (Sc + Dc)

#define CHROMA_ADDITION COLOR_ADDITION

// SUBTRACT<--->[(Sa - Da), (Sc - Dc)]

#define ALPHA_SUBTRACT(mx, Sa, Da) (Sa - Da)

#define COLOR_SUBTRACT(mx, Sc, Sa, Dc, Da) (Sc - Dc)

#define CHROMA_SUBTRACT COLOR_SUBTRACT

but apparently you can add some comparing here ...just .. it went from two-stage process to single stage for untrained eye and I am not sure where to put those ifs?

...

вс, 25 сент. 2022 г., 11:06 Andrew Randrianasulu < [email protected]>:

...

I found Graphics-softlight mode behaving visually close...but not sure how close to CinHV/CV subtract mode ...

вс, 25 сент. 2022 г., 10:24 Andrew Randrianasulu < [email protected]>:

...

I was trying to repeat tuto at

https://linuxvideoediting.blogspot.com/2022/01/transparent-text-effect-in-Ci...

so I loaded video, created empty new vid track, applied 'titles', 'blur' and 'invert video' to _empty track_, then set track's mode to subtract .... result was color inversion of original video on second vid track (

I attach the new image of the overlays to replace "normal.png" in the manual. It seems to me that the original image corresponding to "Subtract" is wrong: it corresponds to the Porter-Duff type overlay called "SrcOut". The test I did using the green and red of the original image seems to me to lead to a correct result. Green (ColorPicker): R = 0.1020 G = 0.8078 B = 0.2980 Red (ColorPicker): R = 0.7333 G = 0.1686 B = 0.2980 Subtract: Alpha Chroma (Sa - Da); (Sc - Dc) (0 - 0); ([0.1020-0.7333], [0.8078-0.1686], [0.2980-02980]) 0 ; (0, 0.6392, 0) The ColorPicker indicates that the green resulting from "Subtract" is exactly (0, 0.6392, 0) I don't really understand this whole overlays thing, especially if they have to do with plugins that use the alpha channel (Reroute and Invert Video, for example). I hope IgorBeg can say something, because he has gone into this topic a lot. Andrew's proposal to add in the pulldown a new section with CinCV overlays sounds great to me because if we can't reproduce the results of the tutorial, something must be wrong. Even just the fact that we cannot use YUVA, but only RGBA. PS: the definition of "Subtract" given in the manual seems to me to match the definition on the "rippletraining" website that you posted. I would not modify it...

I think the problem is due to the alpha channel present in the image. It is imported inside CinGG by removing the transparency and converting it to white. See attached image. I lose transparency with both png and exr, so it is a problem with CinGG (or me getting something wrong) and not the images. I have been using the RGBA-FLOAT color model. A long time ago it seems to me that there was talk of problems with importing sources with alpha channel, but I can't find it again.

Interesting results. I will try to understand and October is going to be "look into Overlays"! Will use your attached files. On Wed, Sep 28, 2022 at 7:38 AM Andrea paz <[email protected]> wrote:

I tried all 30 patchbay overlays. 17 out of 30 are wrong. I attach the 2 sources used (rosso.png and verde.png) plus the project xml if anyone wants to repeat the tests. I also attach the screeshots of the 17 wrong overlays so you can compare them with the ones given in the manual. You can see that the overlapping area is almost always right. The problem comes up with the non-overlapping parts, I don't understand why. You have to do the calculations to figure out what the right result is and why you don't get it.... I remember the RGB values of green and red that I used as sources (I sampled them from the "normal" image in the manual):

green: 0.1020 0.8078 0.2980

red: 0.7333 0.1686 0.2980

ah, I think I see same white are problem as described. good, bug is consistent ) чт, 29 сент. 2022 г., 10:12 Andrea paz <[email protected]>:

...

Interesting results. I will try to understand and October is going to be "look into Overlays"! Will use your attached files.

I am not sure if it is correct to do the tests with the test_subtract.xml project I provided. I used 2 png images of FullHD size and then resized them in the Compositor via Projector. More correct is to use the other 2 images I attach where the colored squares are already the correct size and everything else should be transparent background. I also attach the test_subtract_2.xml project that uses these 2 new images. Trying the overlays with these new images show that in the blend they also use the white values we find instead of the transparencies.

чт, 29 сент. 2022 г., 14:50 Andrea paz <[email protected]>:

I think this is a complicated problem. You can see from the Compositor image you posted that the upper track (green) does not totally cover the lower track (red). So sometimes transparency works and sometimes it doesn't. It works exactly the same for me as it does for you. If you try some other overlays you can see that sometimes the result indicates that white values are also used during the blend, sometimes not.

PS: I tried using the first appimage created, August 2020, and the same transparency display problem occurs.

PS2: I tried rendering a single frame and the result is correct: instead of white parts there is transparency. I did a new rendering applying "subtract" and the result is completely wrong: all black!

may be because 100 - 100 in alpha channel = 0 ? See images.

чт, 29 сент. 2022 г., 19:21 Andrea paz <[email protected]>:

may be because 100 - 100 in alpha channel = 0 ?

...

Yes, I think so.

also, because default png render both for ffmpeg and native NOT using alpha channel - be sure to select rgba format for ffmpeg and check alpha checkbox for png .... I tried to render with native png and initially result loads/shows up in resources wrongly because it uses just png not png alpha (?) yet loading same png standalone via ffmpeg shows up alpha in image correctly ....

чт, 29 сент. 2022 г., 20:00 Andrew Randrianasulu <[email protected]>:

чт, 29 сент. 2022 г., 19:21 Andrea paz <[email protected]>:

...

may be because 100 - 100 in alpha channel = 0 ?

...

Yes, I think so.

also, because default png render both for ffmpeg and native NOT using alpha channel - be sure to select rgba format for ffmpeg and check alpha checkbox for png ....

I tried to render with native png and initially result loads/shows up in resources wrongly because it uses just png not png alpha (?) yet loading same png standalone via ffmpeg shows up alpha in image correctly ....

this is confusing! I tried to load resulting rgba png in GIMP and then it showed wrong too, until I deselected alpha channel visibility! so, it seems ffmpeg's image decoders just drop alpha currently. from images at least. native cinelerra's decoders correctly route alpha, but we can't see it correctly on resources or on tracks... compositor apparently just drop alpha in rgba project mode, so we see only color components from composited image. But alpha channel still around and get rendered into image formats with alpha. And rendering into images without alpha may result in black image in at least subtract mode because alpha subtracted too, and this affect actual image?? like rgba -> rgb transfer with alpha =0 just result in blank black image?? this adds some confusion!!

more documentation, it seems Adobe products use shared code for this ....

https://www.rippletraining.com/blog/final-cut-pro-x/understanding-blend-mode...

Using the above URL for comparison, I used it on current CinGG and HV 4.6.1 for subtract. HV matches and GG does not. So tomorrow I will look at the code that Andrew quoted below to see if adding the specific guard corrects the issue. In the attached, top left is HV 4.6.1 and bottom left is GG current with right side the URL.

--quote---

Subtract

Subtract does what it advertises; the color values of one layer are subtracted from the other layer. This tends to have a net darkening effect. Pixel values can’t fall below zero, so negative numbers are rendered to black.

---end quote---

in older cingg code (from 4.6.mod era - earliest public code on Google code) I see such construct :

/data/data/com.termux/files/home/cingg-g~nelerra-4.6.mod/cinelerra/overlayframe.C 4762/69317 UTF-8 6%

break; \

case TRANSFER_SUBTRACT: \

r = (temp_type)output[0] - (temp_type)input1; \

g = ((temp_type)output[1] - (temp_type)chroma_offset) - \

((temp_type)input2 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

b = ((temp_type)output[2] - (temp_type)chroma_offset) - \

((temp_type)input3 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

if(r < 0) r = 0; \

if(g < 0) g = 0; \

if(b < 0) b = 0; \

r = (r * opacity + output[0] * transparency) / max; \

g = (g * opacity + output[1] * transparency) / max; \

b = (b * opacity + output[2] * transparency) / max; \ break; \

---

so it basically had specific guard against going negative. Not sure if our implementation does the same just in different place?

I see no specific handling of it in macros ...

overlayframe.h [----] 38 L:[ 53+ 0 53/615] *(1572/17155b) 001[*][X]

// ADDITION<--->[(Sa + Da), (Sc + Dc)]

#define ALPHA_ADDITION(mx, Sa, Da) (Sa + Da)

#define COLOR_ADDITION(mx, Sc, Sa, Dc, Da) (Sc + Dc)

#define CHROMA_ADDITION COLOR_ADDITION

// SUBTRACT<--->[(Sa - Da), (Sc - Dc)]

#define ALPHA_SUBTRACT(mx, Sa, Da) (Sa - Da)

#define COLOR_SUBTRACT(mx, Sc, Sa, Dc, Da) (Sc - Dc)

#define CHROMA_SUBTRACT COLOR_SUBTRACT

but apparently you can add some comparing here ...just .. it went from two-stage process to single stage for untrained eye and I am not sure where to put those ifs?

...

вс, 25 сент. 2022 г., 11:06 Andrew Randrianasulu <[email protected]

...

:

...

I found Graphics-softlight mode behaving visually close...but not sure how close to CinHV/CV subtract mode ...

вс, 25 сент. 2022 г., 10:24 Andrew Randrianasulu < [email protected]>:

...

I was trying to repeat tuto at

https://linuxvideoediting.blogspot.com/2022/01/transparent-text-effect-in-Ci...

so I loaded video, created empty new vid track, applied 'titles', 'blur' and 'invert video' to _empty track_, then set track's mode to subtract .... result was color inversion of original video on second vid track (

And now here is the forgotten attached! On Sat, Oct 1, 2022 at 7:27 PM Phyllis Smith <[email protected]> wrote:

more documentation, it seems Adobe products use shared code for this ....

...

https://www.rippletraining.com/blog/final-cut-pro-x/understanding-blend-mode...

Using the above URL for comparison, I used it on current CinGG and HV 4.6.1 for subtract. HV matches and GG does not. So tomorrow I will look at the code that Andrew quoted below to see if adding the specific guard corrects the issue. In the attached, top left is HV 4.6.1 and bottom left is GG current with right side the URL.

...

--quote---

Subtract

Subtract does what it advertises; the color values of one layer are subtracted from the other layer. This tends to have a net darkening effect. Pixel values can’t fall below zero, so negative numbers are rendered to black.

---end quote---

in older cingg code (from 4.6.mod era - earliest public code on Google code) I see such construct :

/data/data/com.termux/files/home/cingg-g~nelerra-4.6.mod/cinelerra/overlayframe.C 4762/69317 UTF-8 6%

break; \

case TRANSFER_SUBTRACT: \

r = (temp_type)output[0] - (temp_type)input1; \

g = ((temp_type)output[1] - (temp_type)chroma_offset) - \

((temp_type)input2 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

b = ((temp_type)output[2] - (temp_type)chroma_offset) - \

((temp_type)input3 - (temp_type)chroma_offset) + \

(temp_type)chroma_offset; \

if(r < 0) r = 0; \

if(g < 0) g = 0; \

if(b < 0) b = 0; \

r = (r * opacity + output[0] * transparency) / max; \

g = (g * opacity + output[1] * transparency) / max; \

b = (b * opacity + output[2] * transparency) / max; \ break; \

---

so it basically had specific guard against going negative. Not sure if our implementation does the same just in different place?

I see no specific handling of it in macros ...

overlayframe.h [----] 38 L:[ 53+ 0 53/615] *(1572/17155b) 001[*][X]

// ADDITION<--->[(Sa + Da), (Sc + Dc)]

#define ALPHA_ADDITION(mx, Sa, Da) (Sa + Da)

#define COLOR_ADDITION(mx, Sc, Sa, Dc, Da) (Sc + Dc)

#define CHROMA_ADDITION COLOR_ADDITION

// SUBTRACT<--->[(Sa - Da), (Sc - Dc)]

#define ALPHA_SUBTRACT(mx, Sa, Da) (Sa - Da)

#define COLOR_SUBTRACT(mx, Sc, Sa, Dc, Da) (Sc - Dc)

#define CHROMA_SUBTRACT COLOR_SUBTRACT

but apparently you can add some comparing here ...just .. it went from two-stage process to single stage for untrained eye and I am not sure where to put those ifs?

...

вс, 25 сент. 2022 г., 11:06 Andrew Randrianasulu < [email protected]>:

...

I found Graphics-softlight mode behaving visually close...but not sure how close to CinHV/CV subtract mode ...

вс, 25 сент. 2022 г., 10:24 Andrew Randrianasulu < [email protected]>:

...

I was trying to repeat tuto at

https://linuxvideoediting.blogspot.com/2022/01/transparent-text-effect-in-Ci...

so I loaded video, created empty new vid track, applied 'titles', 'blur' and 'invert video' to _empty track_, then set track's mode to subtract .... result was color inversion of original video on second vid track (

BUT Subtract mode when using the Red/Green png's does not appear to be correct. I will keep analyzing. On Sat, Oct 1, 2022 at 12:43 PM Phyllis Smith <[email protected]> wrote:

Preliminary results show Subtract (Difference) mode is working same as in this url as Andrew quoted. See attached where compare3.gif shows the URL's difference with Cinelerra subtract below and input.gif shows CinGG input files.

...

according to this

https://emptyeasel.com/2008/11/14/layer-modes-part-three-difference-addition...

color inversion in subtract mode IS normal thing.

yet in original Cin something else happens ....

may be Phyllis can replace our original red-green square images with full-color gradients + photo, so effect will be more natural? Or add this into new appendix .....

BUT Subtract mode when using the Red/Green png's does not appear to be

...

correct. I will keep analyzing.

I think difference might be due to alpha channel in pngs ...?

Maybe, but in doing more tests I see that Addition looks 100% correct. I just started using capture of their files. See Addition attached with URL's on the left and CinGG on the right.

On Sun, Sep 25, 2022 at 4:15 AM Andrew Randrianasulu < [email protected]> wrote:

so I am officially confused!

according to this

https://emptyeasel.com/2008/11/14/layer-modes-part-three-difference-addition...

color inversion in subtract mode IS normal thing.

yet in original Cin something else happens ....

may be Phyllis can replace our original red-green square images with full-color gradients + photo, so effect will be more natural? Or add this into new appendix .....

As suggested, I included in the Manual (just checked into GIT) another set of illustrations for the 30 Overlays using full-color gradient + photo. In looking on the web for comparison and additional information, I hope it is correct with the known guard problem with Subtract. In comparing to the only 7 that are in HV 4.6.1, I found 2 other differences. See attached for "Divide" and "Min".