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