openvl-devel Mailing List for OpenVL (Open Volume Library)
Brought to you by:
sarang
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(1) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(10) |
Feb
(5) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(3) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Merlin C. <Dic...@ro...> - 2008-08-23 20:09:04
|
<html> <head> <meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <title>Try your luck online today!</title> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} @page Section1 {size:595.3pt 841.9pt; margin:2.0cm 42.5pt 2.0cm 3.0cm; mso-header-margin:35.4pt; mso-footer-margin:35.4pt; mso-paper-source:0;} div.Section1 {page:Section1;} --> </style> </head> <body lang=EN style='tab-interval:35.4pt'> <div class=Section1> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> Every New Player Receives up to 1800$ Free at ClubWorld!<o:p></o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> <o:p> </o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> +100 games and the greatest offers<o:p></o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> <o:p> </o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> Play the most exciting games with the high payouts online! <o:p></o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> <o:p> </o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> Best and Wide range of Choices<o:p></o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> <o:p> </o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> The best fun you will ever have!<o:p></o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> <o:p> </o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> <a href="http://www.seropl.com/"> http://www.semiss.com/</a><o:p></o:p></span></p> <p class=MsoNormal><span lang=EN-US style='mso-ansi-language:EN-US'> <o:p> </o:p></span></p> </div> </body> </html> |
From: %XTRAZ_VRACH L. M. <Lau...@an...> - 2008-01-22 17:09:52
|
Your woman lived you alone along of she had jazzed it with your friend. By reason of the length of his machine drove her mad with him. Increase your jang and you'll forget about this problems once and for all. Increase your male organ size and you will forget about problems sure enough. %XTRAZ_WWW%XTRAZ_DOMAINS |
From: Rupert O. <gus...@ag...> - 2007-07-26 14:50:08
|
From: Wayne C. <ron...@bb...> - 2007-07-25 14:22:17
|
From: Danial B. <dru...@ab...> - 2007-07-25 07:34:13
|
From: Xiaoliang,Li <le...@sj...> - 2005-03-26 09:13:49
|
Hello openvl-devel, Best regards, Xiaoliang,Li le...@sj... 2005-03-26 |
From: Sarang L. <sa...@us...> - 2004-11-04 05:18:03
|
I added min and max macros to vlmacros.h. Should we keep the name min and max or should we rename them to vlMin, vlMax? Sarang On Wednesday 03 November 2004 08:23 pm, Sarang Lakare wrote: > I will put them in some header file that can be used everywhere. I think we > already have vlmacros.h .. we can put it there. > > Sarang > > On Wednesday 03 November 2004 03:51 pm, Susan Frank wrote: > > Sarang, > > I didn't write the min and max functions. The only place I could find > > them was in /usr/include/pm.h. I'm not sure how my compiler grabbed them, > > but I'll add #define min(a,b) ((a) < (b) ? (a) : (b)) > > #define max(a,b) ((a) > (b) ? (a) : (b)) > > somewhere in openvl to make it more portable. Any suggestions as to the > > best place for it? > > Susan > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: > > Sybase ASE Linux Express Edition - download now for FREE > > LinuxWorld Reader's Choice Award Winner for best database on Linux. > > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > > _______________________________________________ > > openvl-devel mailing list > > ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openvl-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2004-11-04 01:23:54
|
I will put them in some header file that can be used everywhere. I think we already have vlmacros.h .. we can put it there. Sarang On Wednesday 03 November 2004 03:51 pm, Susan Frank wrote: > Sarang, > I didn't write the min and max functions. The only place I could find them > was in /usr/include/pm.h. I'm not sure how my compiler grabbed them, but > I'll add #define min(a,b) ((a) < (b) ? (a) : (b)) > #define max(a,b) ((a) > (b) ? (a) : (b)) > somewhere in openvl to make it more portable. Any suggestions as to the > best place for it? > Susan > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > openvl-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvl-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Susan F. <sf...@cs...> - 2004-11-03 20:43:54
|
Sarang, I didn't write the min and max functions. The only place I could find them was in /usr/include/pm.h. I'm not sure how my compiler grabbed them, but I'll add #define min(a,b) ((a) < (b) ? (a) : (b)) #define max(a,b) ((a) > (b) ? (a) : (b)) somewhere in openvl to make it more portable. Any suggestions as to the best place for it? Susan |
From: Sarang L. <sa...@us...> - 2004-10-16 03:28:54
|
This is for Susan: I am getting compilation errors due to missing min and max functions. I added min function in vlVolume (although not the right location!), but I found max function required in vox fileio filter... and its not there. Can you please check where you were getting the min and max functions? Maybe we can put them in some header? Sarang -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2004-10-16 03:27:22
|
Hi Susan, Let us first note down your requirements. From your email I see these 2 requirements: - You want to create a huge vlVolume that does not fit in the memory.. and you want to load only a part of it from a file (or a list of files). When you access this volume, the iterators will return the correct value when the iterator is in the portion of the volume that has been loaded. For the rest of the volume, the iterators would return 0 or null or something_else. - You have a large file on disk that contains a huge volumetric data that cannot fit in memory. You want to create a vlVolume of a smaller size and load only a part of the data that is stored in the file on disk. The vlVolume you created then does not correspond in dimension to the volume on disk. Let me know if I got your requirements correctly. We can discuss more then. I have fixed a few compilation errors in vlVolume... the function "min" was missing and some more errors. I will checkin the next time my laptop is on the internet. happy hacking! Sarang On Friday 20 August 2004 03:19 pm, Susan Frank wrote: > I have made several changes to vlVolume to accomodate huge volume data > sets. The current version has much redundancy that I plan to fix as > follows: > > For the cleanest implementation of Volume File I/O that supports > selectively reading partial volumes and combining volume files into a > single volume, I would like to do (before the next release of OpenVL): > > Read/ReadVolumes(filename,info,readFileInfo,readPos,readDim,format,useFileE >xt) Only filename is required. All other input items take on default values > when not supplied. > If info is not supplied readFile info is used. If readFileInfo is not > supplied, it is read from file(s). > For ReadVolumes filename contains a list of filenames. For > efficiency there is an option to provide a > filePath and List object instead. > > Read volume slabs (full x,y slices, up to full volume) starting at a > selected slice (z dimension). > > Prior to calling the fileio read plugin vlVolume::read should do > fseek(fp,info.headerSize+slicesize*startSlice, SEEK_SET) > NOTE: This require removing all fseek's from f3d, ppm, volvis-slc and vox > read plugins. > > Allow for translations between input data type and volume data type with > functions copyRGBtoRed > copyRGBtoRGBA and copyREDtoRGBA. These replace cropRGBtoRed, etc. because > input is cropped into m_pVolData. Use copyDataT for for cropping data of > the same type. By treating slice as a special case of slab we can remove > vlVolume::readImages. Use vlVolume::m_inputData (was m_pSliceData) for > input. The dimensions of the slab and the volume are obtained from > m_inputData and m_pVolData, respectivly. Only the volume section specified > is written. Slab volumes will be truncated if they attempt to write outside > the defined volume area. For efficiency input volumes of of the same > datatype and dimension as the volume object are read directly into > m_pVolData. > > Any comments? > > Susan > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > openvl-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvl-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Susan F. <sf...@cs...> - 2004-08-20 20:18:44
|
I have made several changes to vlVolume to accomodate huge volume data sets. The current version has much redundancy that I plan to fix as follows: For the cleanest implementation of Volume File I/O that supports selectively reading partial volumes and combining volume files into a single volume, I would like to do (before the next release of OpenVL): Read/ReadVolumes(filename,info,readFileInfo,readPos,readDim,format,useFileExt) Only filename is required. All other input items take on default values when not supplied. If info is not supplied readFile info is used. If readFileInfo is not supplied, it is read from file(s). For ReadVolumes filename contains a list of filenames. For efficiency there is an option to provide a filePath and List object instead. Read volume slabs (full x,y slices, up to full volume) starting at a selected slice (z dimension). Prior to calling the fileio read plugin vlVolume::read should do fseek(fp,info.headerSize+slicesize*startSlice, SEEK_SET) NOTE: This require removing all fseek's from f3d, ppm, volvis-slc and vox read plugins. Allow for translations between input data type and volume data type with functions copyRGBtoRed copyRGBtoRGBA and copyREDtoRGBA. These replace cropRGBtoRed, etc. because input is cropped into m_pVolData. Use copyDataT for for cropping data of the same type. By treating slice as a special case of slab we can remove vlVolume::readImages. Use vlVolume::m_inputData (was m_pSliceData) for input. The dimensions of the slab and the volume are obtained from m_inputData and m_pVolData, respectivly. Only the volume section specified is written. Slab volumes will be truncated if they attempt to write outside the defined volume area. For efficiency input volumes of of the same datatype and dimension as the volume object are read directly into m_pVolData. Any comments? Susan |
From: Susan F. <sf...@cs...> - 2004-08-19 16:08:07
|
Much of what I am using OpenVl for involves combining and splitting massive volumes up. Due to the large size of the data, it is very inefficient, and sometimes not possible, to read in parts I don't need. I have put subvolume and slice handling into vlvolume rather than create volume processing plugins because some object that are private to vlvolume were necessary. In particular, in vlvolume I have the following: READING PART OF A VOLUME: readImages reads slices. I have implemented it to allow for reading one datatype into another so that I don't need to create a separate volume when these don't match (see cropREDtoRGBA, cropRGBtoRGBA, cropRGBtoRed). This occurs in much of my work since I am adding the alpha channel to rgb data. It is also useful for grabbing only one channel for regiongrowing. I also can read only part of the slice. I am now changing this so that the fileio plugins automatically detect if only part of a file is desired based on info.origFilePos. So far. I have put this as slab only into vox (not checked yet). This may take a while since it affects code in many plugins, but when it's done the above crop___ routines will change to copy___ instead, which seems like cleaner code. I think that a separate SubVolume class and slice class, which would derive from vlvolume may be a good idea. This would include most of the code I put in vlvolume so far, and would return vlvolume to it's original level of purity. Any comments? |
From: Susan F. <sf...@cs...> - 2003-10-07 20:13:10
|
I have added the following to vlColorRGBA in vlcolor.h void SetluvAlpha() { a(vlColorRGB<T>(m_x, m_y, m_z).luvAlpha()); = }; AND to vlColorRGB in vlcolor.cpp: T vlColorRGB::luvAlpha()=20 It was added to the color class as indicated: >grep luvAlpha /usr/local/lib/openvl/plugins-0.3/vlalphaadd.so Binary file /usr/local/lib/openvl/plugins-0.3/vlalphaadd.so matches There seems to be a problem with the type of vlColorRGBA as indicated in = this=20 error message: Plugin registerd successfully!!! Status : OK :-) --- * --- * --- * --- Trying file : vlalphaadd.so Status : FAILED :-( /usr/local/lib/openvl/plugins-0.3/vlalphaadd.so Error message : /usr/local/lib/openvl/plugins-0.3/vlalphaadd.so: undefine= d=20 symbol: luvAlpha__t10vlColorRGB1ZUc --- * --- * --- * --- Using plugin directory : /usr/lib/openvl/plugins-0.3 Searching for plugin : VolDataLayout/Linear Service group node found!! Service node found!!. Number of plugins for the same service : 1 Searching for plugin : VolProcessor/AlphaAdd Service group node found!! No plugin found :( Vol Processor with name AlphaAdd not found. Any suggestions? Susan Frank |
From: Sarang L. <sa...@us...> - 2003-04-28 18:25:06
|
New RPMs have been uploaded for gcc3.2. These have -2sar in their name. These have been compiled on Mandrake 9.0 and are tested on both Mandrake 9.0 and Mandrake 9.1. The earlier RPMs were compiled on Mandrake 9.1 and did not install on Mandrake 9.0. The new RPMs should also work on gcc3.2 based RedHat releases and other Linux distributions. Send your experiences. Sarang -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2003-04-28 01:49:16
|
Hi guys, I released version 0.3.0 today. Try it out and report problems, bugs, etc. Release Notes: This release adds more plugins to OpenVL and tons of new features. There are two new programs "vlquery" and "vlconvert". vlconvert can be used to convert between different file formats. In future, vlconvert will have usage similar to "convert" of ImageMagic. This release is incompatible (both source and binary) with OpenVL 0.1.x. You will have to recompile your programs to work with this release. RPM Notes: -We are releasing two sets of RPMs: One set for those who have gcc2.96 based distro (RH7.3, Mdk8.x, etc.) and one set for those who have gcc3.2 based distro (Mdk9.x, RH8, RH9, etc.). -With this release, we are changing the package name to include a minor version number too. This allows multiple unstable releases to be installed simultaneously. -Due to change in package name, you will have to remove older OpenVL RPMs (at the least the -devel package) before installing this release. That is, you cannot upgrade using the -U switch. -You can build your own RPMs from the source rpm (SRPM) using rpm --rebuild openvl-0.3.0-1sar.src.rpm. ChangeLog: - Iterator API Changes: > Removed get/setRelative[NBC](int offset) > Renamed getVoxelOpPtr -> getVoxelOperator > Renamed getInterpolatorPtr -> getInterpolator - Added vlOffset class to define offset distance between two voxels - Added a neighborhood framework which allows easy access to a voxel's neighborhood - Added vlHistogram class for storing and computing histogram of a volume - Added framework for voxel operations via plugins - New Plugin:: Volume Processor : Crop - crops volume - New Plugin:: Volume Processor : GaussianApprox - smoothing using approximate gaussian - New Plugin:: Voxel Operator : CentralDiff - central difference at a voxel - New Plugin:: Volume Processor : CentralDiff - computes a CD gradient volume - BUG_FIX: Fixed the fscanf bug in raw and pgmvol fileio plugins - Win32/mingw support (not properly tested) - Added a new program "vlconvert" to convert between different file formats - Added a new program "vlquery" to query an OpenVL plugin for information Enjoy! Sarang -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2003-04-27 02:31:32
|
There is one important change when checking out and compiling code from cvs. After checking out the code, you need to run "autogen.sh" command. This command will generate the configure script that you need for creating makefiles. Earlier, the configure script was checked in to cvs, which caused many problems. This is also the approach used by most open source projects. I have updated the instructions on the webpage too. Sarang -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2003-04-21 18:31:57
|
On Friday 18 April 2003 08:06 pm, Pal Srinivas wrote: > Hello, > I want to build a application for volumetric display of MRI images. > Later mapping of fMRI ROI onto the volume. I am not sure, whether the > volumetric display capabilities are provided by openvl library routines are > not. Is this similar to the OpenInventor or VTK toolkit? OpenVL does not provide any display capabilities yet. It mainly provides low level functionality that makes implementing algorithms on volumetric data easy. So if you are planning to implement your own algorithms, then you are at the right place. You can look at the plugins directory to find the algorithms already implemented in OpenVL. There are not too many right now. Using these and your own algorithms, you can process your data. Once your processing is done, you can use VTK or other libraries to view your results. > Please help me. Also help me with, how can I get the required > documentation and useful related sites. Please feel free to ask any specific questions you have on this list. Sarang > > Thanks in advance. > Srinivas > > > > > > > _________________________________________________________________ > Help STOP SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > openvl-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvl-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Pal S. <pal...@ho...> - 2003-04-19 00:06:07
|
Hello, I want to build a application for volumetric display of MRI images. Later mapping of fMRI ROI onto the volume. I am not sure, whether the volumetric display capabilities are provided by openvl library routines are not. Is this similar to the OpenInventor or VTK toolkit? Please help me. Also help me with, how can I get the required documentation and useful related sites. Thanks in advance. Srinivas _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: Sarang L. <sa...@us...> - 2003-02-21 22:46:46
|
Hi guys, Here is what I am going to add to the iterator for accessing neighborhood. Any comments? /** * Set the neighborhood of the current voxel to access. A neighborhood * is defined by a list of offsets stored in the vlNeighborhood object. * * @see vlNeighborhood */ virtual bool setNeighborhood(const vlNeighborhood & neighborhood); /// Get the current neighbor of the current voxel. virtual DataType getNeighbor(); /// Get the id of the neighbor in the neighborhood virtual uint16 getNeighborId(); /// Move to the neighbor pointer to the next neighbor in the /// neighborhood list virtual bool nextNeighbor(); /// Move to the neighbor pointer to the previous neighbor in the /// neighborhood list virtual bool prevNeighbor(); /// Move to the neighbor pointer to the first neighbor in the /// neighborhood list virtual bool firstNeighbor(); /// Move to the neighbor pointer to the last neighbor in the /// neighborhood list virtual bool lastNeighbor(); /// Set the current neighbor of the current voxel. virtual bool setNeighbor(const DataType & value) = 0; -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: susan f. <sf...@cs...> - 2003-02-19 21:28:29
|
I like the first one better. i don't think there should be too much confusion with next and nextNeighbor, and efficient is (almost) always better for my applications. Susan Frank |
From: Sarang L. <sa...@us...> - 2003-02-18 23:52:12
|
Hi guys, I was trying to make accessing neighborhood of a voxel really simple. This is needed when for example you want to access all neighboring voxels in a row.. to compute say the average or the median. I have come up with two ways to do this.. your comments/votes are needed. I am showing how I would compute median filter using the new neighborhood access method: 1> This is the first method. It basically extends the vlVolIter API to allow accessing neighborhood. There will be three new methods (and possibly more) to access the neighborhood. The first step in accessing a neighborhood will be setting up the type of neighborhood you want to access (assumming "iter" is an iterator over a volume you are working with): iter.setNeighborhood(neighborhood); where, "neighborhood" will be an object of a class that stores offsets to all the neighbors w.r.t the central voxel (this is also not implemented yet.. but will be something like vlNeighborhood). Then, to access the voxel in the neighborhood: iter.getNeighbor() This will return the first neighboring voxels as defined in "neighborhood". So for example if (-1,-1,-1) was the first voxel, then that will be returned. Then, to move to the next neighbor: iter.nextNeighbor() This will move the internal neighbor pointer to the next neighbor as listed in "neighborhood". The next call to getNeighbor() will return the value at this new neighbor. This call will also return false when there are no more neighbors to traverse. This is how median filter would look: MedianFilter(vlVolume *inputVol, vlVolume *outputVol) { vlVolIter iter(inputVol); vlVolIter oiter(outputVol); // initialize some neighborhood .. lets say of radius 2 vlNeighborhood neighborhood(2); iter.setNeighborhood(neighborhood); std::vector<DataType> voxels; while(!iter.end()) { voxels.clear(); while(iter.nextNeighbor()) { voxels.push_back(iter.getNeighbor()); } // find the median of the vector "voxels". std::vector<DataType>::iterator medianIter = voxels.begin() + (iter.neighborhoodSize()/2); std::nth_element(voxels.begin(), medianIter, voxels.end()); oiter.set(*medianIter); iter.next(); } } 2> This is the second method that can be implemented. The idea here is not to extend the existing iterator API but to have a new iterator API for the neighborhood. So basically you create a new iterator" vlConstNeighborIter<DataType> niter(neighborhood, iter); where "iter" is an iterator on the volume on which you are working, then initialize it over the neighborhood just like you initialize an iterator over a volume. Then you can use this neighborhood iterator to access the voxels in the neighborhood: iter.get() iter.next() - move to next voxel. and so on. This is how median filter would be implemented: MedianFilter(vlVolume *inputVol, vlVolume *outputVol) { vlVolIter iter(inputVol); vlVolIter oiter(outputVol); // initialize some neighborhood .. lets say of radius 2 vlNeighborhood neighborhood(2); std::vector<DataType> voxels; while(!iter.end()) { // create a new neighborhood iterator vlConstNeighborIter<DataType> niter(neighborhood, iter); voxels.clear(); while(niter.next()) { voxels.push_back(niter.get()); } // find the median of the vector "voxels". std::vector<DataType>::iterator medianIter = voxels.begin() + (iter.neighborhoodSize()/2); std::nth_element(voxels.begin(), medianIter, voxels.end()); oiter.set(*medianIter); iter.next(); } } We need to decide which of the two methods is the right way to do this. I am kind of inclined towards the first method because: From user's point of view: + No need to initialize another iterator. + No need to remember one more iterator API. From implementation point of view: + No need to write another iterator API + Neighborhood access will be faster: in method 1, we are extending the basic iterator API.. which means every layout can implement the getNeighbor() function in the fastest possible way! while in method 2, get() will basically call getRelative(offset) of the "iter" that you pass to it which can be slow. Unless we allow every layout to reimplment this new iterator API for its own layout which can complicate things. There are ofcourse some disadvantages of method 1: - the iterator becomes more bloated due to more functions - users might get confused between next() and nextNeighbor() etc. Please give me feedback. All suggestions are welcome. Sarang -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2003-02-13 22:20:41
|
On Sunday 26 January 2003 02:10 am, Kyle Hegeman wrote: > Attached is one for mingw only. The patch is in :) with some little modifications. Thanks again. Sarang -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2003-02-09 00:03:02
|
Hi guys, I have updated the first page of OpenVL a little bit. I have also added two new links under "Develop" for reporting bugs and requesting new features. Please use these links in future so that we can keep track of bugs and feature-requests. Sarang PS : Kyle, I'll apply your remaining patches soon.. I have been too busy with other things lately. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |
From: Sarang L. <sa...@us...> - 2003-01-31 02:29:23
|
Hi guys, I have uploaded the presentation that I gave on OpenVL last friday. It is available here: http://openvl.sourceforge.net/doc/presentations.php Sarang -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarang Lakare mailto:sarang@users#sourceforge.net web:http://www.cs.sunysb.edu/~lsarang/linux !!Join the fight for freedom - Go GNU/Linux!! |