DATAMANIP toolbox : 5-July-96
kroutines
libraries
kappend
- Short Description:
- kappend fails when appending output of kstats
Work-Around : Not sure. need to verify whether it's a bug first.
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Abe Bushra
Date : 26-Oct-95
HW : SGI
OS : IRIX 5.3
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
I am trying to divide a 640X480 image into recangles of 80X80
pixels, and then collect statistic based on all (i.e 48 of them)
80X80 images and put them into an ascii file.
In order to implement this, I am trying to use "append" the output
of the 48 images. Is there any otherway of writing the statistics
output into "File Viewer" without having to reset the file.
At any rate, when I use append for this purpose here is the error
message:
Toolbox: DATAMANIP
Program: kappend
Library: main
Routine: kappend
Category: Unable to find any support for the specified format.
It is possible that the Data Services library was compiled with
not file format support.
Cannot open input object /usr/tmp/
The file exists and I can open it using an text editor.
I have been getting similar problems with print value, supported
formats, print data, etc. I have recompiled the sw, to no avail.
- Notes :
-
(Donna 24-Jan-96)
My gut feeling is that this is not a bug, but documentation
is lacking in kstats.
It is not clear whether he is trying to append the outputs
of extract, or the outputs of kstats. If it is the ascii
output of kstats, kappend should not understand this, so it
is correct behavior. Action:
Can data services provide a better error message?
Add note to documentation that this is for data only,
not ascii text files. use command icon to use
unix cat command? (I haven't verified this)
Also, i think the ascii output from kstats would
give what he wants if he set up the data and the
kstats arguments correctly. add an example to
kstats.
If it is failing with outputs from extract, this is a
severe bug.
I mailed him asking for clarification 24-Jan-96
"Were you using kappend to append the outputs of the extract
operation, or of the kstats operation. And, if it is the
kstats output, was it the ascii or binary output?"
Keywords :
TB::oname : DATAMANIP::kappend
karith1
- Short Description:
- testsuite failure on cray: test1d.sh
Work-Around : none
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By : Donna Koechner
Date : 21-Apr-95
HW : cray
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
- Notes :
-
Looked at the output - it is failing due to a bug. data looks
very different. (this may have been fixed by the char changes
that were released with pack2.)
Keywords :
TB::oname : DATAMANIP::karith1
karith2
kasc2loc
- Short Description:
- kasc2loc, kimportasc do not set location grid type
Work-Around : none
Severity : 4a-A
Priority : 1 - Mandatory
Reported By : Donna Koechner
Date : 11-Mar-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Notes :
Keywords :
TB::oname : DATAMANIP::kasc2loc
- Short Description:
- Needs better documentation
Work-Around : none
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By : Thomas Bueschgens sledge@i1.informatik.rwth-aachen.de
Date : 07-Sep-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Notes :
Keywords :
TB::oname : DATAMANIP::kasc2loc
kasc2map
- Short Description:
- Needs better documentation
Work-Around : none
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By : Thomas Bueschgens sledge@i1.informatik.rwth-aachen.de
Date : 07-Sep-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Notes :
Keywords :
TB::oname : DATAMANIP::kasc2map
kasc2mask
- Short Description:
- Needs better documentation
Work-Around : none
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By : Thomas Bueschgens sledge@i1.informatik.rwth-aachen.de
Date : 07-Sep-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Notes :
Keywords :
TB::oname : DATAMANIP::kasc2mask
kasc2time
- Short Description:
- Needs better documentation
Work-Around : none
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By : Thomas Bueschgens sledge@i1.informatik.rwth-aachen.de
Date : 07-Sep-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Notes :
Keywords :
TB::oname : DATAMANIP::kasc2time
kasc2val
- Short Description:
- Needs better documentation
Work-Around : none
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By : Thomas Bueschgens sledge@i1.informatik.rwth-aachen.de
Date : 07-Sep-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Notes :
Keywords :
TB::oname : DATAMANIP::kasc2val
- Short Description:
- kasc2val is difficult to use
Work-Around : not enough information in report to determine work-around
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Notes :
Keywords :
TB::oname : DATAMANIP::kasc2val
kaxis
kbessel
kbitwise
kblend
kclip
kcmplx
kcmplx2real
kcomment
- Short Description:
- history is not recorded
Work-Around : none
Severity : 4a- Non-standard behavior
Priority : 1 - Mandatory
Reported By :
Date : 12-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- history is not recorded
- Notes :
-
Need to set KPDS_HISTORY attribute in driver routine.
Needs audit.
Keywords :
TB::oname : DATAMANIP::kcomment
kcompare
- Short Description:
- test1.sh, test 5 of testsuite fails on cray (only)
Work-Around : none
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By : Donna Koechner
Date : 21-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Notes :
Keywords :
TB::oname : DATAMANIP::kcompare
kconvert
kcpfromval
kcpseg
kcptoval
kelevation
kextract
- Short Description:
- Strange error message printed when calling function incorrectly - errno is getting set somewhere in an underlying library.
Work-Around :
Severity : 4a- Non-standard behavior
Priority : 1 - Mandatory
Reported By : Birgit Gaschler Birgit.Gaschler@ifn-magdeburg.de
Date : 07-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
+ i want to use the libary function lkextract in my own toolbox.
+ If i use it for instance with the following call
+ lkextract(input_object,0,0,0,0,0,5,5,0,0,0,1,output_object)
+ then i obtain the following glyph help output:
+ Toolbox: MRI_TOOLBOX1
+ Program:test1
+ Library:kdatamanip
+ Routine:lkextract
+ Category:The attribute does not exists and is not defined at
+ specified scope.
+
+ All size parameters must be greater than zero.
+ I cannot found the source of this failure.
+ My outputfile (output_object) is finally the
+ inputfile (input_object).
- Notes :
-
The minimum size a dimension can be is 1. That is what
"All size parameters must be greater than zero" is complaining
about. The
"Category:The attribute does not exists and is
not defined at specified scope"
message is due to an errno being set earlier on. I'm not
sure when this is being set, and will put this on the bugs
list. If you change the function call to the following, it
should fix the problem.
lkextract(input_object,0,0,0,0,0,5,5,1,1,1,1,output_object)
^ ^ ^
Keywords :
TB::oname : DATAMANIP::kextract
- Short Description:
- wsize and hize documentation and behavior do not match
Work-Around :
Severity : 4c- Documentation unclear
Priority : 5 - None
Reported By : Hank van Bekkem - jbek@oce.nl
Date : 16-Sep-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
The default values for parameters wsize and hsize are not
128, as stated in the manual page, but as large as the
dimensions of the input object.
------------ another report ----------------
Tom Sullivan tdsulli@raptor.sandia.gov, 01-Mar-95, K2.0.1DR,
SUN Sparc or SGI
In running kectract from the command line with or without -P
option defaults listed are wsize 128, hsize 128, dsize 1,
esize 1, tsize 1. However if none of these parameters are
entered output is the same as input. Test case
kgconst -wsize 200 -hsize 200 -dsize 15 -type 3 -o file
kextract -in file -o new_file
new_file is the same size as file
kextract -in file -wsize 128 -hsize 128 -dsize 1 -o new_file
Now new_file is reduced size and is the size stated as the
defaults.
Notes :
Keywords :
TB::oname : DATAMANIP::kextract
kfft
kflip
kformats
kgate
kgconst
kgeneric
kgenloc
kgnoise
kgsin
khisto
khistops
kimportasc
kimportraw
kimpulse
kinsertseg
- Short Description:
- Poor error messages when trying to insert non-existent segments
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 1 - Mandatory
Reported By : Tom Sauer
Date : 28-Aug-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Poor error messages when trying to insert non-existent segments
mirage% kinsertseg -P
Enter: (i1) Source Input File {infile}: image:ball
Enter: (i2) Destination Input File {infile}: image:moon
Enter: (o) output file {outfile}: kktt
The following 6 arguments are a group.
Provide a value for AT LEAST ONE of the 6 arguments:
-val -map -mask -loc -time -segment
Enter: (val) If -val flag is selected, operate on Value segment
{flag, (y/n) [n]}: n
Enter: (map) If -map flag is selected, operate on map segment
{flag, (y/n) [n]}: n
Enter: (mask) If -mask flag is selected, operate on Mask segment
{flag, (y/n) [n]}: y
Enter: (loc) If -loc flag is selected, operate on Location seg
{flag, (y/n) [n]}: y
Enter: (time) If -time flag is selected, operate on Time seg
{flag, (y/n) [n]}: y
Enter: (segment) Perform operation on user specified segment
{string , ['Insert All'] }:
--------
Toolbox: DATAMANIP
Program: kinsertseg
Library: ksegops
Routine: lkcpseg
Category: The attribute does not exist and is not defined at
specified scope.
Failed to copy segment 'mask' from source object to
destination object.
Toolbox: DATAMANIP
Program: kinsertseg
Library: ksegops
Routine: lkcpseg
Failed to copy segment 'mask' from source object to
destination object.
Toolbox: DATAMANIP
Program: kinsertseg
Library: ksegops
Routine: lkcpseg
Category: The attribute does not exist and is not defined at
specified scope.
Failed to copy segment 'location' from source object to
destination object.
--------
Tom
- Notes :
-
The "The attribute does not exist and is not defined at
specified scope." error was reported in another kroutine,
and is being set somewhere in an underlying library. The
error statements in lkinsertseg should be made better.
Clean up data services error messages.
Also logged in data services
Keywords :
TB::oname : DATAMANIP::kinsertseg
kinset
kinverse
kkmeans
klinearop
klocxform
klogexp
kmapdata
- Short Description:
- map data through map runs forever on large data sets
Work-Around :
Severity : 3a- Major Inconvenience
Priority : 3 - Medium
Reported By : Patrick M Kelly, kelly@c3serve.c3.lanl.gov
Date : 06-Jun-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
This probably is not a bug, but I am curious about it. I
have a fairly large image in xvimage format:
File data storage type: BYTE
Number of pixels per band: 11803 rows by 9588 columns
or 113167164 pixels
Pixel subrow size: 0
Number of images per file: 1
Number of bands per image pixel: 1
Subimage: NO
File Data Compression: NONE
Pixel size: 1 (x) by 1 (y) meters
Machine dependency: IEEE
Color space model: genericRGB
Data Band Mapping scheme: ONE PER BAND
Map storage type: BYTE
Map row size: 3
Map col size: 256
Map subrow size: 0
Maps per cycle: 0
Enable the Map: OPTIONAL
I tried to "map data through map", and it ran for about an hour
before I gave up. It looked like it was using plenty of CPU
time, so it did not look like an I/O problem. Any ideas?
Oh, and another suggestion. On the help pages (khelp) it would
be nice if I could "grab text" with the cursor and dump it in
an xterm or something.
Pat
Notes :
Keywords :
TB::oname : DATAMANIP::kmapdata
kmsquish
knoise
knormal
- Short Description:
- knormal is using the default values for dmin and dmax, even though the option is not selected
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Donna Koechner
Date : 01-Dec-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
It looks like knormal is using the default values for dmin
and dmax, even though the option is not selected. should
be easy to fix....
Notes :
Keywords :
TB::oname : DATAMANIP::knormal
korient
kpad
kprdata
- Short Description:
- when printing a 1,1,1,1,1 size data set, kprdata does not print its coordinates
Work-Around :
Severity : 10a- Enhancement request
Priority : 3 - Medium
Reported By : Robert Lotufo, lotufo@khoros.unm.edu
Date : 22-Jul-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
when printing a 1,1,1,1,1 size data set, kprdata does not
print its coordinates. (I can understand why is doing this
though)
- Notes :
-
Currently, if lkprdata sees a dimension of size 1, it does not
print that coordinate. For example, in images, all you get are
the width and height indices, not all five. We could force it
to always print all indices. what do you prefer?
(Roberto responded that he would like to see us check special
case of w=h=d=t=e=1 and print all in that case)
Keywords :
TB::oname : DATAMANIP::kprdata
- Short Description:
- value printed "incorrectly" - 9.9 printed as 9.899999619
Work-Around :
Severity : 4a- Non-standard behavior
Priority : 1 - Mandatory
Reported By : Nichols Research Corp, nrc@cheetah.eglin.af.mil
Date : 21-Jun-95
HW : SPARC5
OS : Solaris 1.4
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
why does casting a float to a double do this?
% kgconst -type 10 -real 9.9 -o junk
% kprval -val -i junk
9.9
% kprdata -val -i junk
# Data Printed in the Following Format
# VALUE: 1 elements
# Value data cast to type Double (1024) for printing
9.899999619
%
- Notes :
-
Fix, if possible. Otherwise, add an explanation to man
page of why this happens on some platforms.
Enhancement - add format string to pane to allow direct
control of format.
Keywords :
TB::oname : DATAMANIP::kprdata
kprval
- Short Description:
- Documentation needs to be updated to explain how variables are updated
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 1 - Mandatory
Reported By : Sunjay Talele (IRMA), talele@iplsun.eglin.af.mil
Date : 13-Apr-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
There appears to be a bug such that kprval will not print
a data value into a variable.
Reproduce By:
-------------
kprval works as expected from the command line:
% kprval -i lenna.240.xv -val
117
% kprval -i lenna.240.xv -val -var 'x'
x = 117
%
but when used from inside cantata, it doesn't seem to. The
correct commands are echoed to the Console window but kprval
is writing to kstdout, which presumably has been redirected
somewhere. in any case, the variable is not being set, at
least not such that the Variables pane can see it. if you open the Define Variables / Evaluate Expressions pane and
enter x in the Expression field, and then click Evaluate, the
result displayed is x = 0
- Notes :
-
Sent this reply (donna)...
If you open the Variables pane and type x into the Expression
window and then select evaluate, the variable and the value
will appear. Basically, the variables pane is a static entity,
and does not reflect changes that occur in the workspace.
Perhaps we can add a "read variables" option to the pane
so that the current value of variables in the workspace
can be retrieved more easily.
(12-Feb-96 - donna)
Verify that this is still the case with the new (2.0.3)
cantata - it may be working differently now.
Keywords :
TB::oname : DATAMANIP::kprval
- Short Description:
- kprval does not set history attribute
Work-Around :
Severity : 4a- Non-standard behavior
Priority : 1 - Mandatory
Reported By :
Date : 11-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
kprval does not set history attribute
(might not make sense)
- Notes :
-
need to set history attribute in driver routine
Keywords :
TB::oname : DATAMANIP::kprval
kreal2cmplx
- Short Description:
- kreal2cmplx map padding is wrong on IBM (this causes tests 11a and 11b in the kreal2cmplx/test1.sh test suite to fail)
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 3 - Medium
Reported By : Donna Koechner
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
kreal2cmplx map padding is wrong on IBM. This causes tests
11a and 11b in the kreal2cmplx/test1.sh test suite to fail:
The kreal2cmplx testsuite fails on the ibm (only). It looks
like it is a problem with the map padding value - the Value
Data is being padded before the mapping occurs instead of
after. This causes indexes into the zero row of the map,
instead of padding with zero after the mapping has occurred.
Of all of the architectures that we run testsuites on, Ibm is
the only architecture where this is happening.
The original inputs look like this:
input1 (real part)
map data
0.1 0.2 0.3
1.1 1.2 1.3
2.1 2.2 2.3
3.1 3.2 3.3
4.1 4.2 4.3
value data
1 2 3
input 2 (imaginary part)
value data
1 2 3
5 6 7
correct output
(1.1, 1)(1.2, 0)(1.3, 0) | (2.1, 2)(2.2, 0)(2.3, 0) |
(3.1, 3)(3.2, 0)(3.3, 0)
(0, 5) (0, 0) (0, 0) | (0, 6) (0, 0) (0, 0) |
(0, 7) (0, 0) (0, 0)
ibm output
(1.1, 1)(1.2, 0)(1.3, 0) | (2.1, 2)(2.2, 0)(2.3, 0) | (3.1, 3)(3.2, 0)(3.3, 0) (0.1, 5)(0.2, 0)(0.3, 0) | (0.1, 6)(0.2, 0)(0.3, 0) | (0.1, 7)(0.2, 0)(0.3, 0) --- --- --- --- --- --- --- --- ---
the underlined values are all from map row 0
Donna
Notes :
Keywords :
TB::oname : DATAMANIP::kreal2cmplx
- Short Description:
- kreal2cmplx fails for large data set
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
fails for large data set (?)
Notes :
Keywords :
TB::oname : DATAMANIP::kreal2cmplx
kreplace
kresample
- Short Description:
- incorrect results on cray - the following testsuites fail kresample/test1.sh tests 1,3,7,8,10, kresample/test2.sh tests 1,2,3,4,5
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By : Donna Koechner
Date : 21-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
The results on the cray are *way* off.
cray testsuite failures: test1.sh tests 1,3,7,8,10 fail
test2.sh tests 1,2,3,4,5 fail
- Notes :
-
this may have been fixed with the char changes that were
made in pack2.
- Short Description:
- test suite fails for small buffer size
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
test suite fails for small buffer size
- Notes :
-
krmseg
ksampline
- Short Description:
- cray testsuite failures - the results on the cray are *way* off
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By :
Date : 21-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
cray testsuite failures:
The results on the cray are *way* off.
- Notes :
-
this may have been fixed with the char changes that were
made in pack2.
Keywords :
TB::oname : DATAMANIP::ksampline
ksegcmp
- Short Description:
- history attribute is not set
Work-Around :
Severity : 4a- Non-standard behavior
Priority : 1 - Mandatory
Reported By :
Date : 11-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
- Notes :
-
need to set history attribute in driver routine
(may not make sense)
Keywords :
TB::oname : DATAMANIP::ksegcmp
ksetdattr
kshot
- Short Description:
- test1.sh test 1 fails on cray.
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By :
Date : 21-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
cray testsuite failures: test1.sh test 1 fails
The results on the cray are way off.
- Notes :
-
This may have been fixed with the char changes that were
made in pack2.
Keywords :
TB::oname : DATAMANIP::kshot
- Short Description:
- Shot noise is taking deadly long time to execute.
Work-Around :
Severity : 3a- Major inconvenience
Priority : 2 - High
Reported By : Roberto Lotufo, lotufo@khoros.unm.edu
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Shot noise is taking deadly long time to execute. It works, but
too slow. see workspace ~lotufo/workspaces/bugs/shot-bug.wk
- Notes :
-
I would guess that this is due to the implementation. I
believe that Ashish decided to use put_data's of single
points since knoise is corrupting a input image at random
locations.
So, the problem might be more related to the efficeince of
writing single points. I think the implementation is valid,
data services might be able to be better optimized to support
it.
Look at kshot and decide if the implementation is using data
services properly?
Re-write - first determine coordinates of pixels that will
be updated using dimension data. Then use sorted coordinate
list to update modified pixels (rather than getting and
putting single points in an arbitrary manner like lkshot
currently does).
Keywords :
TB::oname : DATAMANIP::kshot
kstats
- Short Description:
- cray testsuite failures - test1.sh test 1 fails
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By :
Date : 21-Apr-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
cray testsuite failures: test1.sh test 1 fails
The kurtosis ascii values printed out are different than
those in the "correct results" file.
Notes :
Keywords :
TB::oname : DATAMANIP::kstats
- Short Description:
- statistics appears to do incorrect dimensioning & indexing
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 2 - High
Reported By : Michael L. Webb, mwebb@dynatec.com
Date : 19-Oct-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
I was using K2 to calculate the statistics and make histograms of
a 512 x 512 x 4 array. I selected processing over all dimensions
except the height dimension (i.e. the second 512). Both statistics
and hstogram appear to take counts from the (i,0,j) locations and
put them into (.,0,.) or (.,256,.)
It appears to be some sort of dimensioning error.
Notes :
Keywords :
TB::oname : DATAMANIP::kstats
- Short Description:
- It may be possible that doing stats down H on a WxH data set large enough to require large data set processing will give bogus results
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Scott Wilson
Date : 08-Jan-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
It may be possible that doing stats down H on a WxH data set
large enough to require large data set processing will give
bogus results because of the auto-incrementing along the lowest
index order instead of down the H region. This may only turn
up if we need to do constrained optimal regions - just check
it out. Look at the code for lkhisto(), which does correctly
handle this for ideas on how to implement a solution.
Notes :
Keywords :
TB::oname : DATAMANIP::kstats
kunmask
kwiener
kdatamanip
- Short Description:
- running out of memory when I shouldn't be when calling kdatamanip library functions (may be data services)
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Prem Janardhan, prem@poi.graphics.cs.cmu.edu
Date : 30-May-95
HW : SGI
OS : Irix 5.3
Widget : not applicable
C :
Fortran :
Perl :
X :
Win Mgr : not applicable
Display : not applicable
- Original Rpt:
-
Program Name:
------------
lkextract
lklinearop
lkconvert
... not sure exactly where the problem is ...
Bug Description:
---------------
Basically, I am running out of memory when I shouldn't be.
I am working with a large image (which contains only a value
segment) with the following dimensions, datatype KSHORT:
width w = 512
height h = 256
depth d = 8
time t = 10
elements e = 1
I want to perform some image processing on each width X height
"slice" of the above 4D image. I tried the following things:
First
*****
for (i=0; i
Second
******
for (i=0; i
retval = kpds_set_attribute(tmpobj1, KPDS_VALUE_POSITION,
0, 0, 0, 0, 0);
assert (retval==TRUE);
retval = kpds_set_attribute(tmpobj2, KPDS_VALUE_POSITION,
0, 0, 0, 0, 0);
assert (retval==TRUE);
retval = lklinearop (tmpobj1, kernel, CIRCULAR_CONVOLUTION,
0.0, 0.0, offset, TRUNCATE_RESULT,
REFLECT_KERNEL, 2, dim_list, sub_size,
sub_pos, UPCAST, tmpobj2);
assert (retval == TRUE);
}
}
Third
*****
for (i=0; i
retval = kpds_set_attribute(tmpobj1, KPDS_VALUE_POSITION,
0, 0, 0, 0, 0);
assert (retval==TRUE);
retval = kpds_set_attribute(tmpobj2, KPDS_VALUE_POSITION,
0, 0, 0, 0, 0);
assert (retval==TRUE);
retval = lklinearop (tmpobj1, kernel, CIRCULAR_CONVOLUTION,
0.0, 0.0, offset, TRUNCATE_RESULT,
REFLECT_KERNEL, 2, dim_list, sub_size,
sub_pos, UPCAST, tmpobj2);
assert (retval == TRUE);
retval = kpds_set_attribute(tmpobj2, KPDS_VALUE_POSITION,
0, 0, 0, 0, 0);
assert (retval==TRUE);
retval = kpds_set_attribute(tmpobj3, KPDS_VALUE_POSITION,
0, 0, 0, 0, 0);
assert (retval==TRUE);
retval = lkconvert(tmpobj2, "value", "short", 1.0, 0.0,
0.0, tmpobj3);
assert (retval == TRUE);
}
}
Basically, I tried:
1) extracting each slice in the image using lkextract
2) extracting each slice, then convolving it with a kernel
3) extracting eac slice, convolving it with a kernel, then
converting the data type of the result
The objects tmpobj1, tmpobj2 and tmpobj3 and kernel were all
created using kpds_create_object before the loops shown above
(in the main_before_lib_call section. A value segment was
created for each, and then the VALUE_SIZE and VALUE_DATA_TYPE
attributes were set as follows:
tmpobj1=kpds_create_object(); assert (tmpobj1!=KOBJECT_INVALID);
retval = kpds_create_value(tmpobj1); assert (retval==TRUE);
retval = kpds_set_attributes(tmpobj1, KPDS_VALUE_SIZE, w, h,
1, 1, 1, KPDS_VALUE_DATA_TYPE,
KSHORT, NULL);
assert (retval==TRUE);
Only kernel had a smaller size, and it was initialized as
follows:
kernel = kpds_create_object(); assert (kernel!=KOBJECT_INVALID);
retval = kpds_create_value(kernel); assert (retval==TRUE);
retval = kpds_set_attributes(kernel, KPDS_VALUE_SIZE, win, win,
1, 1, 1, KPDS_VALUE_DATA_TYPE,
KDOUBLE, NULL);
where the value of win=5
kernel was later initialized to contain a 2D gaussian using
ligauss_func
What I observed
***************
In all the three runs, the process size as measured by
"cvmeter", kept increasing. Also, the second run consumed
more memory faster than the first and the third run consumed
more memory, faster, than the second. The third run was
killed by the system automatically (presumably because it
ran out of memory).
Approximate amounts of memory used in the three cases:
1) went from 5M to about 10M
2) went from 5M to almost 20M
3) went from 5M to 30-40M
Reproduce By:
-------------
I can send you the source code for my program, and give
you access to my images if necessary.
- Notes :
-
Data services - each open segment has it's own buffer.
Restructure?
also logged in dataserv
Keywords :
TB::oname : DATAMANIP::kdatamanip
ksegops
- Short Description:
- lkcopyseg - you can't lkcopyseg to an output reference, only to the output object.
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Wallace J Bow Jr, wjbow@raptor.sandia.gov
Date : 06-Jun-95
HW : SGI,
OS : IRIX 5.3, 6.0.1, 89.72, pretty much anything really
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display : All NEC Teletypes, punch card readers/writers, ...
- Original Rpt:
-
lkcopyseg - You can't lkcopyseg to an output reference, only
to the output object.
Reproduce By:
------------
I wrote a simple routine that does this:
lcopy_me(kobject in, kobject out)
{
kobject in_ref, out_ref;
in_ref = kpds_reference_object(in);
out_ref = kpds_reference_object(out);
/* if out is outref, it doesn't work */
lkcopyseg(in_ref,"myseg",out);
kpds_close_object(in_ref);
kpds_close_object(out_ref);
}
It doesn't copy the segment. The segment is not even created
in the output object.
- Notes :
-
Possibly a data services bug?
Keywords :
TB::oname : DATAMANIP::ksegops