No reported problems.
The last valgrind memory check on the vxl dashboard, revealed no leaks, =
or pointer problems in vil.
I have used _CrtDumpMemoryLeaks() in the past (though probably not =
specifically with anything in vil.) It not a particularly helpful tool, =
and programs like Purify, Insure and valgrind are all much superior.
> -----Original Message-----
> From: Sebastian Schuberth [mailto:s.schuberth@...]
> Sent: Tuesday, June 15, 2004 6:40 PM
> To: Ian Scott
> Cc: Vxl-Users (E-mail)
> Subject: Re: [Vxl-users] Using vil under VS .NET 2003
> Thanks for your detailed answer, I finally had the time to=20
> install the=20
> old CMake 1.8.3 and rebuild all the libs ... and it seems to=20
> work now.=20
> Nevertheless, I now have a strange other issue: I'm using=20
> _CrtDumpMemoryLeaks() for simple memory leak detection, see:
> As soon as I use a vil_image_resource_sptr, this function call never=20
> returns. Has anyone else experienced this?
> Ian Scott schrieb:
> >>From: Sebastian Schuberth
> >>I'm trying to use vil only (using all its supported images=20
> >>formats incl.=20
> >>those using external libraries, esp. DCMTK). I find the
> >>directory structure very strange
> >>and the build system very complicated,=20
> > All possible directory structures are likely to be strange=20
> to some people. If you have a suggestion on how to explain it=20
> better in the documentation, we'd be interested.
> > As for the build system --- it is nowhere near as=20
> complicated as it used to be. Getting a single code base, and=20
> single build system working on multiple platforms, while=20
> coping with the machine level technicalities such as=20
> different double float formats, different endianness, and=20
> most importantly different levels of support for the C++ and=20
> POSIX standards, is fundamentally difficult. Until we used=20
> CMake, the build system was more complicated, and broke a lot.
> >>still I=20
> >>managed to get my code compiled and linked without errors, but=20
> >>"vil_load_image_resource" always returns NULL.=20
> > That should work. I guess you've checked the obvious=20
> things, like you actually have a valid image?
> >>Here's what I did:
> >>- Downloaded and installed VXL 126.96.36.199 as well as CMake.
> >>- Trimmed down the CMake configuration because I'm only=20
> >>interessted in=20
> >>vil: http://www-public.tu-bs.de:8080/~y0011326/cmake.png
> > That's good - it is exactly how we intended it to be used.
> >>- Opened $VXLBIN/vxl.sln, added the following global includes:
> >>(These seem to be necessary although not mentioned at
> >>else "vxl_config.h" cannot be found, maybe the docs need an update?)
> >>(as mentioned in the docs, not that I don't really have the above=20
> >>environment variables defined, they are just placeholders for=20
> >>my paths)
> > You shouldn't need to add anything to get VXL to build.=20
> CMake 1.8.3 definitely adds those paths to the search path=20
> for MSVC 6 project files. Unfortunately our MSVC.NET testing=20
> machines have had hardware problems for a while, so I don't=20
> know the current state of those machines, but we have had=20
> reports of people building VXL 188.8.131.52 successfully. I don't=20
> know about CMake 2.0 It was only just released very=20
> recently, and we haven't tested it that much. You could try=20
> using CMake.1.8.3 instead.
> > It is of-course necessary to add those directories to your=20
> own project.
> >>- Successfully created the dcmtk, jpeg, png, tiff, vcl, vil and z=20
> >>libraries (manually compiled each of these from the IDE).
> >>- Added the libs to my project and the following source:
> >>#include <vil/vil_load.h>
> >>// ...
> >>cout << data->ni() << "x" << data->nj() << endl;
> >>Unfortunately, data is always NULL, no matter which file format I'm=20
> >>trying to open (I tried BMP, PNG and DCM). The cause is that
> >>(vil_load.cxx, line 64)
> >>fails. But why?
> > You almost certainly do not have any plugins installed, so=20
> this should return false. (The plugins are not the standard=20
> image file formats, but things like the video library, so=20
> that you can load a frame by saying=20
> vil_load("my_movie.avi:30").) The function you are currently=20
> in should then return NULL and go bak to=20
> vil_load_image_resource(), which should then call (line 57)
> > im=3Dvil_load_image_resource_raw(filename);
> > which in turn will call=20
> > im=3Dvil_load_image_resource_raw(vil_stream *is)
> > which will then try and load the image, using all the=20
> vil_file_formats it knows about.
> > It is possible (given your earlier problems with the build=20
> system) that vil has failed to notice the DCM and PNG=20
> libraries, but the BMP loader is entirely self contained with=20
> vil, so that should always work.
> > Suggestions:
> > 1. Does your program print any diagnostic to the console?
> > 2. Try enabling the debugging output at lines 21-23.
> > 3. Try following loading a .pnm file (.pbm, .pgm or .ppm)=20
> as these are very simple and handled entirely with vil.
> > 4. Turn the testing on, and building and running the=20
> vil_tests. (Turn BUILD_TESTING and BUILD_CORE_UTILITIES on in=20
> > 5. Use CMake 1.8.3
> > Ian.
> Sebastian Schuberth
> Institute of ComputerGraphics
> Technical University at Brunswick
> Phone: +49 531 391-2113, Fax: -2103