so I am officially confused!

according to this

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-modes-final-cut-pro/
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 <randrianasulu@gmail.com>:
I found Graphics-softlight mode behaving visually close...but not sure how close to CinHV/CV subtract mode ...



вс, 25 сент. 2022 г., 10:24 Andrew Randrianasulu <randrianasulu@gmail.com>:
I was trying to repeat tuto at


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 (