Home
Creators
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

EARLY ACCESS: "CD / Alpha Channel" (Patreon)

Published:
2022-10-14 22:17:08
Imported:
2026-06
haven't archived this post yet. have a subscription? use the importer!

Content

Hello everyone!

Here's a new video for your exclusive early-access consumption!

I wasn't sure if it would be possible to make this topic remotely interesting and... am still not sure. But the video has some fun moments, which I hope you'll enjoy.

Thanks for your support!

Files

Previews only

maxresdefault.jpg

Please consider supporting my videos on Patreon: http://www.patreon.com/CaptainDisillusion CD/ • Intro - https://youtu.be/R4sF0MT1TGM • Aspect Ratio - https://youtu.be/g5ZgUIobSj0 • Frame Rate - https://youtu.be/DyqjTZHRdRs • Resolution - https://youtu.be/1unkluyh2Ks • Interlacing - https://youtu.be/1Yja9m1Lu6M • Color - https://youtu.be/FTKP0Y9MVus

Comments

David Baril

AWESOME!!! also sorry to be that guy but I believe you are mixing up premultiplied and straight alpha in some of the ways you present the concept! As I understand it, pre-multiplied is when the translucent parts of the image is multiplied (or "matted") with the value of the background and "straight" describes when pixels are just made opaque with their RGB values untouched, so the meaning of the words have less to do with the order in the workflow chain than with the actual math (again!) of what is going on with the translucent parts.

-

I still just don't understand how the production quality of these videos is <i>so much better</i> than most every other channel. Magnificent editing, throw-away jokes multiple times per second, just 👏

David Baril

The part where dark pixels become darker is not because they are being multiplied twice, it is because the software is not doing the extra work to decontaminate the premultiplied color if you told it the alpha was straight.

Douglas Pluylaar

I never really tried to get the premultiplied straight thing, so I do actually really LIKE this awareness :D Thanks CD :D also another video from you just makes the world a little brighter :D Loved it!

Minh

Was the Lucas beard CGI?

Urban Exile
>>93612124

No, he's right, it's because of the double-multiplication. Edges usually (statistically) have alpha values that are in the gray region, neither exactly 0 or 1. So masking (multiplying) twice instead of once always causes the value to be smaller in those cases. Adding an extra "multiply by a number greater then 0 and less than 1" by definition must make the result smaller (darker).

CaptainDisillusion
>>93611866

Idk what to tell you other than… no, that’s not how it is, based on what I researched and also tested with my own two hands 🙂 “Premultiplied” is the FG image multiplied by its MATTE (“matted”). How could it be preemptively multiplied by the BG when the BG is not yet known? “Straight” is just the RGB & matte, without the multiplication happening inside the FG image file.

David Baril
>>93611866

But hear me out The BG color is usually black, premultiplied is usually on a black matte. It can be a different color and that is why After Effects gives you the option, but it's the same value for every pixel. Just look at what the AE interpret footage says "Premultiplied - Matted With Color: (color box)" When you choose that option, there's something of an "unmult" step happening on the translucent parts, to remove the matte color (usually black) from the original color. Straight alpha skips that processing and just uses the RGB and alpha values 'straight"

David Baril
>>93611866

You get a black fringe because the software expects clean, straight, RGB colors, but you give it something that's premult on black. And you get a crazy fringe because the software is unnecessarily unmultiplying straight RGB data if you tell it it's premult when it's not.

Adam Wishneusky

I love love love your work but this is the first time as a non vfx person I’ve felt like this is only for people in the biz. I know vaguely what an alpha channel is and wanted to learn more but this feels like a rant

Major Menace
>>93612124

That's great, thanks in advance for going to the effort of making a video to explain this to us. Just out of curiosity, I saw you mentioned using AE frequently for the past 20 years, I assume for a job, what exactly is it you do?

Mike Berman
>>93625223

Yeah, me too. I really enjoyed the video, but for the first time after a CD video I didn't feel like I understood the topic.

David Baril
>>93612124

I've been doing projection mapping and LED content for Cirque du Soleil and shows, and now I'm into 3D character animation. Check out my pinned tweet @davidbaril - I've been fooling around with image channels for a while!

Jennifer Ortiz

It IS remotely interesting. Er, I mean, it IS interesting! Gonna have to watch it a few times, though; the pacing is very fast. (Hey, it's interesting enough to watch multiple times!)

Major Menace
>>93612124

Oh wow, cool job! Incredible art on your twitter by the way, I didn't even realise you could make things like your latest posts on a computer, must've taken a while to figure out! And a great npr style too! I won't ask any more questions on here, as the thread of messages is now quite long. I'm looking forward to the video explanation, this is a really interesting topic but hard to understand for me, so I hope you can help.

Peter Vazny
>>93612124

If I understand this debate correctly, David is saying that a precomputed value of a blue pixel with brightness of 255 and matte of 0.5 will be turned to 128 while the matte will be set to 1. So if you don’t mark the image as precomputed, the final image will combine 0% of the background with 100% of the foreground, which because of the pre computation step is now 128 instead of 255. While CD is saying that the blue pixel gets precomputed to 128, but matte stays the same 0.5 and the final effect is 50% of background is then combined with 0.5 * 128 which would be only 64. I guess those are indeed two different outcomes, since in CD’s case there is 50% of background blended in with 25% of foreground, while in David’s case it is just 50% of foreground against black.

Christopher Mayfield

I watched it with the family. The thing I like most about the cd is they are quick. Under 10 minutes I can just sit the family down and say hey let's watch this. Both the kids yelled out. His beard is missing. Oops

Jerrad Pierce

I might have included a bit about 1-bit (GIF) versus n-bit alpha, but this was otherwise interesting. I particularly enjoyed the SNL and Lucas references. (Of course, you're now not far off from a discussion of gamma)

BoomShadow

Heh heh. I'm probably similar in age to the Captain, but I wasn't getting the reference in the opening. Someone in the Youtube comments mentioned Hans and Frans. Apparently it was an SNL skit.

David Baril
>>93612124

Here's a 5min attempt. Still not sure I'm being clear lol https://drive.google.com/file/d/1CoPDcR3uF0gHBPcF5Xci17K9VkNGxLOj/view?usp=sharing TL;DR is (assuming the matte is pure black, which it typically is) Loading a Premult alpha correctly = After Effects will do something extra to the RGB data it gets from the file to *remove the matte color* that's been mixed in with all transparent pixels at save time. Loading a Straight Alpha correctly = After Effects just uses the RGBA values from the file *as is*. Loading a Premult Alpha but telling AE it's straight = because it thinks the pixels are straight, AE won't remove the matte color from the RGB data it sees in the TIFF, so the transparent pixels will *stay contaminated* by the matte color. Dark edges occur. Loading a Straight Alpha but telling AE it's premult = Your asking AE to alter the RGB value of the translucent pixels, but they were Straight pixels and totally fine to begin with, so it *pushes them brighter* than the original color. Overbright edges occurs. The error I'm seeing in the video is that it portrays pre-mult as the "skip the processing" option instead of Straight.

Billy
>>93612107

I wonder if its because they're put together by someone whose a master of production and whose whole channel is about teaching how those things are done and have been done in the past.

David Whitney

I wish my math teachers generated a spit-take-per-minute ratio that you do. Yours is 0.36 if you are wondering.

David Baril

Last try I swear! Because I have a new starting point I should have lead with, and also maybe I just misunderstood that part: At 3:46, the screengrabs of the Blender Suzans shows Straight alpha. Then, if I understand correctly, you refer to it and its "gritty edge pixels" as premultiplied, or the result of premultiplication? The "gritty edge pixels" stuff is what straight alpha should look like in these conditions. It's the pure RGB data, as rendered out of cycles, but without the alpha channel masking the transparent parts. This is what gets written to file, 100% as is, with its accompanying alpha channel. No multiplication of any kind happens in this process. Premultiplying is the other case. It's when the all the "gritty edge pixel stuff" has been premultiplied with a matte color - typically black - before saving to file, and it needs to get un-multiplied accordingly at import time. If not, every pixel from the image is also as dark as it is transparent. If you ignore the alpha channel on a premultiplied file, it will show as normal on a black background, without any darkening or "gritty edge pixels". Really hope I nailed it this time. Explaining stuff is hard yet you make it look so easy!

Schiffty5

CDeez nuts (with proper matting of course)

Tom Clabon

Amazing that you manage to make something about Alpha channels this watchable!

Major Menace
>>93671259

I think for the Suzanne part, 'peeling away the alpha' divides the premultiplied data by the matte, bringing out grittiness due to data loss from the PM. The raw data from the renderer is multiplied by the raw matte, then composited and viewed using this PM data. Gritty edges shouldn't exist in straight data from cycles unless on really low sample counts, which is for an entirely different reason to the topic of discussion. This whole topic seems pretty mathematical, so I don't understand what part of that you're trying to refute. This isn't a debate, so I'm only arguing the side I believe in currently, which is subject to change. I hope you are operating the same way, otherwise this could go on for much longer.

David Baril
>>93671259

The grittiness is something I see when I do straight alphas in Octane render too. I think it's a combination of two things: Even with high samples, blurry, semi transparent things are harder to render, so those parts are always relatively noisier. And the more transparent the pixels, the more noise you can have in the RGB data without it showing through, but it becomes glaring when you ignore the transparency. No operation is needed for those pixels to look this way other than to look at them while bypassing the alpha. I've been calling the gritty pixels 'staight alpha nonsense' for years. I'm always spying on my channels as I work. I think the main issue is: comparing alpha blending to classical optical compositing is a red herring when talking about straight alpha. That's because straight alpha is a pure product of how digital imaging works and there is no real optical equivalent for it. When we combine a layer that has alpha transparency with another layer in AE or any modern compositing software, the requirements are no longer analogous to the optical process. The schema we see at 4:00, where the BG layer has a black silhouette and the FG layer has a black matte so they can be double-exposed together is not relevant to how alpha blending happens digitally. Something like that does happen in the code, but it's all packaged in a function that expects and outputs pure "straight alpha". Nothing requires premultiplication anymore! In fact, premultiplication gets undone on import most of the time. Keeping footage as pre-multiplied with a matte, then feeding it into a function that expects straight alpha is how the actual "double multiplication" occurs. So this video is all backwards from 3:46 on. It will make anyone who watches it more confused about the subject. I can't not try to warn CD! I might still be wrong, maybe I misunderdstood the video, but my understanding of alpha channels has been solid and thoroughly tested for a long time. I'm always geeking out about this stuff. It's my jam! I know that I'm up against a legend that has invested months of hard work in his explanation, so I won't take it personal if I fail to convince anyone here. And you know what, I hope this video gets published as is! That would mean I'd have to stop procrastinating and make a legit YT response video and we all get more content out of it.

Matt Sims

Without getting into a big unwanted debate I didn't really "get into" the last video. But this one is fantastic. Back on form Capt D! I laughed out loud and have already watched this three times... and also the Undebunkable ;)

Danny Sullivan

You always make it interesting to watch CD!

Carter Burr-Kirven
>>93612124

It's important to note that what Cap is describing in the video here is the general theory of how *all* compositing works. Every composite operation requires those steps: matte the foreground, stencil the background, add together. The tricky bit that I think you're running into is that After Effects, specifically, is weird, and shouldn't be used as an example of proper compositing behavior or image handling. After Effects likes to handle alpha "behind the scenes" for you, applying operations in the order *it* chooses, and always putting premultiplication last. Yes, After Effects does premultiply your images—like Cap said, it's a fundamental step necessary for compositing any two images. And like he also said, a lot of software handles it for you. What AE is doing in those "ingest" options is just bringing the images *into* its own environment, preparing them for a world where alpha is always applied last. AE expects layers to be separated from their alpha (unpremultiplied), so when you bring in a premultiplied image, AE needs to know, so that it can divide the alpha back out, creating an image with disassociated alpha and RGB, aka the way AE internally handles images. (This is a terrible way for a compositing program to function, and comes from the fact that AE grew out of paint programs that work with masks instead of compositing programs that work with mattes. Poke around on the Internet a little and you can find all manner of people with *lots* of strong feelings about this.) Just because After Effects needs to do stuff to images in order to make them compatible with its own workflow doesn't mean what Cap said about the compositing operation itself is incorrect, though. Doing a composite requires a premultiplied foreground image. After Effects might unpremult it for a bit along the way, but it still gets premultiplied in the end, and if you're speaking generally, like Cap was in the video, about the compositing operation in the abstract, separate from any particular software's idiosyncrasies, premultiplication does indeed mean that the image is ready to be used directly in a composite, while unpremultiplied images require another step (premultiplication).

Carter Burr-Kirven
>>93671259

David, I get the sense you mostly work with graphics instead of VFX? AE instead of Nuke? PNGs instead of EXRs? I can tell you as somebody who works in the world of VFX that *everything* we work with is premultiplied, all the time. Premultiplied alpha (or "associated alpha," as I've heard some people push for, since a lot of "premultiplied" images (CG renders, for example) have never actually been multiplied by anything, and never will be) is the only way to store certain types of image data, like glow and fire (that is, things that are both bright and transparent), and is the standard way alpha is stored and handled in most advanced image-processing and 3D rendering software. In Nuke, for example, which I use every day, premultiplication is most certainly not undone on import, and the compositing operation, A+B(1-a), absolutely expects a premultiplied image. You refer to every pixel in the image being "as dark as it is transparent" as though that's a bad thing, but that's what we want! As Cap points out in the video, those pixels are going to be added to the background pixels, so we need to make both darker so that the sum comes out right. We're doing a linear interpolation between the two color values, basically: 30% blue foreground, 70% green background means multiply blue by 0.3, green by 0.7, and add the two together!

David Baril
>>93612124

The big misconception here is that nothing needs to be premultiplied anymore, and there's one section where straight alpha and premultiplied alpha are inverted in the explanation. Premultiplying is an inherently lossy process, it's diluting the color information with the matte by the amount of transparency. Working with straight alpha data had no such downside. It's true that there's a function in compositing softwares that does multiplications and additions internally to blend layers, but that function does not work properly when you feed it pre-multiplied data.

David Baril
>>93671259

I work with all that but I'm not a Nuke user. Do we agree that an image that has never been multiplied by anything, that can have bright transparent pixels, is what we call straight alpha? It's also when you have the "gritty edge pixels" if you ignore the alpha, right? Because premultiplied is the black-background, darkened transparency version, right? While Nuke as a way to use premultiplied data in a node, AE does not. You could go through the trouble of multiplying the BG by the FG's inverted alpha then add in the FG yourself, but I don't see a good reason why? That's why the default way in AE is to make premul alpha straight-ish again ASAP so it gets treated like all the rest of the RGBA data flowing inside, or else you get the dark edges. So, when you look at CD's video at 3:46, and he shows a shot of Blender that actually shows straight alpha data, and the next sentence days it's been multiplied (it's straight) and that premultiplication it is necessary (it's not) to *avoid* dark edges (it makes them)... it's where everything gets irremediably confused. It's the flag I'm trying to raise.

Carter Burr-Kirven
>>93612124

The bread-and-butter compositing operation in the comp software I use every day, Nuke, is called "over," and it's the exact same operation as defined by folks like Alvy Ray Smith and Porter & Duff 40 years ago: A+B(1-a). Foreground pixels (A) plus the background pixels (B) multiplied by the inverse of the foreground alpha. It has no foreground multiplication component, because it expects a premultiplied input. Premultiplication is lossy, yes, and can result in us losing data we can never get back, but that's why we *store* premultiplied images, so we never have to *do* the premultiplication. Look at CG renders, for example: in their natural state, they're premultiplied (and again, this is why we need to get better terms, since nothing was ever multiplied: the alpha and the color information were generated at the same time, with transparency and soft anti-aliased edges that emerge naturally from sampling behavior). If we save that image right into a premultiplied file, like EXR, and take it into our compositing program, it's ready to go. The image is premultiplied (and *perfectly* so, since it was *born* that way), the compositing operator expects a premultiplied image. Bingo! Now, imagine that same render had an emissive fire VDB in it. No density, no obscuration, just light. The renderer will handle it perfectly, creating the RGB and the alpha at the same time, just like we ask it to, and will give us an image that is bright orange in the RGB and totally black in the alpha. If we pass that data into a premultiplied container and send it along to a software that handles premultiplication correctly, all good! We have our fire. But if we instead take that image and save it into a straight format, like PNG: the software divides the RGB by the alpha, creating a straight image (remember, straight alpha is not the natural state of CG renders!), and saves those RGB values into the file alongside the alpha. Then it comes time to composite the image: our alpha values get multiplied back in, and our fire disappears! Since its alpha was zero. And there's no way to get it back, since we need to premultiply our image to fix those crunchy "straight edges", but we can't do that without losing the fire. Like you said, premultiplication is destructive. So, although I get that this can sound confusing, the only way to avoid premultiplication is to save the file into a premultiplied format in the first place! Straight alpha doesn't bypass premultiplication, it just postpones it. If we want to save those values (which were generated properly in the first place!), we have to store them as premultiplied the whole way through.

Carter Burr-Kirven
>>93671259

You only get dark edges if something gets double-premultiplied, and something only gets double-premultiplied if there's an error in order of operations. I think After Effects makes this much more likely by hiding half the steps from you "under the hood," so you don't have a full picture of what's being done to your image. Again, After Effects has to premultiply your image when it's time for the composite, because premultiplication is a fundamental part of layering two images together. So yeah, if you feed a premulted image into AE's layering operation, which premults its inputs, then you'll get a double premult, and thus dark edges. And yeah, I agree that those "gritty edge pixels" are what tells you you're looking at a straight-alpha image (more precisely, an unpremultiplied image, which is what the RGB channels of an image stored with straight alpha contain). I don't know if I'd agree that an image with straight alpha could *ever* contain bright transparent pixels. Like, yeah, the image *file* itself could contain them, but since you'll lose them the second you ever try to composite the image anywhere, can you really say the image contains them? At that point, they're more like an artifact of the storage medium: they were lost the second the data was saved into a straight-alpha container. And, I mean, that's one "good reason why" right there: straight alpha simply can't store that kind of data. Fire, flares, glows... there are workarounds using multiple layers, but if you want to store that kind of stuff in a file, premultiplied handles it perfectly. And then this bit with the Suzannes is where you're losing me. He shows a Blender render (premultiplied, like all 3D renders), shows the raw, unpremultiplied RGB to prove it's premultiplied, and then says that when working with premultiplied data, like CG renders, you have to make sure not to premutiply again in compositing, or else you'll double-premultiply and get dark edges, which all seems correct to me? I don't see any bit where he says that premultiplication is necessary to avoid dark edges, just that the data, whether premultiplied or not premultiplied, must be handled correctly throughout the process to avoid errors? Same as his conclusion at the end.

David Baril
>>93612124

I feel like we are close to agreeing. I'm glad to learn some of the nuances of when premultiplied alpha is still useful in some cases. With AE workflow though, all necessary multiplication for alpha blending always happens under the hood already and you can't skip any, so using pre-multiplied data doubles the multiplication. And that the scenario most people encounter dark edges with. Because you need to postpone multiplication (and even undo it if there was pre-) until AE does it itself at the moment of combining the layers. I assure you straight alpha is the natural state of CG renders. We don't need a better term, that's what it is! Gritty edges = straight alpha, soft edges = premultiplied. I don't think there is a third thing.

David Baril
>>93671259

I think you still have some misconceptions about the nature of straight alpha. You also need to consider that postmultiplication for the purpose of displaying the data can also happen when you are working with a CG viewport, and that peeling off the alpha is just skipping this display step. A legit workflow can still be entirely premultiplication-free from render to comp to output without any issue. I don't think I'm good enough at explaining without any visuals for us to get out of this bind, but thank you for bringing in some nuances about how premultiplied footage still fits in a Nuke workflow.

Carter Burr-Kirven
>>93612124

Think about how sampling happens: the renderer shoots out millions of little rays, scattered inside each pixel, that fly out into the scene and do all their wonderful little lighting and BSDF calculations. Say we've got the edge of a blue sphere crossing through that pixel: 40% of the rays hit the sphere, 60% shoot past it. Once the values are all integrated, that pixel will be darker than the pixel right next to it, since there's less sphere in it! That pixel will be, say 40% blue, and the software will record 0.4 alpha for that pixel, since, again, that's what the rays saw. We've now got an image with black, white and gray alpha values that perfectly line up with the soft, feathery anti-aliased edges in the RGB channels: that's a quote-unquote "premultiplied" image! But nothing was ever multiplied! That's why the terms can be misleading. There's an thread, if you're curious, on Adobe support from a few years ago, that's somewhat infamous within the VFX community: a user asks about Photoshop's EXR handling and gets a rather testy, and incorrect, response from one of the devs, followed by about thirty pages of patient responses from every luminary of the industry, including the developer of the EXR format. I'll put it in another comment since Patreon sometimes seems to want to nuke comments with links in them. The main thing the Adobe guy seems to be struggling with in that thread is the notion that a "premultiplied" image must have been multiplied by its alpha at some point. Which is a very understandable misconception, honestly! It is right there in the name. I'm a fan of using the terms "associated" and "unassociated" instead: less confusion about math, and more clearly tell you exactly what's going on—either the alpha has been merged with the RGB, "associating" them, or it lives totally separately, hidden behind the RGB, and needs to be applied at another step. And yes, total agreement about the way AE handles it in particular: you have no choice, you have to do it AE's way, which is, in my opinion, an inferior way, but that's how it is! I was never disputing that you should use AE's alpha ingest options correctly—that's the whole point CD was trying to get across in this video: know the processes, stay aware, communicate, make sure all conversions are happening correctly!

David Baril
>>93612124

I'm sure some 3D renderers work this way, but AFAIK, Octane and Cycles don't see translucent pixels as dark when you render on transparent. There's no obligation for a pixel that has 40% of a blue sphere motion blur in it to include any other color information than 40% opaque and blue at any point in the render process. Then it gets matted for viewing, or gently blended on a grey checkerboard. None of that makes it to file. Premultiplication is an optional checkbox in Octane. I never use it.

Carter Burr-Kirven
>>93612124

Hm. I can't speak for Octane, but I know I can go into Blender right now and render a sphere with a 100% transparent, emissive material, which will show up in the render preview and will look just fine saved into a EXR, which means it was definitely never multiplied by its alpha, or it'd be gone. I'll freely admit my hands-on experience is almost entirely limited to Blender, though.

David Baril
>>93612124

Exactly! And that would mean it's a straight alpha file, right? Thanks for your explanations, by the way! I learned some very interesting things like how to better composite premultiplied alpha instead of preventively "unpremultiplying" it like AE would. realized some of my assumptions were wrong. But I still think the video is absolutely confusing from 3:46 on, especially considering how premultiplied alpha is dealt with in the specific software that's present in the video. Doing the same thing as nuke would need a whole lot of fiddling with extra layers. And I still think using straight alpha when you render is always the best option.

Carter Burr-Kirven
>>93612124

No, that would mean it’s premultiplied! (Again, terminology: the data was never actually multiplied, but I’m saying Blender rendered it and saved it into the file: if it had somehow rendered an alpha-less, raw-color image, and then multiplied the alpha into that, the emissive object would have disappeared) Yeah, I feel like I can see where you’re coming from in terms of showing AE screenshots while describing general theory, but again I just want to emphasize that AE, specifically, is weird, and given that the takeaway is “pay attention, educate yourself, and make sure your formats are correct,” I guess I’m not as worried about people coming away with the wrong lesson. Have you read Bartosz Ciechanowski’s excellent write up of alpha, by the way? https://ciechanow.ski/alpha-compositing/

David Baril
>>93612124

I'm still very very confused by your first paragraph there, it still reads contradictory even though I think we are aligned on most of the rest. So, the baseline I'm still 99.9% certain of: If you peel away the alpha and the extremely transparent, emissive sphere you rendered and now it looks fully bright, bloated with gritty edged, this is the RGB part of a straight alpha image. If you peel away the alpha channel and the sphere is gone, everything is black, the file has been premultiplied on a black matte.

David Baril
>>93612124

HOLY SHIT I actually just learned something else, looking for the equivalent of Nuke's A+B(1-a) and I found it! The "luminescent premul" blending mode is how you actually skip the double multiplication in After Effects, but there is a twist, a big catch. It gets confusinger but I have a full picture now. The twist is that to use this "luminescent premul" blending mode you also have to prevent AE from messing with your premultiplied source file by lying to it and tell it it's actually seeing straight alpha don't worry about it pass it along as is. That's how you smuggle the unharmed premultiplied version in the timeline with its matte intact underneath the alpha. Now it will have a dark edge in normal blending mode, but will be perfect in "luminescent premul" which skips the unnecessary multiplication. The way you know if you picked the right alpha, usually, you see the dark edges, would think "ah I picked the wrong kind of alpha" and correctly switched to "premultiplied" which then makes AE mathematically undo the premultiplication away from the imported footage before it can make it to the comp. That makes it compatible with the "normal" blending mode (a function that you can't tell to skip multiplying the RGB of the FG layer by its alpha, making it only work in straight alpha) with only a bit of color loss. Also, Turns out undoing the premultiplication of imported files before comping, by default, is not bad practice! A cursory look at Nuke's official reference tells me footage should always be unpremultiplied before doing any color correction. After Effects' way of doing things is not that crazy after all!

Major Menace
>>93646358

He did include that though, when he says that in anything more than a gif there are grey values, which you don't have in single bit alpha

CaptainDisillusion
>>93612124

David, thank you for flagging the issue, taking the time to make a vid and the many...many comments :) I see you've already independently arrived at what I've also learned in the last few days by talking to literal people from ILM and hearing about what Adobe developers say. To add to your last comment, the only file format that seems to work exactly right with luminescent premult is EXR. When you do the fake straight interpretation trick with a TIFF or TGA, etc. it sort of works, but the result is slightly over-bright. It's almost like premult-interpreted EXRs look like straight-interpreted TIFFs, and straight-interpreted EXRs look perfect. I'm sure there's some simple numbers explanation for that, but anyway. I am working on a small add-on section to the video that addresses how most compositor apps force-straighten premult images. It's impossible to explain everything perfectly in a frantically-paced overview video, but at least it will be a tiny nod to this aspect of things.

David Baril
>>93612124

Thanks for hearing me out and investigating further! It's almost impossible to explain in a punchy video (even though you pull it off consistently) and also super hard in text I found out. It's been surprisingly hard to tease out and explain my assumptions so I can include them in an explanation that is accessible, and I'm glad I corrected the incorrect assumptions along the way. It's been a journey. The EXR/Tiff/TGA discrepancy I'd be inclined to blame some color management mishap, which belongs in a land of confusion and quirks of its own. One that I feel like staying away from, right now, to everyone's relief. Anyways, EXR ftw! I just realized every edit I do probably shows up as a notification, so you're seeing the real number of times I came back here to type. Which is way too much. Sorry I get carried away :) David Out

Jerrad Pierce
>>93646358

Yes, but there were no accompanying visuals. So unless you're familiar with already it, that may be insufficient. But I also think it's relevant because depending on the original background color that's been made transparent you can end up with a similar dark fringe or a bright/colored halo.