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