|Twice now, in the past year, I have made vil_image_view<myType> and run into the problem that any type in an image needs to be added to the vil_pixel_format enums. The first time, the type was bool. Thinking it might be useful to others, I made some local modifications to my copy of the source that I may still submit someday if I ever get around to cleaning it up and writing test code. (I probably should have just stuck with an image of vxl_byte and set them to 0 or 255.)|
However, yesterday, I ran into the problem again. There are work-arounds, which I will be implementing, but I feel like I am programming in FORTRAN 77, implementing arrays of records by using several arrays of scalars. However, it would be nice to be able to put any type in an image as long as it behaves reasonably like a number (operator+, operator-, operator*...cast to double).
Right now my code crashes due to an assertion violation on memory allocation because component size for VIL_PIXEL_FORMAT_UNKNOWN is 0. I can't change this without adding my special purpose type to the list of types, and that is changing the library.
It appears that the reason for the hard-coded enums is that the automagic load and conversion functions need to know the types without using RTTI. Is there any way to separate this from the rest of the image_view class in some way so that the enums are only used on load and save and convert (at which point an assertion violation would be appropriate).
This is probably too much work for a little-used feature that has a work-around. However, because the general contract for a template'ed container class is that you should be able to use any type you want as long as it provides appropriate operations, it doesn't sit well with me that vxl_image_view doesn't fit this contract. And if it did fit the contract, I, at least, would use the functionality.