Lagarith's RGB32 & RGBA. Difference?

[ValentineStone]

So Lagarith's page here states:

Lagarith is able to operate in several colorspaces - RGB24, RGB32, RGBA, YUY2, and YV12.

Are RGB32 and RGBA different things?

If so how do I switch between RGB24 and RGB32 in Lagarith settings when I record RGB (not RGBA)?

Also, Vegas shows that just RGB in Lagarith settings gives video 32bits for colorspace (Ex. 1280x720x32).
Where is that fourth channel coming from (8*3+8), or is it not the forth channel, is it that RGB32 thing?

I'm so confused...

P.S.: This thread came from this one concerning Smart Rendering in Vegas as separate question evolving from the original one.

[Cornucopia]

Functionally, they should be the same. Internally, they probably differ in their channel ordering (planar vs. packed).

Vegas is probably just keeping an extra channel available for an alpha, whether it is used/needed or not. Kind of like keeping an extra seat at the dinner table for occasional strangers/guests. AFAIK, Vegas doesn't actually store/render that 4th channel unless you specify it to do so.

Scott

[racer-x]

how do I switch between RGB24 and RGB32 in Lagarith settings when I record RGB (not RGBA)?

Switch between RGB32 and RGB24 here:

[ValentineStone]

Vegas is probably just keeping an extra channel available for an alpha, whether it is used/needed or not. Kind of like keeping an extra seat at the dinner table for occasional strangers/guests. AFAIK, Vegas doesn't actually store/render that 4th channel unless you specify it to do so.

^ Alright, thanks, I can see that happening, I'll look for the switch concerning this in Vegas.

Switch between RGB32 and RGB24 here:
RGB32 = RGBA
RGB24 = RGB (Default)

^ Well, that is what I guessed, and I see the point that extra 8 bits are there for transparency, therefore 32 is 24 collor + 8 for alpha, but why then Lagarith's page here states that it can do RGB24 AND RGB32 AND RGBA?:

Lagarith is able to operate in several colorspaces - RGB24, RGB32, RGBA...

I mean, is that a typo or is there something deep and crazy about that statement?

[newpball]

Isn't RGB32 just nomenclature to indicate you want 32 bit processing (which due to CPU-architectural reasons can be more efficient than 24 bit) of 24 bit video?

[poisondeathray]

The description on that page might be confusing

RGB24 is RGB. RGB32 is RGBA. These are 8bits per channel formats. 8 red + 8 green + 8 blue + 8 alpha = 32 . Each channel has 2^8 possible values or 256. They range from 0 to 255.

It's not the same thing as 32bits per channel . 2^32 values per channel. That's a big number. Very high level of precision

Most RGB formats are actually interpreted as RGB32 in many programs. Even if there is no actual alpha channel, it's a "dummy" alpha channel. I'm not a computer programmer but it has something to do with data or memory alignment

[hello_hello]

MagicYUV does a bit of RGB32 and RGBA distinguishing I don't really understand.
http://magicyuv.com/index.php/features

Or maybe someone can reverse engineer the RGBA tooltip into English.



It distinguishes between RGB32 and RGBA in the list of input colour spaces, but I don't quite understand why.



So it'd appear RGB32 is often really RGB24 with a dummy alpha channel, but when is RGB32 really RGB32?
It's described here as having a greyscale colour channel. Is that the distinction between RGB32 and RGBA? Greyscale colour channel vs a transparency/alpha channel?
http://en.wikipedia.org/wiki/RGB_color_model#Video_framebuffer

[poisondeathray]

This is what I was referring to. Many programs treat RGB24 (ie 3 channel "regular" RGB) as RGB32. eg. vdub is like this. There is a dummy alpha channel for alignment purposes or some other programmatic or memory reason. Some programmer will know the technical reason. AE does it correctly. It correctly identifies and distinguishes between RGB24 and RGB32. That's how it should be. 3x8 should be 24, not 32 - at least in "layman's" math. There shouldn't be a "dummy" alpha channel - just "because"

It's described here as having a greyscale colour channel. Is that the distinction between RGB32 and RGBA? Greyscale colour channel vs a transparency/alpha channel?
http://en.wikipedia.org/wiki/RGB_color_model#Video_framebuffer

No - that's exactly what an alpha channel is. It's a black/white representation of areas that are transparent. That's why that link calls it " fourth greyscale color channel as a masking layer, often called RGB32.". 100% white is 100% transparent. Shades in between are intermediate in transparency. RGB32 is RGBA

The confusion lies when there is a "dummy" alpha channel. If there was no "dummy" there would be no confusion. At least for the non programmatic layman, it's "dumb" to have a "dummy"

[Cornucopia]

Yeah and that magicyuv tool tip was the opposite of helpful-it sounds like it just further confused the topic for those here who were already hazy in their understanding.

Scott

[hello_hello]

Well only one other person has posting here since I posted the screenshot and poisondeathray doesn't seem further confused.

[poisondeathray]

Are you still confused? Using magicyuv's nomenclature, RGBA is always RGB32 with active alpha (ie there is usable transparency data)

Lagarith is no different. When you have RGB selected, that is always functionally RGB24, even though some programs may treat it as RGB32 (with dummy alpha). If you need a usable alpha channel you MUST select RGBA in lagarith. Similarly, if you NEED the alpha channel for transparency, you MUST select RGBA in magicyuv (or the AYUV option for YUV444 if using YUV)

So actual RGB can be RGB24 or RGB32, depending on how software handles it. That is why this is a stupid way of doing it. One "label" can mean 2 things. (It's not magicyuv's fault, that's they way some codecs and programs handle RGB). A better, clear way of doing it is RGB24 always means RGB, RGB32 always means RGBA. 8x3=24. 8x4=32. Makes sense. If there was no dummy channel, "math" would work properly.

(To be more specific, RGBA is actually BGRA in programs like AE. It's functionally the same thing, just the channel storing order is different)

[ValentineStone]

Ok, thanks everybody, I got it all sorted out now.

In terms of why it's all weird like that with RGB possibly being both RGB24 and RGB32 I do think that there might be a structural difference (planar vs packed), just like Scott (Cornucopia) pointed out earlier.

I can see RGB24 being either packed or planar, while RGB32 with dummy 4th channel is probably (just a guess) planar only for algorithm efficiency reasons, cause making a jump over a dummy channel in packed will end up increasing coding/decoding times a bit.

And finally, I figured, Lagarith's page probably states that it supports RGB32 as a thing due to the fact that source may be RGB32 with that dummy channel being there and hoping to be handled correctly.

Thanks again,
Valentine

[Ignus]

Hi all,

Oh, my...
Thought I'd clarify it a bit, as there are so much confusion here.

RGB24 is a 3-byte per pixel interleaved (packed) RGB format, with bytes in memory: BGRBGRBGR...
RGB32 is a 4-byte per pixel interleaved (packed) RGB format with a dummy 4th byte, with bytes in memory: BGRXBGRXBGRX...
RGBA is a 4-byte per pixel interleaved (packed) RGBA (with-alpha) format with a valid alpha channel, with bytes in memory: BGRABGRABGRA...

From a memory layout perspective, RGB24 is different, while RGB32 and RGBA are identical.
The source of the confusion is that from a codec/application perspective, there is no way to distinguish RGB32 from RGBA. The reason for that is that they both use the same format id number (in simple terms).
So RGB32 and RGBA are the same thing, the only difference is how you interpret the data: is the alpha valid or not (garbage).
Some applications interpret it as without-alpha (dummy 'X' value above), like VirtualDub.
Some applications interpret it as with-alpha, like After Effects.

From a codec perspective, when a codec encounters RGB32/RGBA, it also has to interpret it some way.
If the codec interprets it as RGB32 while the application which sends it actually meant RGBA, then the alpha channel will be lost, as the codec will drop it, thinking it is dummy data.
At the same time however, if the codec interprets it as RGBA, while the sending application meant RGB32, then the dummy 4th channel will be compressed as alpha, wasting space and time with compression.

This is the reason for the existence of this option, to tell the codec how to interpret incoming RGB32/RGBA data.

There are more intricacies involved, but I hope that clears up the confusion somewhat.

EDIT: The existence of RGB32 without alpha is purely because of performance reasons. It is vastly more easy and efficient to handle RGB32 than RGB24, because the processor accesses data faster in 32-bit (4-byte) increments than 24-bit (3-byte) increments.

Greets,
I.

[ValentineStone]

Wow, this ^ is awesome! Now I don't have to guess all night all day, thank you so very much Ignus, that is exactly the kind of answer I was hoping to get.
See, I'm a first year student in programming so while now this video stuff is kinda personal hobby thing, the technical information will come in super handy later on.
Compact, yet deep enough to give the understanding of "how it works", simply put - awesome!
Valentine

[Ignus]

You're welcome.
And don't worry, when I was first year in programming I wouldn't have thought in my wildest dreams I would be writing a video codec anytime in the future...
So keep it up

Greets,
I.

[hello_hello]

Ignus,
Looking at my screenshots in post #7, if I select RGBA as the accepted colourscpace, do i still need to check the "enable RGBA compression" tooltip, or would it be treated as RGB32 until the option is checked?

Thanks.

[Ignus]

Ignus,
Looking at my screenshots in post #7, if I select RGBA as the accepted colourscpace, do i still need to check the "enable RGBA compression" tooltip, or would it be treated as RGB32 until the option is checked?

Thanks.

Yes, you have to select.
If you select RGBA as the accepted colorspace, but don't check Enable RGBA, then the input is treated as RGB32, which will not be accepted, since it's not RGBA. You can try in VirtualDub, it will refuse to compress this way.

Yes, this really can be a bit confusing, but works sort of like a double check: you enable RGBA compression (treat RGB32 as RGBA) and allow only RGBA compression (accept only RGBA/RGB32, and not RGB24 for example).

Greets,
I.