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.
delete and rename cops, not working?
6156 8 1- probbins
- Member
- 1145 posts
- Joined: July 2005
- Offline
- pbowmar
- Member
- 7024 posts
- Joined: July 2005
- Offline
- probbins
- Member
- 1145 posts
- Joined: July 2005
- Offline
- JColdrick
- Member
- 4140 posts
- Joined: July 2005
- Offline
- malexander
- Staff
- 5156 posts
- Joined: July 2005
- Offline
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 :?:
Progress, I guess :?:
- probbins
- Member
- 1145 posts
- Joined: July 2005
- Offline
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.
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.
“gravity is not a force, it is a boundary layer”
“everything is coincident”
“Love; the state of suspended anticipation.”
“everything is coincident”
“Love; the state of suspended anticipation.”
- JColdrick
- Member
- 4140 posts
- Joined: July 2005
- Offline
- probbins
- Member
- 1145 posts
- Joined: July 2005
- Offline
- JColdrick
- Member
- 4140 posts
- Joined: July 2005
- Offline
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.
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.
John Coldrick
-
- Quick Links