You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(4) 
_{Dec}
(6) 

2002 
_{Jan}
(68) 
_{Feb}
(72) 
_{Mar}
(46) 
_{Apr}
(44) 
_{May}
(40) 
_{Jun}
(54) 
_{Jul}
(26) 
_{Aug}
(86) 
_{Sep}
(95) 
_{Oct}
(151) 
_{Nov}
(65) 
_{Dec}
(34) 
2003 
_{Jan}
(22) 
_{Feb}
(70) 
_{Mar}
(24) 
_{Apr}
(28) 
_{May}
(50) 
_{Jun}
(31) 
_{Jul}
(17) 
_{Aug}
(42) 
_{Sep}
(27) 
_{Oct}
(71) 
_{Nov}
(27) 
_{Dec}
(71) 
2004 
_{Jan}
(40) 
_{Feb}
(30) 
_{Mar}
(20) 
_{Apr}
(22) 
_{May}
(41) 
_{Jun}
(9) 
_{Jul}
(24) 
_{Aug}
(41) 
_{Sep}
(35) 
_{Oct}
(8) 
_{Nov}
(5) 
_{Dec}
(4) 
2005 
_{Jan}
(27) 
_{Feb}
(13) 
_{Mar}
(18) 
_{Apr}
(7) 
_{May}
(10) 
_{Jun}
(36) 
_{Jul}
(28) 
_{Aug}
(17) 
_{Sep}
(1) 
_{Oct}
(11) 
_{Nov}
(12) 
_{Dec}
(15) 
2006 
_{Jan}
(99) 
_{Feb}
(5) 
_{Mar}
(31) 
_{Apr}
(26) 
_{May}
(20) 
_{Jun}
(33) 
_{Jul}
(45) 
_{Aug}
(18) 
_{Sep}
(2) 
_{Oct}
(19) 
_{Nov}
(3) 
_{Dec}
(8) 
2007 
_{Jan}
(1) 
_{Feb}
(15) 
_{Mar}
(20) 
_{Apr}

_{May}
(4) 
_{Jun}
(6) 
_{Jul}
(11) 
_{Aug}
(11) 
_{Sep}
(11) 
_{Oct}
(19) 
_{Nov}
(25) 
_{Dec}
(46) 
2008 
_{Jan}
(42) 
_{Feb}
(20) 
_{Mar}
(43) 
_{Apr}
(24) 
_{May}
(4) 
_{Jun}

_{Jul}
(19) 
_{Aug}
(63) 
_{Sep}
(33) 
_{Oct}
(17) 
_{Nov}
(36) 
_{Dec}
(20) 
2009 
_{Jan}
(36) 
_{Feb}
(18) 
_{Mar}
(144) 
_{Apr}
(36) 
_{May}
(11) 
_{Jun}
(7) 
_{Jul}
(8) 
_{Aug}
(21) 
_{Sep}
(33) 
_{Oct}
(7) 
_{Nov}
(2) 
_{Dec}
(1) 
2010 
_{Jan}
(33) 
_{Feb}
(3) 
_{Mar}
(34) 
_{Apr}
(2) 
_{May}
(1) 
_{Jun}
(2) 
_{Jul}
(3) 
_{Aug}
(28) 
_{Sep}
(8) 
_{Oct}
(12) 
_{Nov}
(11) 
_{Dec}
(44) 
2011 
_{Jan}
(30) 
_{Feb}
(10) 
_{Mar}
(8) 
_{Apr}
(23) 
_{May}
(8) 
_{Jun}
(9) 
_{Jul}
(3) 
_{Aug}
(9) 
_{Sep}
(5) 
_{Oct}
(9) 
_{Nov}
(11) 
_{Dec}
(24) 
2012 
_{Jan}
(6) 
_{Feb}
(32) 
_{Mar}
(8) 
_{Apr}
(26) 
_{May}
(13) 
_{Jun}
(51) 
_{Jul}
(21) 
_{Aug}
(7) 
_{Sep}
(9) 
_{Oct}
(13) 
_{Nov}
(5) 
_{Dec}
(10) 
2013 
_{Jan}
(56) 
_{Feb}
(6) 
_{Mar}
(15) 
_{Apr}
(4) 
_{May}
(24) 
_{Jun}
(4) 
_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(1) 
_{Dec}
(8) 
2014 
_{Jan}
(7) 
_{Feb}

_{Mar}

_{Apr}

_{May}
(12) 
_{Jun}
(3) 
_{Jul}
(7) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(19) 
2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}
(22) 
_{Dec}
(25) 
2016 
_{Jan}
(9) 
_{Feb}
(9) 
_{Mar}
(13) 
_{Apr}

_{May}

_{Jun}
(2) 
_{Jul}
(4) 
_{Aug}

_{Sep}

_{Oct}
(11) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2

3

4

5

6

7

8
(2) 
9
(2) 
10
(3) 
11
(13) 
12
(2) 
13
(6) 
14
(17) 
15
(2) 
16
(1) 
17
(2) 
18

19

20

21

22

23

24
(9) 
25
(6) 
26

27

28

29

30
(1) 
31
(2) 


From: Wheeler, Fred (CRD) <wheeler@cr...>  20020125 15:40:55

Not using template functions leads to a maintenance problem. A vil_round must be defined for all possible pixel types for which template <class T, class U> bool vil_interpolate_bilinear is instantiated, including combos with rgb<whatever type>. If vil_round could be a templated function with a default (ordinary cast) and specializations (better rounding from floating to integral) we would have a nice solution, but it sounds like msvc won't support that. I agree that a conditional inside the loop should be avoided, but in this case I'm sure it would be compiled out. That's moot anyway, since that technique would not work due to the absence of >= ops for rgb<> types. Fred Wheeler Original Message From: Ian Scott [mailto:ian.m.scott@...] Sent: Friday, January 25, 2002 10:26 AM To: Wheeler, Fred (CRD); Blezek, Daniel J (CRD) Cc: Vxlmaintainers (Email) Subject: RE: [Vxlmaintainers] casting instead of rounding in templates If the rounding/summation function is a separate inline function, having 10 or 20 specialisations doesn't sound like a big deal to me. Afterall they can probably be four lines each. e.g. (roughly  the code may be wrong) inline vil_round(float * out, double in, unsigned char dummy){ *out = in; } inline vil_round(unsigned char * out, double in, unsigned char dummy){ *out = in + ( (in >= T(0.0)) ? T(0.5) : T(0.5) ); } Dan  n.b no need for partial specialiations here. Having 10 or twenty of these sounds fine to me, unlike having my code run twice as slowly because it is performing an unnecessary test in the middle of a loop. Ian. > Original Message > From: Wheeler, Fred (CRD) [mailto:wheeler@...] > Sent: Friday, January 25, 2002 3:10 PM > To: Ian Scott > Cc: Vxlmaintainers (Email) > Subject: RE: [Vxlmaintainers] casting instead of rounding in > templates > > > I agree that oneline template inline function with > specializations to do this conversion would be a > good solution. The only problem I see is that it would need > to be specialized for so many cases. We > would want special rounding whenever a floating type is > converted to an integral type. We would have > a specialization for > > <all integral types, all float types> > > by which I mean <unsigned char, float>, ... <short, double>, > ... <long long, double> and everything > in between, about 20 odd specializations. Actually, I guess > we can forget about float, because if > the pixels are float, the righthandside will be converted > to double, so now were down to 10 or so. > Oops, but then there is long double, back up to 20. > > So many specializations does not seem like a clean solution to me. > > Fred Wheeler > > > Original Message > From: Ian Scott [mailto:ian.m.scott@...] > Sent: Friday, January 25, 2002 9:57 AM > To: Wheeler, Fred (CRD) > Cc: Vxlmaintainers (Email) > Subject: RE: [Vxlmaintainers] casting instead of rounding in > templates > > > I would have thought that template specialisations were more > appropriate. > They are certainly more efficient that having an if in the > middle of a loop. > > > > Original Message > > From: Wheeler, Fred (CRD) [mailto:wheeler@...] > > Sent: Thursday, January 24, 2002 9:50 PM > > To: vxlusers@...; > > vxlmaintainers@... > > Subject: [Vxlmaintainers] casting instead of rounding in templates > > > > > > > > (is vxlmaintainers a subset of vxlusers?) > > > > In file "vil_interpolate.txx", function "template <class T, > > class U> bool vil_interpolate_bilinear", > > the final line is: > > > > *out = U(pix00 * weight00 + pix10 * weight10 + pix01 * > > weight01 + pix11 * weight11); > > > > *out is of type T. This is a nice and general template, but > > if both T and U are integral types, then > > the right hand side above gets promoted to double because the > > weight* vars are type double. Then, > > the cast to type U gets to an integer by truncation. I think > > it would be much better to go to the > > nearest integer. This is causing problems for me and I'd > > like to fix it. I have not yet come up > > with a clean and easy way, so I'm looking for suggestions. > > My favorite attempt so far is below. > > Alas, it is really not sufficient. For one, I don't think > > vcl_numeric_limits works. For two, this > > breaks when instantiated with T as an rgb<unsigned char> (not > > quite the right name, but you know what > > I mean) type because both the if and else clauses must be > > compiled even if only one will be used for > > a certain type, and there is no >= for the rgb<unsigned > > char>. Any suggestions or pointers? > > > > T x = pix00 * weight00 + pix10 * weight10 + > > pix01 * weight01 + pix11 * weight11; > > > > // conversion done depending on the template types > > // when casting a floating type to an integral type, round > > to nearest int > > if (std::numeric_limits<U>::is_specialized && > > std::numeric_limits<T>::is_specialized && > > std::numeric_limits<U>::is_integer && > > ! std::numeric_limits<T>::is_integer ) { > > // add (subtract) 0.5 if greater (less) than 0 > > // so truncation will lead to the nearest integer > > *out = U( x + ( (x >= T(0.0)) ? T(0.5) : T(0.5) ) ); > > } else { > > *out = U(x); > > } > > > > Thanks, > > Fred Wheeler > > > > _______________________________________________ > > Vxlmaintainers mailing list > > Vxlmaintainers@... > > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > > > 
From: Ian Scott <ian.m.scott@st...>  20020125 15:24:12

If the rounding/summation function is a separate inline function, having 10 or 20 specialisations doesn't sound like a big deal to me. Afterall they can probably be four lines each. e.g. (roughly  the code may be wrong) inline vil_round(float * out, double in, unsigned char dummy){ *out = in; } inline vil_round(unsigned char * out, double in, unsigned char dummy){ *out = in + ( (in >= T(0.0)) ? T(0.5) : T(0.5) ); } Dan  n.b no need for partial specialiations here. Having 10 or twenty of these sounds fine to me, unlike having my code run twice as slowly because it is performing an unnecessary test in the middle of a loop. Ian. > Original Message > From: Wheeler, Fred (CRD) [mailto:wheeler@...] > Sent: Friday, January 25, 2002 3:10 PM > To: Ian Scott > Cc: Vxlmaintainers (Email) > Subject: RE: [Vxlmaintainers] casting instead of rounding in > templates > > > I agree that oneline template inline function with > specializations to do this conversion would be a > good solution. The only problem I see is that it would need > to be specialized for so many cases. We > would want special rounding whenever a floating type is > converted to an integral type. We would have > a specialization for > > <all integral types, all float types> > > by which I mean <unsigned char, float>, ... <short, double>, > ... <long long, double> and everything > in between, about 20 odd specializations. Actually, I guess > we can forget about float, because if > the pixels are float, the righthandside will be converted > to double, so now were down to 10 or so. > Oops, but then there is long double, back up to 20. > > So many specializations does not seem like a clean solution to me. > > Fred Wheeler > > > Original Message > From: Ian Scott [mailto:ian.m.scott@...] > Sent: Friday, January 25, 2002 9:57 AM > To: Wheeler, Fred (CRD) > Cc: Vxlmaintainers (Email) > Subject: RE: [Vxlmaintainers] casting instead of rounding in > templates > > > I would have thought that template specialisations were more > appropriate. > They are certainly more efficient that having an if in the > middle of a loop. > > > > Original Message > > From: Wheeler, Fred (CRD) [mailto:wheeler@...] > > Sent: Thursday, January 24, 2002 9:50 PM > > To: vxlusers@...; > > vxlmaintainers@... > > Subject: [Vxlmaintainers] casting instead of rounding in templates > > > > > > > > (is vxlmaintainers a subset of vxlusers?) > > > > In file "vil_interpolate.txx", function "template <class T, > > class U> bool vil_interpolate_bilinear", > > the final line is: > > > > *out = U(pix00 * weight00 + pix10 * weight10 + pix01 * > > weight01 + pix11 * weight11); > > > > *out is of type T. This is a nice and general template, but > > if both T and U are integral types, then > > the right hand side above gets promoted to double because the > > weight* vars are type double. Then, > > the cast to type U gets to an integer by truncation. I think > > it would be much better to go to the > > nearest integer. This is causing problems for me and I'd > > like to fix it. I have not yet come up > > with a clean and easy way, so I'm looking for suggestions. > > My favorite attempt so far is below. > > Alas, it is really not sufficient. For one, I don't think > > vcl_numeric_limits works. For two, this > > breaks when instantiated with T as an rgb<unsigned char> (not > > quite the right name, but you know what > > I mean) type because both the if and else clauses must be > > compiled even if only one will be used for > > a certain type, and there is no >= for the rgb<unsigned > > char>. Any suggestions or pointers? > > > > T x = pix00 * weight00 + pix10 * weight10 + > > pix01 * weight01 + pix11 * weight11; > > > > // conversion done depending on the template types > > // when casting a floating type to an integral type, round > > to nearest int > > if (std::numeric_limits<U>::is_specialized && > > std::numeric_limits<T>::is_specialized && > > std::numeric_limits<U>::is_integer && > > ! std::numeric_limits<T>::is_integer ) { > > // add (subtract) 0.5 if greater (less) than 0 > > // so truncation will lead to the nearest integer > > *out = U( x + ( (x >= T(0.0)) ? T(0.5) : T(0.5) ) ); > > } else { > > *out = U(x); > > } > > > > Thanks, > > Fred Wheeler > > > > _______________________________________________ > > Vxlmaintainers mailing list > > Vxlmaintainers@... > > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > > > 
From: Blezek, Daniel J (CRD) <blezek@cr...>  20020125 15:17:00

One issue that might rear it's ugly head is that the Microsoft C++ compiler chokes on partial specializations, and is not likely to be fixed due to MS's emphasis on C#. dan > Original Message > From: Wheeler, Fred (CRD) > Sent: Friday, January 25, 2002 10:10 AM > To: 'ian.m.scott@...' > Cc: Vxlmaintainers (Email) > Subject: RE: [Vxlmaintainers] casting instead of rounding in > templates > > > I agree that oneline template inline function with > specializations to do this conversion would be a > good solution. The only problem I see is that it would need > to be specialized for so many cases. We > would want special rounding whenever a floating type is > converted to an integral type. We would have > a specialization for > > <all integral types, all float types> > > by which I mean <unsigned char, float>, ... <short, double>, > ... <long long, double> and everything > in between, about 20 odd specializations. Actually, I guess > we can forget about float, because if > the pixels are float, the righthandside will be converted > to double, so now were down to 10 or so. > Oops, but then there is long double, back up to 20. > > So many specializations does not seem like a clean solution to me. > > Fred Wheeler > > > Original Message > From: Ian Scott [mailto:ian.m.scott@...] > Sent: Friday, January 25, 2002 9:57 AM > To: Wheeler, Fred (CRD) > Cc: Vxlmaintainers (Email) > Subject: RE: [Vxlmaintainers] casting instead of rounding in > templates > > > I would have thought that template specialisations were more > appropriate. > They are certainly more efficient that having an if in the > middle of a loop. > > > > Original Message > > From: Wheeler, Fred (CRD) [mailto:wheeler@...] > > Sent: Thursday, January 24, 2002 9:50 PM > > To: vxlusers@...; > > vxlmaintainers@... > > Subject: [Vxlmaintainers] casting instead of rounding in templates > > > > > > > > (is vxlmaintainers a subset of vxlusers?) > > > > In file "vil_interpolate.txx", function "template <class T, > > class U> bool vil_interpolate_bilinear", > > the final line is: > > > > *out = U(pix00 * weight00 + pix10 * weight10 + pix01 * > > weight01 + pix11 * weight11); > > > > *out is of type T. This is a nice and general template, but > > if both T and U are integral types, then > > the right hand side above gets promoted to double because the > > weight* vars are type double. Then, > > the cast to type U gets to an integer by truncation. I think > > it would be much better to go to the > > nearest integer. This is causing problems for me and I'd > > like to fix it. I have not yet come up > > with a clean and easy way, so I'm looking for suggestions. > > My favorite attempt so far is below. > > Alas, it is really not sufficient. For one, I don't think > > vcl_numeric_limits works. For two, this > > breaks when instantiated with T as an rgb<unsigned char> (not > > quite the right name, but you know what > > I mean) type because both the if and else clauses must be > > compiled even if only one will be used for > > a certain type, and there is no >= for the rgb<unsigned > > char>. Any suggestions or pointers? > > > > T x = pix00 * weight00 + pix10 * weight10 + > > pix01 * weight01 + pix11 * weight11; > > > > // conversion done depending on the template types > > // when casting a floating type to an integral type, round > > to nearest int > > if (std::numeric_limits<U>::is_specialized && > > std::numeric_limits<T>::is_specialized && > > std::numeric_limits<U>::is_integer && > > ! std::numeric_limits<T>::is_integer ) { > > // add (subtract) 0.5 if greater (less) than 0 > > // so truncation will lead to the nearest integer > > *out = U( x + ( (x >= T(0.0)) ? T(0.5) : T(0.5) ) ); > > } else { > > *out = U(x); > > } > > > > Thanks, > > Fred Wheeler > > > > _______________________________________________ > > Vxlmaintainers mailing list > > Vxlmaintainers@... > > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > > > > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Wheeler, Fred (CRD) <wheeler@cr...>  20020125 15:10:51

I agree that oneline template inline function with specializations to do this conversion would be a good solution. The only problem I see is that it would need to be specialized for so many cases. We would want special rounding whenever a floating type is converted to an integral type. We would have a specialization for <all integral types, all float types> by which I mean <unsigned char, float>, ... <short, double>, ... <long long, double> and everything in between, about 20 odd specializations. Actually, I guess we can forget about float, because if the pixels are float, the righthandside will be converted to double, so now were down to 10 or so. Oops, but then there is long double, back up to 20. So many specializations does not seem like a clean solution to me. Fred Wheeler Original Message From: Ian Scott [mailto:ian.m.scott@...] Sent: Friday, January 25, 2002 9:57 AM To: Wheeler, Fred (CRD) Cc: Vxlmaintainers (Email) Subject: RE: [Vxlmaintainers] casting instead of rounding in templates I would have thought that template specialisations were more appropriate. They are certainly more efficient that having an if in the middle of a loop. > Original Message > From: Wheeler, Fred (CRD) [mailto:wheeler@...] > Sent: Thursday, January 24, 2002 9:50 PM > To: vxlusers@...; > vxlmaintainers@... > Subject: [Vxlmaintainers] casting instead of rounding in templates > > > > (is vxlmaintainers a subset of vxlusers?) > > In file "vil_interpolate.txx", function "template <class T, > class U> bool vil_interpolate_bilinear", > the final line is: > > *out = U(pix00 * weight00 + pix10 * weight10 + pix01 * > weight01 + pix11 * weight11); > > *out is of type T. This is a nice and general template, but > if both T and U are integral types, then > the right hand side above gets promoted to double because the > weight* vars are type double. Then, > the cast to type U gets to an integer by truncation. I think > it would be much better to go to the > nearest integer. This is causing problems for me and I'd > like to fix it. I have not yet come up > with a clean and easy way, so I'm looking for suggestions. > My favorite attempt so far is below. > Alas, it is really not sufficient. For one, I don't think > vcl_numeric_limits works. For two, this > breaks when instantiated with T as an rgb<unsigned char> (not > quite the right name, but you know what > I mean) type because both the if and else clauses must be > compiled even if only one will be used for > a certain type, and there is no >= for the rgb<unsigned > char>. Any suggestions or pointers? > > T x = pix00 * weight00 + pix10 * weight10 + > pix01 * weight01 + pix11 * weight11; > > // conversion done depending on the template types > // when casting a floating type to an integral type, round > to nearest int > if (std::numeric_limits<U>::is_specialized && > std::numeric_limits<T>::is_specialized && > std::numeric_limits<U>::is_integer && > ! std::numeric_limits<T>::is_integer ) { > // add (subtract) 0.5 if greater (less) than 0 > // so truncation will lead to the nearest integer > *out = U( x + ( (x >= T(0.0)) ? T(0.5) : T(0.5) ) ); > } else { > *out = U(x); > } > > Thanks, > Fred Wheeler > > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Ian Scott <ian.m.scott@st...>  20020125 14:55:22

I would have thought that template specialisations were more appropriate. They are certainly more efficient that having an if in the middle of a loop. > Original Message > From: Wheeler, Fred (CRD) [mailto:wheeler@...] > Sent: Thursday, January 24, 2002 9:50 PM > To: vxlusers@...; > vxlmaintainers@... > Subject: [Vxlmaintainers] casting instead of rounding in templates > > > > (is vxlmaintainers a subset of vxlusers?) > > In file "vil_interpolate.txx", function "template <class T, > class U> bool vil_interpolate_bilinear", > the final line is: > > *out = U(pix00 * weight00 + pix10 * weight10 + pix01 * > weight01 + pix11 * weight11); > > *out is of type T. This is a nice and general template, but > if both T and U are integral types, then > the right hand side above gets promoted to double because the > weight* vars are type double. Then, > the cast to type U gets to an integer by truncation. I think > it would be much better to go to the > nearest integer. This is causing problems for me and I'd > like to fix it. I have not yet come up > with a clean and easy way, so I'm looking for suggestions. > My favorite attempt so far is below. > Alas, it is really not sufficient. For one, I don't think > vcl_numeric_limits works. For two, this > breaks when instantiated with T as an rgb<unsigned char> (not > quite the right name, but you know what > I mean) type because both the if and else clauses must be > compiled even if only one will be used for > a certain type, and there is no >= for the rgb<unsigned > char>. Any suggestions or pointers? > > T x = pix00 * weight00 + pix10 * weight10 + > pix01 * weight01 + pix11 * weight11; > > // conversion done depending on the template types > // when casting a floating type to an integral type, round > to nearest int > if (std::numeric_limits<U>::is_specialized && > std::numeric_limits<T>::is_specialized && > std::numeric_limits<U>::is_integer && > ! std::numeric_limits<T>::is_integer ) { > // add (subtract) 0.5 if greater (less) than 0 > // so truncation will lead to the nearest integer > *out = U( x + ( (x >= T(0.0)) ? T(0.5) : T(0.5) ) ); > } else { > *out = U(x); > } > > Thanks, > Fred Wheeler > > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Ian Scott <ian.m.scott@st...>  20020125 11:36:26

> (is vxlmaintainers a subset of vxlusers?) > > No, they are two different lists. However, anyone who receives vxlmaintainers is very likely to also receive vxlusers. 