Dr. Lupton, Sorry for the slow response. I simply defined the following: typedef boost::gil::pixel<float, boost::gil::gray_layout_t> gray_float_pixel_t; typedef boost::gil::image<gray_float_pixel_t, false> gray_float_image_t; typedef gray_float_image_t::view_t gray_float_view_t; typedef gray_float_image_t::const_view_t gray_float_const_view_t; As Dr. Bourdev advised, I do not use with these typedefs any of the color conversion operations offered by GIL. Apparently those rely on the scaling properties of the float wrapper type. So far, all I have done with these typedefs is ... 1. construct views using interleaved_view and pixel data pointed to by [const] float*, as illustrated near the beginning of the GIL tutorial 2. create x- and y- iterators for the views to apply row- and column-oriented algorithms I implemented reasonably fast gray morphology operations for rectangular structure elements. I wouldn't mind offering this code for contribution to some open source project; but this work is for my corporate employer, from whom I would need to get legal permission. Cheers. On Feb 18, 2011, at 12:27 PM, Robert Lupton the Good <rhl@astro.princeton.edu> wrote:

...

With this, the unit test for my gray opening function with an unscaled float image now compiles and works fine.

Does this mean that you have some clean way to handle gil images that don't automatically scale into [0,1]? If so, can we have it pushed into the next boost release?

I have a clunky version of this that I'm not proud of, but I certainly need. I'm an astronomer, and the values in my images (unsigned short, int, float) are directly related to the number of photons detected so scaling is a real problem.

R

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users