Maybe there should be a clamp option in 'merge3'. I think divide has similar
issues. That would allow for backward compatibility to 'merge2'.
Clamping for matte purposes is valid isn't it?
Howard
> On 28 Jan 2015, at 7:53 pm, Deke Kincaid <d...@thefoundry.co.uk> wrote:
>
> Mads:
>
> When you say we changed it, did we at one time have a merge2 node that did
> not clamp and we changed the formula on the Merge2 node to then clamp?
>
> I suspect this predates The Foundry's involvement in Nuke (Merge2 node was
> introduced before 2007) and anyone who did make the modification has long
> since left. I looked through our bug database and no one has filed a bug
> though I did find a previous post on this list asking the same question back
> in 2012. The trouble is if no one emails support and files a bug then it
> does not exist as a feature request/bug.
>
> Nuke-Users is not an official Foundry channel for filing bugs/features, it is
> just a channel for like minded users to converse with each other. You should
> send this into supp...@thefoundry.co.uk and get this logged.
>
>
> --
> Deke Kincaid
> Media & Entertainment OEM Development Manager
> The Foundry
> Skype: dekekincaid
> Tel: (310) 399 4555 - Mobile: (310) 883 4313
> Web: www.thefoundry.co.uk
> Email: d...@thefoundry.co.uk
>
>> On Wed, Jan 28, 2015 at 9:31 AM, Mads Lund <madshl...@gmail.com> wrote:
>> But i guess that leads back to the original question.
>> I can't find a single reason (artistically or technically) why they changed
>> this to clamp between 0-1.
>>
>>> On Wed, Jan 28, 2015 at 6:03 PM, Ivan Busquets <ivanbusqu...@gmail.com>
>>> wrote:
>>> For more crude / unclamped versions of some merging operations (including
>>> "overlay"), you can also use the olde "Merge" node (as opposed to the
>>> default "Merge2".
>>>
>>> Merge {
>>> inputs 2
>>> operation overlay
>>> name Merge1
>>> selected true
>>> xpos -254
>>> ypos 199
>>> }
>>>
>>>
>>>> On Wed, Jan 28, 2015 at 8:34 AM, Mads Hagbarth Lund <madshl...@gmail.com>
>>>> wrote:
>>>
>>>> It's just bad with the overlay thing, as it is a pretty useful way to add
>>>> grain and do dodge/burn effects. It works out of the box in Photoshop,
>>>> Fusion and AfterEffects but you have to make your own overlay gizmo to
>>>> make it work in Nuke.
>>>>
>>>>
>>>>> Den 28/01/2015 kl. 17.11 skrev Daniel Short <danisnotsh...@gmail.com>:
>>>>>
>>>>
>>>>> I wondered how the screen would need to be calculated differently since
>>>>> the invert function might get you some crazy values in float space.
>>>>> It makes sense that they changed it to give us a visually accurate result
>>>>> when a mathematical one would look like an error.
>>>>>
>>>>>> On Wed, Jan 28, 2015 at 10:49 AM, John Mangia <j...@johnmangia.com>
>>>>>> wrote:
>>>>>> Looks like the nuke screen algorithm has a low pass to allow for values
>>>>>> over 1 to comp more naturally. You can see the difference if you expose
>>>>>> down.
>>>>>>
>>>>>>> On Wed, Jan 28, 2015 at 10:37 AM, Mads Lund <madshl...@gmail.com> wrote:
>>>>>>> Ahh ok, so the "Screen" operation in the merge node does not just
>>>>>>> screen.
>>>>>>>
>>>>>>> Screen is the same as the Merge node, only with operation set to screen
>>>>>>> by default. It layers images together using the screen compositing
>>>>>>> algorithm: A+B-AB if A or B ≤1, otherwise max(A,B). In other words, If
>>>>>>> A or B is less than or equal to 1, the screen algorithm is used,
>>>>>>> otherwise max is chosen. Screen resembles plus. It can be useful for
>>>>>>> combining mattes and adding laser beams.
>>>>>>>
>>>>>>> However i still don't see why they don't apply this to the overlay
>>>>>>> method aswell. (why would you want clamp the image?)
>>>>>>> And it also doesnt explain why it clamps at 0 (since multiply does not
>>>>>>> clamp at 0)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Wed, Jan 28, 2015 at 2:46 PM, John Mangia <j...@johnmangia.com>
>>>>>>>> wrote:
>>>>>>>> Screen is also a multiplicative operation, it's just inverted images
>>>>>>>> multiplied together and re-inverted.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, Jan 28, 2015 at 8:35 AM, Ron Ganbar <ron...@gmail.com> wrote:
>>>>>>>>> The math used in Nuke for Screen makes it inheritingly clamp (it
>>>>>>>>> doesn't really clamp, but can not produce colors brighter than 1).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ron Ganbar
>>>>>>>>> email: ron...@gmail.com
>>>>>>>>> tel: +44 (0)7968 007 309 [UK]
>>>>>>>>> +972 (0)54 255 9765 [Israel]
>>>>>>>>> url: http://ronganbar.wordpress.com/
>>>>>>>>>
>>>>>>>>>> On Wed, Jan 28, 2015 at 2:15 PM, Mads Lund <madshl...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> According to the documentation:
>>>>>>>>>>
>>>>>>>>>> • overlay - Image A brightens image B.
>>>>>>>>>> Algorithm: multiply if B<.5, screen if B>.5
>>>>>>>>>>
>>>>>>>>>> However Nuke also clamps the colors between 0 and 1.
>>>>>>>>>> It seem that all other compositing software does not clamp between 0
>>>>>>>>>> and 1, so i am wondering if this is a bug in Nuke?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Nuke-users mailing list
>>>>>>>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>>>>>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Nuke-users mailing list
>>>>>>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>>>>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Nuke-users mailing list
>>>>>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>>>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Nuke-users mailing list
>>>>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> John Mangia
>>>>>>
>>>>>> 908.616.1796
>>>>>> j...@johnmangia.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Nuke-users mailing list
>>>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daniel Short
>>>>> www.danisnotshort.com
>>>>> 215.859.3220
>>>>> _______________________________________________
>>>>> Nuke-users mailing list
>>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>>
>>>> _______________________________________________
>>>> Nuke-users mailing list
>>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>
>>>
>>> _______________________________________________
>>> Nuke-users mailing list
>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>>
>> _______________________________________________
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
> _______________________________________________
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
