From: Amitha P. <pe...@cs...> - 2002-10-09 14:18:35
|
Peter Vanroose writes: > But since vil2_image_view is a templated class, users are free to template > over vil_rgb (a 3-byte pixel type). Although we would strongly discourage > this. > > The only trace of this is the fact that vil2_pixel_type can assume the > value VIL2_PIXEL_TYPE_RGB_BYTE, meaning that's a 3-byte pixel at the lowest > level. I don't think this has to be removed, only its use should be > discouraged. I would disagree somewhat here on the actual implementation. The pixel_format type is currently in vil_image_view. And I suggest that the view need not support vil_rgb pixel formats at the view level. I can understand such a flag at the image_resource level; here, it would be a description of how the data *actually* is. And this could be RGB. But that aside, my main concern is with vil_rgb appearing in the vil2-supplied conversion, print and math routines. I don't think they need to be, and I think those routines can easily be generalized to planes!=3. I don't think a user, using just a view, needs to know anything other than the number of planes and the type of each "pixel". (That is, typeof(img(i,j,p)) ). I am concerned that when there is even some trace of vil_rgb, users will latch onto that as the way to handle RGB images, because they have a mental separation between greyscale and RGB. It won't be obvious to many that it's more consistent to just deal with 3 planes instead. And they will write algorithms for vil_image_view< vil_rgb<...> > instead of writing them for vil_image_view<...> and 3-planes. Unfortunately, this kind of thing happens too often, and it creates problems in the future with system integration and such.[1] I really can't think of any place in vil2 where explicit support for vil_rgb would be useful. I offer to pull out all references to vil_rgb from vil2, while trying to maintain the existing functionality. I will begin to do this on Friday, unless someone has objections. Amitha. [1] Yes, user education is the key to most of these problems, but limited time and limited means conspire to make this not always possible. |