Re: [Boost-users] [GIL] gray pixel iterator in generic algorithm

Subject: Re: [Boost-users] [GIL] gray pixel iterator in generic algorithm
From: Curtis Gehman (curtis2006_at_[hidden])
Date: 2010-12-23 00:27:30

Lubomir,

I'm performing quantitative analysis with a physically significant  
gray scale.  So I don't expect to do any color conversion.

Thanks for your response.  I'll try out your suggestion when I return  
from my Christmas vacation.

Curtis Gehman
Burlingame, CA

On Dec 22, 2010, at 2:23 PM, Lubomir Bourdev wrote:

> Hi Curtis,
>
> GIL's default float type is not "float" but a special float wrapper  
> to ensure that the range is 0..1
> The built-in float has a range from -infinity to infinity and that  
> does not work well when converting a value from another channel type.
> If you want an image with a standard float you can create it like  
> this (untested)
>
> typedef pixel<float,gray_layout_t> gray_float_pixel_t;
> typedef image<gray_float_pixel_t,false> gray_float_image_t;
> typedef gray_float_image_t::view_t gray_float_view_t;
> ...
>
>
> However, don't use such images with algorithms that require channel  
> ranges, such as color conversion.
>
> Lubomir
>
>
> On Dec 20, 2010, at 11:53 PM, Curtis Gehman wrote:
>
>> I'm trying to use GIL pixel iterators in a generic STL-style  
>> algorithm.  I'm primarily using GIL for the generic 2D iterators.   
>> And in my context, I'm only interested in grayscale images.
>>
>> The value_type associated with GIL iterators is a pixel type,  
>> which typically is an object representing multiple channels (e.g.,  
>> colors).  It makes sense that comparison operators (e.g., <) are  
>> not defined for general color pixel types.
>>
>> For grayscale images, however, it makes sense that common  
>> arithmetic and comparison operators would be defined for the pixel  
>> type.  This seems to be the case for the 8-bit grayscale GIL type  
>> (gray8_view_t).  The iterator's value_type appears to be  
>> seamlessly evaluated to an unsigned char, exactly as I would expect.
>>
>> When I try to use a float image view type, however, the same magic  
>> doesn't seem to happen.  Below is some toy code that demonstrates  
>> the issue.  When the last line is knocked out with "//", the code  
>> compiles.  But with that second template instantiation (for  
>> floats) there, the compiler (gcc 4.2 and VC++2010) exits when it  
>> does not find an operator< for the iterator's value_type when  
>> instantiating for gray32fc_view_t.
>>
>> I suppose that I can roll my own  
>> less<iterator_traits<SrcView::x_iterator>::value_type> functors.   
>> But I just started using GIL, and I'm hoping that there is a  
>> simpler solution.
>>
>> Any ideas?
>>
>>
>> #include <algorithm>
>> #include <iterator>
>> #include <vector>
>>
>> #include <boost/gil/gil_all.hpp>
>>
>> namespace g = boost::gil;
>>
>> using std::vector;
>> using std::iterator_traits;
>>
>> template <typename SrcView> inline
>> vector<typename iterator_traits<typename  
>> SrcView::x_iterator>::value_type>
>> row_min(const SrcView& src)
>> {
>> 	typedef typename iterator_traits<typename  
>> SrcView::x_iterator>::value_type value_t;
>> 	vector<value_t> result;
>> 	for (int y = 0; y < src.height(); ++y)
>> 	{
>> 		result.push_back(*std::min_element(src.row_begin(y), src.row_end 
>> (y)));
>> 	}
>> 	return result;
>> }
>>
>>
>> // Explicit template instantiation
>>
>> // Works for gray8c_view_t.
>> template  
>> vector<iterator_traits<g::gray8c_view_t::x_iterator>::value_type>  
>> row_min(const g::gray8c_view_t& src);
>>
>> // Compile error for gray32fc_view_t.
>> // No operator< for  
>> iterator_traits<g::gray32fc_view_t::x_iterator>::value_type.
>> template  
>> vector<iterator_traits<g::gray32fc_view_t::x_iterator>::value_type> r 
>> ow_min(const g::gray32fc_view_t& src);
>>
>> <ATT00001..txt>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users