RETRO toolbox : 5-July-96


kroutines libraries

lrfclass



Short Description:
possible divide by zero (fix provided in report)
Work-Around :
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 4 - Low
Reported By : yishay@wisdom.weizmann.ac.il
Date : 08-Jan-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
In both LRFtrain and LRFclass routines, when calculating the distance from the receptive fields centers, the square distance is divided by the variance value, without checking that this value is not zero.

dis += q/cc_var[j][k] ; (cc_var[j][k] may be zero).
Notes :
bug also listed in lrftrain.todo
Keywords :
TB::oname : RETRO::lrfclass


Short Description:
R[][] is always 0 because the sum of 75 differences was too big. Solve this by dividing the distance by the number of features (fix provided)
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By : yishay@wisdom.weizmann.ac.il
Date : 08-Jan-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
1. calculating distance from centers (LRFtrain, LRFclass) . I have many features (75) , and so I got always R[][] = 0, because exp(-distance) = 0 , because the distance was too big - sum of 75 differences. I solved it by dividing the distance by the number of features :

dis = dis / input_dim ;
Notes :
bug also listed in lrftrain.todo
Keywords :
TB::oname : RETRO::lrfclass

lrftrain



Short Description:
Need documentation explaining how to create the input center/class image by appending the supervised classification to the cluster center image
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 4 - Low
Reported By : Gerd Diesner
Date : 12-Jan-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I have a problem with the function lrftrain. I had connected the inputs of the lrftrain glyph with the outputs of the vkmeans glyph.

+--------+ | | | |------------------ |vconvert| \ \ +-------+| \ \ | \ | +-------+ \ +--------+ \ | | \ | | ---| |-- -----| | | |--\----------| | -| |---\------- -| | | |-- ---------| | -| | | | | |vkmeans| | |lrftrain| +-------+ | +--------+ | | | ascii file viewer

Ball.xv was the input image. After the process convert from byte type to float type the next process was vkmeans. When the process lrftrain started I became a bad smiley on the lrftrain glyph. The error message was: lrfclass: the center/class image does not contain the correct number of data bands. Should have 2 bands, but contains 1 bands. Please ensure that the classified (ie. supervised) image has been appended to the cluster center image.

... and from another message ...

>" Prior to using the LRF algoithm, it is necessary to run > vkmeans on the training image to fix the cluster centers, > followed by a supervised ... Note that the image resulting > from the supervised classification MUST be appended to the > cluster center image before running the LRF." > ... > Also, how do you append the supervised > classification image to the cluster center? >

Hi, I had previously posted a similar request (chronologically later then this one) and I have not seen a response. Did I miss a post somewhere? Could someone please explain to me what "append" means in this context?

The two images are of completly different sizes and different number of bands.

The cluster _center_ image has a x = number of centers y = 1 bands = size of vectors.

while the supervised image has dimensions equal to the cluster _number_ image (x,y) and 1 band.

How can I join them? Am I missing something?
Notes :
Keywords :
TB::oname : RETRO::lrftrain


Short Description:
possible divide by zero (fix provided in report)
Work-Around :
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 4 - Low
Reported By : yishay@wisdom.weizmann.ac.il
Date : 08-Jan-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
In both LRFtrain and LRFclass routines, when calculating the distance from the receptive fields centers, the square distance is divided by the variance value, without checking that this value is not zero.

dis += q/cc_var[j][k] ; (cc_var[j][k] may be zero).
Notes :
bug also listed in lrfclass.todo
Keywords :
TB::oname : RETRO::lrftrain


Short Description:
R[][] is always 0 because the sum of 75 differences was too big. Solve this by dividing the distance by the number of features (fix provided)
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By : yishay@wisdom.weizmann.ac.il
Date : 08-Jan-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
1. calculating distance from centers (LRFtrain, LRFclass) . I have many features (75) , and so I got always R[][] = 0, because exp(-distance) = 0 , because the distance was too big - sum of 75 differences. I solved it by dividing the distance by the number of features :

dis = dis / input_dim ;
Notes :
bug also listed in lrfclass.todo
Keywords :
TB::oname : RETRO::lrftrain


Short Description:
The total_error variable depends only on last pattern - it should be global (fix provided)
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By : yishay@wisdom.weizmann.ac.il
Date : 08-Jan-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
2. calculating total error (LRFtrain). the total_error value is used to determine when the training process may be finished. the total_error variable is initialized to zero before each pattern, so the decision whether to finish training or not depends only on the error in the last pattern. I moved " total_error = 0.0 " out of the loop over the patterns.
Notes :
Keywords :
TB::oname : RETRO::lrftrain


Short Description:
want to use class 0 but programs is written so that no input may be classified as "0"
Work-Around :
Severity : 3a- Major inconvenience
Priority : 4 - Low
Reported By : yishay@wisdom.weizmann.ac.il
Date : 08-Jan-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
3. interpetetion of the zero class (LRFtrain). I would like to get a pattern classified "0" if it is not similar to any of my examples. The training set contains only "positive" examples, so I want class "0" to mean "negative" answer. As it is now, node 0 (which does not correspond to any input vector) will get such weights that it will "activate" the class which has most of the examples in the training set, and no input may be classified as "0".

For example - 10 vectors in the training set. 8 belong to the first center (class 1), 2 to the second center (class 2).

typical weights node / class 0 1 2

0 -1 1 -1 1 0 0 0 2 0 -2 2

My solution (first try) is to train only the weights of the "real" nodes and to set the weiths of node 0 : it will have 1.0 class "0", 1.0 for any other class.

The weights from each "real" node to class "0" should be negative. I am not sure yet what should be the best value.

That is it for now. I will be happy to know if you have any comments. yishay (yishay@wisdom.weizmann.ac.il)
Notes :
Keywords :
TB::oname : RETRO::lrftrain

vbandsp1


vbandsp3


vcast


vclose



Short Description:
vclose documentation needs a description of algorithm
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 3 - Medium
Reported By : Martin C. Martin, martin@vis.toronto.edu
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Does anybody know where I can find a description of the algorithm that vclose uses? Was a paper written explaining it? Thanks, Martin.
Notes :
Keywords :
TB::oname : RETRO::vclose


Short Description:
vclose - Segmentation fault in sample workspace (K1.0.5)
Work-Around :
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 3 - Medium
Reported By : Bakke Peter A, peteb@aplcen.apl.jhu.edu
Date : 12-Mar-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
vclose - Segmentation fault in sample workspace. Trying to run the workspace "repos/workspace/vipl_wksp/edge" results in a segmentation fault in vclose.
Notes :
Keywords :
TB::oname : RETRO::vclose


Short Description:
vclose draws a vertical line at col 127 for 640*512 images
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : shirley@peabody.eece.unm.edu
Date : 28-Mar-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I think there is a minor bug in vclose with rectangular images. vclose draws a vertical line at col 127 for 640*512 images. If you run: vgconst -o junk -r 640 -c 512 -b 1 -l 0.5 -m 0 -t "byte" followed by vgef and vdiff, then vclose, (with all defaults) you will see the what I mean. The same problem happened with the standard image "tools.xv"
Notes :
Keywords :
TB::oname : RETRO::vclose

vcltrans



Short Description:
color space model not correctly set by vcrgbhls
Work-Around : explicitly set colorspace model after operation
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Victor E. Roetman, vroetman@beta.tricity.wsu.edu
Date : 01-Sep-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Subject: HLS colorspace in KHOROS I am very confused about changing colorspaces in KHOROS. When I take a 24 bit color image, run it through vcrgbhls , and then back through vcrgbhls again (in hls to rgb mode), then my color image then becomes a grey scale image. I guess basically what I would like to be able to do is a histogram stretch on a color image, yet leave the colors alone. I do not know how to do this in RGB mode, and I can't seem to be able to convert to HIS (HSI) or HLS or anything effectively. Can anyone give me some advice or direction?

Also, if I put three images into vbandcomb, and select another colorspace, it doesn't seem to work either. Thank you very much. Victor Roetman, Washington State University TriCities
Notes :
Keywords :
TB::oname : RETRO::vcltrans


Short Description:
vcltrans (K2) fails for valid color space model
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Matthew G. Fleming, mgf@post.its.mcw.edu
Date : 20-Nov-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Here's a small bug: I have some RGB images created with the K1 tiff2viff. When I try to use the K2 "Linear Convert" program on them, to convert to cieXYZ space, I get the following error message:

RETRO vcltrans The attribute does not exist and is not defined at specified scope. Input image has an invalid color space model.

Valid color space models are: ....generic RGB.....

Data Object Info shows the color space of the input image to be KRGB. Using Set Attribute to set the color space of this image to RGB does not help.

The K1 version of the linear color conversion program handles this without difficulty.
Notes :
Keywords :
TB::oname : RETRO::vcltrans

vcmtrans


vconvert


vcost


vdetilt


vdistance


vdrf


venhance


vfht


vfractal


vgamth


vgbox


vgcirc



Short Description:
circle with diameter 0 should generate an empty image, but generates an image with diameter = 1
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : lotufo@water.khoros.unm.edu
Date : 20-Jul-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Notes :
minor bug report on circle generator circle with diameter 0 should generate an empty image. It is now generating a diameter 1 image.
Keywords :
TB::oname : RETRO::vgcirc

vgef


vgettilt


vgfractal


vgpwl


vgrow


vhmed


vhxray


vlabel



Short Description:
vlabel doesn't appear to use a "split and merge" approach, but documentation says it does
Work-Around :
Severity : 2b- Documentation incorrect, or so poor that functionality is unusable
Priority : 3 - Medium
Reported By : Steve Kubica
Date : 14-Nov-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
vlabel doesn't appear to use a "split and merge" approach.

I come to this conclusion primarily after reading a comment in the code over the labeling function that says "this function could be improved by adding heuristics for merging or split region". ;^)

I therefore do not think I will discuss splitting and merging in the section on vlabel in my thesis.

------------ However, for the record, here is what it appears to do : (note : I really only studied the case for gray-scale images, so I'm not really sure how different it is for cluster-center images.. I don't think it's too dramatically different though)

Pixels within a region are considered to be connected if the "distance" between them is less than some threshold. (distance can be either euclidean or city-block and is calculated between neighboring pixel vectors)

This threshold is set according to a mutually exclusive parameter :

Either : Number of regions expected is set - or - Split and merge factor is set

Split and merge factor - simply used to "fix" a distance threshold which will determine if two pixels are connected or not. If this is specified, the labeling process is applied once.

Number of expected regions - data is "analyzed" to try and guess at a distance threshold which will produce the desired number of regions. The labeling process is applied using that threshold and the number of regions it produces is compared to what is desired. If the expected number of regions are not produced, then the threshold is "fudged" and the labeling process is applied again. If after 30 tries it doesn't come up with the desired number of regions, it gives you the one that came closest.

The "labeling process" essentially is to go to each pixel and compare it to its neighbors using a distance metric. If it's close enough to its neighbors (according to the distance threshold) then its it's linked into their region. If its not close enough to *any* of the neighbors, then a new region is started. I think there's some merging going on in the sense of when a pixel successfully "connects" two disjoint regions, those regions are merged.

A post-labeling process then goes and identifies "small" regions and either zaps them or merges them. (where the definition of "small" is an user-defined option).

// Steve K
Notes :
Integrate Steve's notes into the documentation
Keywords :
TB::oname : RETRO::vlabel


Short Description:
vlabel error when merge factor is greater than 1
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Donna Koechner
Date : 05-Aug-91
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
In vlabel, if you put in merge factor of greater than 1, you get an error message saying that that is an invalid value, but the routine goes ahead and runs, and you get results. I don't know if they're valid.
Notes :
This routine is a real tangle - scott
Keywords :
TB::oname : RETRO::vlabel


Short Description:
error message in vlabel says cluster center image has to be FLOAT, but is checking for it to be VFF_TYP_4_BYTE! make sure this is not in K2
Work-Around :
Severity : 2b- Incorrect behavior
Priority : 3 - Medium
Reported By : Mathew Yeates
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I found the offending code. (Had to untar the source)

if (clus_cent ->data_storage_type != VFF_TYP_4_BYTE) { (void) fprintf(stderr, "vlabel: cluster center image has to be a FLOAT image\n\n"); exit(1); } Now the question: Is it supposed to be FLOAT or INT? The cluster center image seems like it should be FLOAT. Has anybody ever run this routine? Is this the routine to use for lrftrain? -Mathew

----- bug report for same problem ----- from Kevin Burton, noran!iowa!kburton@uunet.uu.net, 06-Apr-93 The man page says that vlabel can take input from vkmeans as an alternative to a multi-banded input image. I have been unable to get it to work this way. In cantata the gliphs look like:

+-------+ +-------+ | >|-----\ |> | | >|------\-------|> | | >| -------|> | | | | | |vkmeans| | vlabel| +-------+ +-------+

First vlabel complained that the CC image needed to be of type FLOAT. I added vconvert in between vkmeans (the second output) and the vlabel (the second input). Vlabel continued to complain that the CC image needed to be of type FLOAT. I checked that vconvert was indeed converting to FLOAT and it was. Is there someone that has used vkmeans this way that might be able to give me some pointers ? Kevin Burton Noran Instruments voice: (608) 831-6511 x317
2551 West Beltline Highway, Room 532 FAX: (608) 836-7224 Middleton, WI 53562 email: kburton@noran.com
Notes :
Keywords :
TB::oname : RETRO::vlabel


Short Description:
vlabel creates incorrect border when setting "-w 0"
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Anqi Ye, aye@fourier.ece.cmu.edu
Date : 23-Aug-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I use "-w 0 " in vlabel. But it always excludes a border of 2 pixels on 4 sides and assigns a value 0 to the border. It there any way to specify 0 border width? The vman page says default is 0, and bounds are 0 < [-w] < 16 -- seems self-contracdictory. Anqi Ye aye@fourier.ece.cmu.edu ECE Dept. (O)(412)268-3264 Carnegie Mellon Univ. (H)(412)687-8542 Pittsburgh, PA 15213
Notes :
Keywords :
TB::oname : RETRO::vlabel

vmarr


vmediaxis


vmindis


vmos2band


vpml


vqerr


vquant


vsamp


vsdef


vshape



Short Description:
The K2 version of vshape core dumps when "principal axis" is selected
Work-Around :
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 3 - Medium
Reported By : Matthew G. Fleming, mgf@post.its.mcw.edu
Date : 04-Dec-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
The K2 version of vshape core dumps when "principal axis" is selected under "axis representation". And there are lots of sqrt: domain errors when "X and Y moments" is selected instead.
Notes :
Keywords :
TB::oname : RETRO::vshape


Short Description:
vshape gets X center and Y center switched (fix provided in report)
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 3 - Medium
Reported By : Ruth Rosenholtz, rruth%robotics.Berkeley.EDU@ucbvax.berkeley.edu
Date : 23-Sep-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Does vshape get X center and Y center switched? I ran it on an image of an ellipse, where the center of the ellipse is at (20,15), and vshape gives me (X center, Y center) = (15,20). I can send you the output of vshape and the uuencoded viff image, if you want. This probably means that other outputs are switched between x and y.

Your code says:

for (row = 0; rowm10 += a2; ... } } ... xm = m10 / m00; obj[ind]->xcent = xm;

Note that col is the *x* coordinate, and row is the *y* coordinate, so to find m10, you're multiplying the pixel value by the *y* value. Ruth Rosenholtz, UC Berkeley
Notes :
Keywords :
TB::oname : RETRO::vshape


Short Description:
Documentation states that the -mc option will compute the normalized central moments, when the central moments are really computed (fix and other clarifications provided in bug report)
Work-Around :
Severity : 2b- Documentation incorrect, or so poor that functionality is unusable
Priority : 3 - Medium
Reported By : Greg Donohoe, donohoe@conjurer.eece.unm.edu
Date : 13-May-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
In: 'Vshape function', jacques@ele.etsmtl.ca. writes: + I have 2 simple questions concerning the documentation + (help) of the Vshape function. + 1- It says that if we use the option -mc, the function will + compute the normalized central moments. This is not true, + this option will in fact compute the central moments (not + the normalized ones). I have notice that i must use the + option -mi instead.

You are right...in my copy of 'vshape', the help page says:

-mc when set to one, this computes the set of central moments and normalized central moments. The central moments are invariant to translation, and the normal- ized central moments are invariant to both size and translation.

This is wrong...-mc only gives the central moments.

+ 2- Are the central normalized moments (used with the -mi + option) invariant to the rotation? (it should be)

The central normalized moments are not invariant to rotation, they are normalized by scale (area, or m00). This is a common interpretation of normalized moments, though it may not be the only one.

The it is possible to generate moments that are invariant to rotation and *not* scale. This option is not implemented in 'vshape'.

I have verified that the invariant moments provided by 'vshape' (-mi option) are indeed invariant to position, scale and rotation. This option *also* gives you the (scale) invariant moments.

Perhaps the documentation should be clarified on these points. Thank you for your observations. -- Greg Donohoe
Notes :
Add these clarifications to the documentation
Keywords :
TB::oname : RETRO::vshape


Short Description:
the statistics output of vshape does not follow the order mentioned in the man page
Work-Around :
Severity : 2b- Documentation incorrect, or so poor that functionality is unusable
Priority : 3 - Medium
Reported By : Patrick Haggard, ph@physiol.ox.ac.uk
Date : 25-Mar-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
The statistics output of vshape does not follow the order mentioned in the man page: the x and y values are exchanged. Is this anything to do with the fact that the MSVD glyph also outputs the matrices in the wrong order? This seems to me like a bug, although it`s trivially easy to cope with once you know it's there. Shouldn't this be acknowledged? Or am I way out? Patrick
Notes :
Keywords :
TB::oname : RETRO::vshape


Short Description:
eccentricity of region changes with rotation, and the angle Theta does not correspond with the rotation of the region
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 3 - Medium
Reported By : dodm2804@ele.etsmtl.ca
Date : 26-Jul-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
The problem that I have with vshape is that I do not understand the result given by vshape which I found very strange. First, what you call the X axis in your reference manual for vshape is the vertical axis. So, I have one region which is almost vertical in the image and the result for Theta and the eccentricity are the following: Theta : -4.072522e-02 Eccentricity : 4.947488e-01 Then, I rotate this region of +57.3 degrees (clockwise) and the result given by vshape are: Theta : 5.207974e-01 Eccentricity : 1.698994e+00 I am very surprise that the eccentricity of the region have change and that the angle Theta does not correspond with the rotation of the region in the image. Am I missing something here or if there are some bugs in the results given by vshape, and how should it be corrected? Thank you! Michel. (I am working with Khoros 1.0, Patch Level 5.)
Notes :
Keywords :
TB::oname : RETRO::vshape


Short Description:
bug in calculation of M7 in vshape
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 3 - Medium
Reported By : jonb@marel.is
Date : 22-Jul-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
bug in calculation of M7 in vshape
Notes :
Keywords :
TB::oname : RETRO::vshape


Short Description:
regions in the ASCII output do not always correspond directly to the regions in the VIFF output (ie. the label numbers are mismatched), and the x- and y-coordinates which identify the region location, are intechanged for some entries in the ASCII output.
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 3 - Medium
Reported By : George S. Chamberlain, gsc@doe.carleton.ca
Date : 25-Feb-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I have been using vshape to extract positions of regions identified by vlabel.

Upon examining the ASCII output, I have found that the regions in the ASCII output do not always correspond directly to the regions in the VIFF output (ie. the label numbers are mismatched). The background (region 0) is always correct, however the others appear to be one off. Also, the x- and y-coordinates which identify the region location, are intechanged for some the entries in the ASCII output.

Has anyone observed this before? Is there a patched vshape.prog file lounging on an ftp site somewhere? I tried to check ftp.eece.unm.edu earlier, but it is denying anonymous access. George Chamberlain, gsc@doe.carleton.ca
Notes :
Keywords :
TB::oname : RETRO::vshape


Short Description:
unclear documentation - when using vlabel, what difference does the split & merge factor make?
Work-Around :
Severity : 2b- Documentation incorrect, or so poor that functionality is unusable
Priority : 3 - Medium
Reported By : George S. Chamberlain, gsc@doe.carleton.ca
Date : 25-Feb-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
On the same vein, when using Vlabel, what difference does the split & merge factor make? I have noticed that regardless of what value I enter in the pane, it performs multiple iterations. Each iteration uses a new value for this factor, but it always ends off using the results of the first iteration. Also, the reported results of the subsequent iterations have always been identical to the first.

Any help in understanding just what is going on in vlabel, and vshape anyone can provide for me will be greatly appreciated. George Chamberlain, gsc@doe.carleton.ca
Notes :
Keywords :
TB::oname : RETRO::vshape


Short Description:
vlabel allows split-and-merge factor to increase above 1, but cannot be set above 1 in the pane
Work-Around :
Severity : 4a- Non-standard behavior
Priority : 3 - Medium
Reported By : George S. Chamberlain, gsc@doe.carleton.ca
Date : 25-Feb-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
The images I have been working with recently are about 512x350 and contain about 25-35 regions, the smallest of which is about .004% of the total image size - about 25 pixels^2. About 80% of each image is background information. I have noticed that the split-and-merge factor for these images increases above 1 for these images (but cannot be set above 1 in the pane). The output the routine gives is correct. George Chamberlain, gsc@doe.carleton.ca
Notes :
Keywords :
TB::oname : RETRO::vshape

vslope


vspatial


vspeckle



Short Description:
Documentation does not relate the algorithms described by Crimmin to the C program. (very nice clarification provided in the bug report)
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 3 - Medium
Reported By : Mike Bruce, nobody@kodak.com
Date : 04-Mar-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
In "crimmin's geometric filter", Leen-Kiat writes: + I have been working with the geometric filter. I had the + original paper written by Crimmin's. And I have read the + help file provided by KHOROS. tried to follow through the + program file (written in C). I could not relate the + algorithms described by Crimmin to the C program. Would you + please explain in greater detail how the program works? For + example, what does positive hull procedure do? What does + negative hull procedure do? What does the center pixel + compare to? Thanks. + Leen-Kiat

At the highest level, Crimmins algorithm can be explained as follows:

The structuring element is an 8-hull approximation to a convex hull. Relative to the center pixel, comparisons are made in 8 directions, N, S, E, W, NE, SE, SW, NW.

If you view the image as a 3-D surface, these comparisons are used to nonlinearly "smooth" the surface. The positive hull procedure can be viewed as "rolling" an octahedron over the top of the image surface. Assuming that the structuring element will fall into the valleys on the surface, the valleys are given a grey-scale value corresponding to the depth at which the octahedron can fall into the valley. Of course, the minimum valley grey value is assumed to be zero. Similarly, the negative hull procedure can be viewed as rolling the structuring element under the surface of the image. Here, peaks are reduced to the level corresponding to how far up the peak the octahedron can fit.

It is clear that spatially small peaks and valleys are smoothed with fewer iterations than spatially larger ones. Desired features that are spatially very small may even be removed after one iteration. Also, deeper (grey-scale variation) features will may require additional iterations in order to obtain the desired surface smoothness.

I hope this provides some insight into the algorithm.

Michael Bruce Ektron Applied Imaging 23 Crosby Drive Bedford, MA 01730 (617) 271-1825 bruce@ektron.kodak.com
Notes :
Integrate Bruce's explanation into doc (and credit him)
Keywords :
TB::oname : RETRO::vspeckle

vsurf


vtilt


vwmdd


verror


vipl


vutils