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
(1) 
3

4
(14) 
5
(3) 
6
(2) 
7

8
(2) 
9
(10) 
10
(4) 
11
(2) 
12
(1) 
13
(10) 
14

15

16
(6) 
17
(1) 
18
(3) 
19
(6) 
20
(9) 
21
(1) 
22
(1) 
23
(3) 
24
(2) 
25
(3) 
26
(6) 
27
(3) 
28

29

30
(2) 





From: Wheeler, Fred (Research) <wheeler@cr...>  20020906 12:10:50

Ian, > OPTION (VXL_FORCE_V3P_JPEG "Use V3P in preference to any native JPEG > library?" YES) > MARK_AS_ADVANCED (VXL_FORCE_V3P_JPEG) Do you think the default should be YES here? I think it should be, but it would be a change in behavior to default to using v3p. Fred Wheeler 
From: Wheeler, Fred (Research) <wheeler@cr...>  20020906 12:06:20

I would like to make a few changes in v3p/CMakeLists.cmake and some FindXXX.cmake files. These are lowrisk changes to clean up what I started yesterday, so I'm going to make them now. I was planning on migrating the tree to use FindMPEG2.cmake (which uses v3p if needed) instead of FindMPEG.cmake (which should be removed later). Right now, both are used. I think this can wait until after beta2. The v3p/mpeg2 library seems to be mostly working now. I've run gel/jvid/bin/jplayer in win32, Cygwin (glut too featureless to be usable, but it links and opens a window) and Solaris (static and dynamic, both with gtk). I was quite surprised to see so much green on the dashboard this morning. I thought there would be many more problems. We're seeing a color offset with the one mpeg test file we've viewed here. Not sure if its an mpeg2 lib or vidl lib issue. Lu Galup will probably get that straightened out soon. Fred Wheeler > Original Message > From: Amitha Perera [mailto:perera@...] > Sent: Thursday, September 05, 2002 5:47 PM > To: vxlmaintainers@... > Subject: [Vxlmaintainers] Beta2 release > > > Since it looks like the dashboard will be well tomorrow, I suggest > that we lock down the repository in preparation for a beta2 release > this weekend. > > So: until further notice, please do not commit anything except to fix > bugs that the dashboard exhibits. > > Any complaints? > > Amitha. > > >  > This sf.net email is sponsored by: OSDN  Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Amitha Perera <perera@cs...>  20020905 21:47:16

Since it looks like the dashboard will be well tomorrow, I suggest that we lock down the repository in preparation for a beta2 release this weekend. So: until further notice, please do not commit anything except to fix bugs that the dashboard exhibits. Any complaints? Amitha. 
From: Peter Vanroose <Peter.Vanroose@es...>  20020905 15:24:50

> With sparc/gcc it seems that "long double" is the quad IEEE type and takes > 16 bytes. Also on SGI. Stange enough, on the 64bit Alpha platform, "long double" is 8 bytes, just like "double" ! There is some "Inf" and "NaN" magick in vnl/vnl_math.cxx, which is really needed there, at least it was in the times of gcc 2.95. So it seems that "IEEE float" is not as standard as it should be, at least not in the current compilers' (or platforms' floating point unit's) implementation... Peter. P.S. Do you have simple a C program to extract the number of E and F bits? Could be useful in configure... 
From: Frederik Schaffalitzky <fsm@ro...>  20020905 13:28:39

On Wed, 4 Sep 2002 Peter.Vanroose@... wrote: > Do you have a pointer to the documentation for this? No, only what I could find on the http://www. Correcting for endianness, the layout is always SEE...EEFF.....FF where S is the sign bit, E the exponent bits and F the mantissa ("fraction") bits. > Is the internal representation (and the division between mantissa and > exp) fixed once the total length of the representation is known? If > not, this has to be tested for in configure. Don't think so but these are the cases I have seen: single 1 + 8 + 23 = 32 double 1 + 11 + 52 = 64 doubleextended 1 + 15 + 64 = 80 quad 1 + 15 + 112 = 128 But I am no expert and I have not read the wonderful IEEE754 document. So far as I can see, the x86 80bit floating format ("long double" on my linux box) seems to not really be IEEE in that the leading "1" in the fraction part is included in the mantissa whereas in IEEE it is implied. Also, the "sizeof" size of my "long double" seems to be 12 bytes, with 16 bits of zeropadding on the left. With sparc/gcc it seems that "long double" is the quad IEEE type and takes 16 bytes. 
From: <Peter.Vanroose@es...>  20020904 17:11:21

> ... It's with instantiating complex<bignum>. In > particular, with instantiating abs( complex<bignum> ). This symptom is fixed now, since vnl_bignum now has a constructor that takes "long double". But the more general question (of needing sqrt(T) in vnl, and of complex<T>, for nonbuiltin types T) remains of course open. Peter. 
From: Amitha Perera <perera@cs...>  20020904 16:37:18

Fred asked a pertinent question which shows I don't really know what I'm talking about: :) Frederik Schaffalitzky wrote: > Sorry, I don't understand what you mean by "long double constants"... > Exactly how does the implementation of the VCx.y sqrt(double) cause long > doubles to be passed to the constructor of vnl_bignum? Investigating further, the problem is not with the sqrt or abs overrides per se. It's with instantiating complex<bignum>. In particular, with instantiating abs( complex<bignum> ). VC70 implements abs(complex<Ty>) with a complicated, and presumably efficient and accurate, routine. In one branch of the routine, there is a statement (Ty)0.423423....545345L which asks for a conversion from a long double to Ty. (It's a high precision representation of sqrt(2), FWIW.) This fails for vnl_bignum, and also fails for vnl_rational when we try to explicitly instantiate abs(complex<rational>). There is no problem with VC60, because there is a "fix" in vcl/win32/vcl_complex.h that defines T abs( complex<T> z ) { return sqrt( norm(z) ); } Now, this "fix" shouldn't be in place for VC70 because the library *does* provide abs(complex<T>). It may not be implemented as we like, but then, the implementation details are not ours to dictate. I think in general, there is trouble when trying to create a userdefined type that acts like a standard numeric type. As Fred mentioned earlier, it is undefined to overload std::sqrt because that is adding to namespace std. Perhaps the solution is to go back to vnl_sqrt for vnl stuff. Has there been previous discussion about this issue? Amitha. 
From: Ian Scott <ian.m.scott@st...>  20020904 15:46:55

Fred wrote: > The IEEE format allows for any length of mantissa and > exponent but only a > few combinations are common. I can't remember if the vsl > people eventually > decided to implement I/O of arbitrary length integers but one could do > something like that for IEEE floating point values. If someone knows how to consistently convert a long double to and from a triple of integers [Sign, Mantissa, and Exponent] values, I can use that to provide vsl support. I think that would be a better approach than Amitha's suggestion of converting it to a rational. Rational descriptions will not cope with the full range of exceptional values defined by IEEE, i.e. NaNs and Infs. Ian. 
From: <Peter.Vanroose@es...>  20020904 15:30:04

> Yes. Moreover, vnl_bignum is an *integral* type. sqrt is not > "welldefined" anyway. Which also argues that complex<vnl_bignum> > shouldn't exist. Well, vnl_rational has similar problems. And is not integral, so sqrt(vnl_rational) and complex<vnl_rational> make more sense than for vnl_bignum. Peter. 
From: <Peter.Vanroose@es...>  20020904 15:26:33

> The definition of vcl_sqrt or std::sqrt in vnl_bignum.h is illformed, as > Bill's client pointed out recently in connection with std::complex and > STLPORT. We are not allowed to add more sqrt() signatures to std:: The simplest solution would then be to remove vcl_sqrt(vnl_bignum). BUT... that breaks e.g. vnl_vector<vnl_bignum> since e.g. normalise() uses vcl_sqrt. One solution could be to systematically use vnl_math_sqrt in vnl_vector and vnl_matrix (and overload it in vnl_bignum), but that looks like overkill to me. Better solutions? Peter. 
From: Amitha Perera <perera@cs...>  20020904 15:25:31

Frederik Schaffalitzky wrote: > The definition of vcl_sqrt or std::sqrt in vnl_bignum.h is illformed, as > Bill's client pointed out recently in connection with std::complex and > STLPORT. We are not allowed to add more sqrt() signatures to std:: Yes. Moreover, vnl_bignum is an *integral* type. sqrt is not "welldefined" anyway. Which also argues that complex<vnl_bignum> shouldn't exist. > So vcl_sqrt() for vnl_bignum must be removed or renamed. Does that solve > the problem? Probably. That'll force removal of complex<bignum> from the explicit instantiations. However, with the implicit instantiation of vcl code, people could probably continue to use it if they wish. > I didn't understand what the problem with sqrt() for VCx.y > was. If you are saying that vcl_sqrt(double) returns a long double then > that vcl_sqrt() is wrong: it could and should be fixed in vcl. VCx.y sqrt is broken in general, but that's not the real issue. The problem was that the their implementation of sqrt has long double constants. When those constants interact with vnl_bignums, they cause overloading ambiguities. > long double is unlikely to unavailable on any compiler that we support. > Of course, on some architectures it is 128 bits wide (Sparc) and on some > it is 96 bits (80x86), which is a problem if we expect "long double" to be > binary exchangeable across architectures.... Let's not have that > discussion again. Binary exchange is one issue. Having support for long double is another. It is (should be) perfectly reasonable for vnl to support long double types on any given and fixed platform, regardless of what the size of the underlying type is. There are very few places where is it necessary that the size of the underlying type be known. > The IEEE format allows for any length of mantissa and exponent but only a > few combinations are common. Yes. And I don't think the C++ standard mandates the use of IEEE arithmetic, although that assumption seems to be widespread in vnl. > I can't remember if the vsl people eventually decided to implement > I/O of arbitrary length integers but one could do something like > that for IEEE floating point values. This is the solution for any floating point type: represent as a rational. It will be correct as long as both platforms have types that can represent the number in question. But then, you can't ask for more. Amitha. 
From: <Peter.Vanroose@es...>  20020904 15:19:37

> The IEEE format allows for any length of mantissa and exponent but only a > few combinations are common. I can't remember if the vsl people eventually > decided to implement I/O of arbitrary length integers but one could do > something like that for IEEE floating point values. Do you have a pointer to the documentation for this? Is the internal representation (and the division between mantissa and exp) fixed once the total length of the representation is known? If not, this has to be tested for in configure. Peter. 
From: Frederik Schaffalitzky <fsm@ro...>  20020904 15:05:49

The definition of vcl_sqrt or std::sqrt in vnl_bignum.h is illformed, as Bill's client pointed out recently in connection with std::complex and STLPORT. We are not allowed to add more sqrt() signatures to std:: So vcl_sqrt() for vnl_bignum must be removed or renamed. Does that solve the problem? I didn't understand what the problem with sqrt() for VCx.y was. If you are saying that vcl_sqrt(double) returns a long double then that vcl_sqrt() is wrong: it could and should be fixed in vcl. long double is unlikely to unavailable on any compiler that we support. Of course, on some architectures it is 128 bits wide (Sparc) and on some it is 96 bits (80x86), which is a problem if we expect "long double" to be binary exchangeable across architectures.... Let's not have that discussion again. The IEEE format allows for any length of mantissa and exponent but only a few combinations are common. I can't remember if the vsl people eventually decided to implement I/O of arbitrary length integers but one could do something like that for IEEE floating point values. Frederik On Wed, 4 Sep 2002, Amitha Perera wrote: > In trying to clean up vcl code for VC70, we've come across problems > relating to the long double type. In particular, the VC70 standard > library seems notsobroken that it only requires a few patches in > vcl/win32/* (actually, VC60sp5 seems to be similar...). The problem is > that the VC70 implementation of some of the math functions uses long > double constants (e.g. in the sqrt function). This creates problems > when trying to instantiate vnl_bignum because there is no constructor > taking a long double as an argument. While there is, no doubt, a > reasonable work around for this particular problem, it is indicative > of a bigger problem: inconsistent and incomplete support for long > double in vnl. > > The C++ standard explicitly has a long double type. On some platforms, > it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is > there a clean way of getting long double support into > vnl_math.{h,cxx}? From there, it should be relatively straight forward > to propagate to the rest of vnl. > > I must admit lack of experience with this level of detail in floating > point representations, etc. Can any vnl gurus comment? > > On a side note: the comment in vnl_math says that vnl_math::maxdouble > (and relatives) are only there until there is support for numeric > traits. It would seem that we now have widespread support for numeric > traits, in terms of complete specialization. Should > vnl_math::maxdouble be moved into traits? > > Amitha. > > >  > This sf.net email is sponsored by: OSDN  Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Ian Scott <ian.m.scott@st...>  20020904 13:18:57

The last time I looked (a few moths ago) the two libraries in the tbl module vipl and vepl were looking pretty good except for one thing  they leak a lot of memory. Peter did some work to tidy up the code so that the memory leak problems might be easier to fix, however noone has actually tackled the leaks themselves. In my opinion the code would (apart from the leaks) be suitable for promotion to full VXL status  the documentation is adequate, they are easy to use and extend, and appear to do the job pretty well. Ian. Original Message From: Joseph Mundy [mailto:mundy@...] Sent: Wednesday, September 04, 2002 2:11 PM To: 'Vxl' Subject: [Vxlmaintainers] Image Processing Dear VXLers, What is the current status of vxl image processing? Joe 
From: Peter Vanroose <Peter.Vanroose@es...>  20020904 13:14:40

> What is the current status of vxl image processing? See tbl/vipl, tbl/vepl, and (for convolutions and simple operations) vxl/vil. Peter. 
From: Joseph Mundy <mundy@le...>  20020904 13:10:50

Dear VXLers, What is the current status of vxl image processing? Joe 
From: Ian Scott <ian.m.scott@st...>  20020904 08:56:58

vsl currently provides no support for long doubles. In particular we would need to design a unique encoding for long double, and write code to get data into that format from each platform's native long double. We couldn't find any straightforward solution to this during the design of vsl, but if anyone has some suggested code, then it would be fairly easy to try after the upcoming release tagging. I'd be happy to help. Ian. > Original Message > From: Amitha Perera [mailto:perera@...] > Sent: Wednesday, September 04, 2002 6:17 AM > To: vxlmaintainers@... > Subject: [Vxlmaintainers] Numerics and long double > > > In trying to clean up vcl code for VC70, we've come across problems > relating to the long double type. In particular, the VC70 standard > library seems notsobroken that it only requires a few patches in > vcl/win32/* (actually, VC60sp5 seems to be similar...). The problem is > that the VC70 implementation of some of the math functions uses long > double constants (e.g. in the sqrt function). This creates problems > when trying to instantiate vnl_bignum because there is no constructor > taking a long double as an argument. While there is, no doubt, a > reasonable work around for this particular problem, it is indicative > of a bigger problem: inconsistent and incomplete support for long > double in vnl. > > The C++ standard explicitly has a long double type. On some platforms, > it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is > there a clean way of getting long double support into > vnl_math.{h,cxx}? From there, it should be relatively straight forward > to propagate to the rest of vnl. > > I must admit lack of experience with this level of detail in floating > point representations, etc. Can any vnl gurus comment? > > On a side note: the comment in vnl_math says that vnl_math::maxdouble > (and relatives) are only there until there is support for numeric > traits. It would seem that we now have widespread support for numeric > traits, in terms of complete specialization. Should > vnl_math::maxdouble be moved into traits? > > Amitha. > > >  > This sf.net email is sponsored by: OSDN  Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Peter Vanroose <Peter.Vanroose@es...>  20020904 06:33:23

> The C++ standard explicitly has a long double type. On some platforms, > it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is > there a clean way of getting long double support into vnl_math.{h,cxx}? I don't expect much trouble when one just adds a "long double" version anywhere where there are float and double versions of a function. E.g., adding "long double" versions in vnl_bignum was straightforward. (Well, I only tried gcc and SGI's CC.) Shall we just try and do this in vnl_math ? The "maxdouble" issue is more tricky, I guess, since that would require extra configure efforts. But why not... Peter. 
From: Amitha Perera <perera@cs...>  20020904 05:14:51

In trying to clean up vcl code for VC70, we've come across problems relating to the long double type. In particular, the VC70 standard library seems notsobroken that it only requires a few patches in vcl/win32/* (actually, VC60sp5 seems to be similar...). The problem is that the VC70 implementation of some of the math functions uses long double constants (e.g. in the sqrt function). This creates problems when trying to instantiate vnl_bignum because there is no constructor taking a long double as an argument. While there is, no doubt, a reasonable work around for this particular problem, it is indicative of a bigger problem: inconsistent and incomplete support for long double in vnl. The C++ standard explicitly has a long double type. On some platforms, it is bigger than double. (On FreeBSD with gcc, it is 96 bits.) Is there a clean way of getting long double support into vnl_math.{h,cxx}? From there, it should be relatively straight forward to propagate to the rest of vnl. I must admit lack of experience with this level of detail in floating point representations, etc. Can any vnl gurus comment? On a side note: the comment in vnl_math says that vnl_math::maxdouble (and relatives) are only there until there is support for numeric traits. It would seem that we now have widespread support for numeric traits, in terms of complete specialization. Should vnl_math::maxdouble be moved into traits? Amitha. 
From: Ian Scott <ian.m.scott@st...>  20020902 18:37:44

I've been reviewing our FindXXX.cmake files, in order to move most of the functinoality out of vxl and into cmake. I wanted to ask everyones opinion on the following point. Most of our own FindXXX.cmake files, add "HAS_XXX" to the list of definitions. This has to be modified to fit into the format that has been agreed by CMake. A straght translation would mean that FindXXX.cmake declares a variable XXX_DEFINITIONS which would include HAS_XXX. Anyone who wants to compile code that uses XXX, would add the following line to the relevent CMakeLists.txt file ADD_DEFINITIONS( ${XXX_DEFINITIONS} ) My question is then, "Is there any point in having FindXXX.cmake set HAS_XXX anywhere?" The CMakeLists.txt file that would have to include the above line, could just include ADD_DEFINITIONS( ${XXX_DEFINITIONS} DHAS_XXX) The advantage to us for going for the option decibed by the latter example line, is that we need less of our own FindXXX.cmake logic, instead leaving it to be maintained by the CMake people. Unless anyone strongly objects, I will put the mods in the repository over the next few days, before the repository lockdown starts. Ian. 