https://code.ros.org/trac/ros-pkg/ticket/5104

I filed a ticket on this subject, but I imagine that it might warrant
discussion on the list here as well. Below I've included the text from
the ticket with a few edits:



ROS and OpenCV use a convention that append bits-per-channel (BPC)
which is in contrast with the bits-per-pixel (BPP) convention which
AFAIK is the much more common standard. (quick source: googling
+"rgb8", vs +"rgb/8", vs +"rgb24")

While bits-per-channel is used in the wild as well in some cases, it's
virtually always with a '/' to differentiate that the appended number
refers to per-channel rather than per-pixel, which of course would not
make for a valid symbol name for our purposes.

The difference from the BPP convention is bit of a problem for two
reasons in that 1)the competing BPP convention has namespace
collisions which could cause significant confusion for things like
RGB8 (RGB 3:3:2 vs RGB 8:8:8) and 2) in general with BPC it is
difficult/impossible to represent non-homogeneous channel formats like
RGB 3:3:2 or RGB 5:5:6 (RGB16BPP).

To bring this out of the hypothetical, I actually have been using a
camera which puts out RGB 5:5:6, and have to convert it to RGB 8:8:8
for use with ROS via sensor_msgs::Image.

Since if this naming convention were changed the namespace collision
would create compilable code that had different semantics (in the case
of RGB8), I don't imagine this can be easily addressed, and so I
expect it will be closed as a "WONTFIX". However since I didn't see
anyone bring this up in the quick search I did, I figure it's worth
reporting so that the decision could be recorded for posterity.

In case it does look like something that would be a desirable fix for
some future version I might suggest a third convention to avoid the
namespace collision semantic change problem:

Using the X:X:X convention as CCC_X_X_X such that:

...neither RGB 3:3:2 nor RGB 8:8:8 would be RGB8

but rather RGB_3_3_2 and RGB_8_8_8.




I didn't think to suggest in the bug report the possibility of
differentiating with RGB8_BPC or RGB8_BPP, though that might be an
improvement that would be viable as well, though not as versatile as
CCC_X_X_X.


Any thoughts?


     Andy