I'm a bit confused with the way the delete cop is working.

If I delete the alpha(A) channel the information (mmb) says it's still there. The docs mention that the colour and alpha channels can't be deleted, they are just cleared to black.
Okay, that's fine to a point.

If I use a rename cop to rename the colour channels from “C” to “colours”, both designations remain. The rename cop also gives a yellow warning.
“Warning: Can not completely rename planes C and A. Default plane(s) added.”

This behaviour, along with the delete cop, make for very complicated channel selections.
One of the most obvious problems is in the viewer. ie: since the C channel name remains after a rename you have to explicitly select the renamed channel to view your image.

For historical reasons we needn't get into, C and A are always there, no matter what. It's unfortunate, but there you go. It's not SESI's fault, is all I can say )

Cheers,

Peter B

Hmmm, you re-writing history Peter?
Up until very recently the normal behaviour was that deleted channels disappeared and only the renamed channel appeared.

I may be wrong but I believe Peter's referring to why it's changed, not that it's never been otherwise in Houdini. Seems that some formats want their RGBA…

Cheers,

J.C.

The persistant RGBA behaviour was added sometime around 6.0. While it does make it clearer for some people (especially users of compositors that have a rigid RGBA structure), I do miss the days where you could load a single Z map and reference that easily, without the token C/A channels.

Progress, I guess :?:

Well, if we are stuck with keeping the original rgba channels, can we get rid of the
warning message in the rename cop.
“Warning: Can not completely rename planes C and A. Default plane(s) added.”

Can we compromise and have a setting somewhere that turns on and off the visibility of the original channels. Keeping these around as well as the renamed channels can get very complicated very quickly. Remember that a renamed C channel generates the new name plus the individual channel declarations.

Urg. Hidden channels? Not so sure I like the sound of that. Sounds like a recipe for confusion, not clarity.

Cheers,

J.C.

I agree John, but what else is there? If the original channels are kept then with any type of
complex network you get a nightmare list of redundant channels.

I agree, the warning is a little misleading(“completely” rename?) - perhaps the implementation isn't as clean as it could be. First off, if you *can't* truly rename RGBA, then don't allow them in the field. Copy them, sure, but don't let an illegal rename equate to a copy and a create! That's not very elegant.

I think the reasoning behind all this is that for any compositor/file format, you could conceivbly punch any node into some sort of framestore. Since you need RGB for a framestore, it must always be available, otherwise you'll need to hack around things, generating them on the fly. I sense from Mark's comment, though, this was done to appease people from a compositing background that don't have experience with non-RGBA channels. That would be unfortunate, as this is the norm in many applications now.

Anyway, I think I see your point, I just think that hiding channels isn't the way - you need an interface for that, that means you'll make errors and relevant RGB channels will disappear…to repeat…ugh.

Here's a crazy thought - what about a Deep Raster File Node(or perhaps a better name? ). This would be a channel of data that doesn't conform to the RGBA standard but otherwise could “channel” usable data of any kind? This would break out that paradigm as an optional usage rather than being “forced” on old-school compositors?

Cheers,

J.C.