From: "Brendan Bolles" Received: from nail.lmi.net ([66.117.140.18] verified) by media-motion.tv (CommuniGate Pro SMTP 6.1.0) with ESMTP id 7187448 for AE-List@media-motion.tv; Thu, 08 Nov 2018 19:43:38 +0100 Received: from [10.25.0.108] (unknown [12.42.42.62]) by nail.lmi.net (Postfix) with ESMTPSA id BCA2AE43AB for ; Thu, 8 Nov 2018 10:56:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E743E84B-A7F6-4A43-A5D8-239739864335" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [AE] ProEXR 2.0 Date: Thu, 8 Nov 2018 10:55:49 -0800 References: To: After Effects Mail List In-Reply-To: Message-Id: <1EBF11F7-4606-42EA-AD2F-6BF4351BAA47@fnordware.com> X-Mailer: Apple Mail (2.3445.5.20) --Apple-Mail=_E743E84B-A7F6-4A43-A5D8-239739864335 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 8, 2018, at 10:33 AM, Teddy Gage = wrote: >=20 > Brendan I tried to use cryptomatte on a few comps in AE using the = previous version and it was brutally, unworkably slow. Render times = ballooned to long lengths like over an hour per frame at high bit depths = or big comps- how is the speed of this new implementation? That sounds like you were running into the problems Chris made me aware = of. If you were, the speed improvements in the release will be dramatic! What was happening (ever since AE CS6 and before!) is that when you had = an EXR sequence and AE was running EXtractoR or something, AE would read = the EXR header many, many times=E2=80=94once for each channel, in each = instance of EXtractoR. When you add in Cryptomatte the EXR header gets = much bigger, multiplying the problem. The result was that these EXR = sequences could be unbearably slow. For some reason AE didn't do this = when you just had a single frame. The latest release of AE is still doing this, I believe, but this = version of the OpenEXR plug-in always caches channels and also headers. = This makes things much better, as I think Chris will attest. Now, Cryptomatte is still not the fastest thing. After all, it usually = processes 12 EXR channels in one pass. Some proxy creating might be = wise. But the extreme slowdown there was before should now be gone. Brendan --Apple-Mail=_E743E84B-A7F6-4A43-A5D8-239739864335 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On = Nov 8, 2018, at 10:33 AM, Teddy Gage <AE-List@media-motion.tv> wrote:

Brendan I tried to use = cryptomatte on a few comps in AE using the previous version and it was = brutally, unworkably slow. Render times ballooned to long lengths like = over an hour per frame at high bit depths or big comps- how is the speed = of this new implementation?

That = sounds like you were running into the problems Chris made me aware of. = If you were, the speed improvements in the release will be = dramatic!

What = was happening (ever since AE CS6 and before!) is that when you had an = EXR sequence and AE was running EXtractoR or something, AE would read = the EXR header many, many times=E2=80=94once for each channel, in each = instance of EXtractoR. When you add in Cryptomatte the EXR header gets = much bigger, multiplying the problem. The result was that these EXR = sequences could be unbearably slow. For some reason AE didn't do this = when you just had a single frame.

The latest release of AE is still doing = this, I believe, but this version of the OpenEXR plug-in always caches = channels and also headers. This makes things much better, as I think = Chris will attest.

Now, Cryptomatte is = still not the fastest thing. After all, it usually processes 12 EXR = channels in one pass. Some proxy creating might be wise.

But the extreme slowdown there was before should now be = gone.

Brendan

= --Apple-Mail=_E743E84B-A7F6-4A43-A5D8-239739864335--