Re: [Vxl-users] Could vil_image_view<myType> be made to work?

[Ian S. <ian...@st...>]

Eric,

vil_image_view has not been designed to explicitly reject non standard 
types, but there are obviously a few problems. I've committed a few 
simple relaxations of the assertions to permit at least simple use of 
vil_image_view<myType>.

There is now a test case demonstrating the behaviour in 
test_non_standard_type() in core/vil/tests/test_image_view.cxx
In order to use myType I had to define a few template specialisations:
for convert_components_from_planes() and vil_print_value(). Whilst it 
would be nice if this was unnecessary, the cost would be significantly 
reduced functionality and ease of use of vil_image_view<standard_type>s.

No doubt there are other library functions that are too aggressive in 
their assertions with vil_image_view<myType>. Let me know if you find them.

Ian.

Eric Moyer wrote:
> 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.
> 
> --Eric
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Vxl-users mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-users