Really? Just tried loading a flat image: "DeepRead2: /<path to image>.exr:
no deep data found in file"
On 9 September 2014 16:14, Deke Kincaid <d...@thefoundry.co.uk> wrote:
> DeepRead can read in both flat and deep channels.
>
> --
> Deke Kincaid
> Creative Specialist
> The Foundry
> Skype: dekekincaid
> Tel: (310) 399 4555 - Mobile: (310) 883 4313
> Web: www.thefoundry.co.uk
> Email: d...@thefoundry.co.uk
>
> On Mon, Sep 8, 2014 at 11:01 PM, matt estela <m...@tokeru.com> wrote:
>
>> Good to know! Yep, I stumbled across the same workaround, but I'm so
>> hardwired to use shuffles it's a hard habit to break. Mainly I was
>> surprised that it was so easy to get nuke into an unhappy place.
>>
>> While I'm vetching, I was also surprised to find the deep toolkit a
>> little undercooked. All a bit crashy, no deepshuffle, deepexpression _very_
>> crashy (and doesn't work with user knobs apparently), a separate deepread
>> rather than a single read node that can handle both regular and deep, etc
>> etc... I hope nuke 9 addresses some of this stuff, cos the core idea of
>> working in deep is great.
>>
>> -matt
>>
>>
>>
>>
>>
>> On 9 September 2014 15:44, Ben Dickson <ben.dick...@rsp.com.au> wrote:
>>
>>> The exrReaderDeep doesn't normalise layer names like the exrReader does
>>> (see Documentation/examples/exrReaderDeep.cpp - it is missing an
>>> equivalent of the "validchanname" method in exrReader.cpp)
>>>
>>> Since the deep EXRs from Mantra contain channel names like "R", "G",
>>> "B", "A" etc, it ends up cluttering the builtin "rgba" channels like:
>>>
>>> rgba.red rgba.r rgba.green rgba.g ...etc
>>>
>>> ..thus nodes the Shuffle acts strangely. Same happens with other
>>> channels like diffuse.r diffuse.g etc (which should become "diffuse.red")
>>>
>>> I reported this a while ago ("Nuke DeepRead doesn't normalise .r/.g/.b
>>> channels"), but it seems the last response I got was "I've passed this
>>> to the engineers to comment on the differences and will get back to you
>>> soon with their responses", so I don't have a bug number..
>>>
>>> Not tried this, but you can probably workaround the problems using a
>>> combination of the "Copy" and "Remove" nodes (e.g you copy the .r into
>>> .red and Remove .r)
>>> - Ben
>>>
>>> On 09/09/14 14:52, matt estela wrote:
>>> > One of the guys here is putting together a repro to send to the
>>> foundry,
>>> > thought I'd check if others have seen this before:
>>> >
>>> > Houdini supports writing deep colour exr's with layers (aovs), and its
>>> > easy to make it simultaneously render both a regular exr and a deep exr
>>> > with identical layer names
>>> >
>>> > Nuke appears to not like this. We'll start a comp with the non-deep
>>> > exr's, then when we're ready to move to deep, start putting down
>>> > deepread nodes. Once we do this, shuffle nodes start to break ( rgba
>>> > becomes rrgg), the layer selector above the viewer stops working, and
>>> > the comp itself stays in this corrupt state, requiring us to build a
>>> > fresh comp from scratch.
>>> >
>>> > If we start and stay with only deep, its ok, and same for staying with
>>> > only non-deep, but you can't combine deep and non deep if they have
>>> > identical layer names.
>>> >
>>> > Anyone seen this?
>>> >
>>> > -matt
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>>
>>> --
>>> ben dickson
>>> 2D TD | ben.dick...@rsp.com.au
>>> rising sun pictures | www.rsp.com.au
>>> _______________________________________________
>>> 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
