вс, 25 сент. 2022 г., 13:15 Andrew Randrianasulu <randrianasulu@gmail.com>:
so I am officially confused!

according to this

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



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/

--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 (