[Cin] oops apparently 'subtract' mode is broken!

[Andrew Randrianasulu]

вс, 25 сент. 2022 г., 13:15 Andrew Randrianasulu <randrianasulu at gmail.com>:

> so I am officially confused!
>
> according to this
>
> https://emptyeasel.com/2008/11/14/layer-modes-part-three-difference-addition-subtraction-darken-lighten/
>
> 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 at 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 at gmail.com
>> >:
>>
>>> I was trying to repeat tuto at
>>>
>>> https://linuxvideoediting.blogspot.com/2022/01/transparent-text-effect-in-Cinelerra-part1.html?m=1
>>>
>>>
>>> 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 (
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220925/b9a5bdd1/attachment.htm>