DATASERV toolbox : 5-July-96


kroutines libraries

kgdbm_dump


kappserv



Short Description:
should subobject position mutually exclusive with location da ta?
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By : Donna K
Date : 6-May-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I've been working with subobject position quite a bit lately, and it looks like it should be mutually exclusive with location data. The reason I say this is if you have, for example, uniform begin and end points and a subobject position, you are setting up conflicting information. For example, if you run kextract, it should give new values to the begin and end points if there is uniform data, not set the subobject position - the begin and end points contain that info already. Allowing both may be confusing and incorrect.

The multi-input datamanip routines are using (or going to be using) subobject position. This means that if you add 2 objects, the subobject position will be used in calculating the resulting size, and the objects will be physically offset so that the subobject positions line up.

Therefore, you may start getting "unexpected" results when you perform karith2 operations on objects that have been extracted. I have an option in kextract that allows the user to choose whether the subobject position should be set when extracting. The default is NO. I don't know if you can add this option to the extractor. If you can, it might be a good idea - otherwise the users will probably start complaining ... (the default might be TRUE, due to the nature of the interactive extractor).

karith2, kgate, and any pains that call them are the only objects that currently behave this way, but this is the direction that datamanip is going, so more will act this way in the future.

As a side note, there is overlap in meaning between subobject position and explicit location data (uniform, rectilinear, and curvilinear). I think we should make these two mutually exclusive in data services.
Notes :
Keywords :
TB::oname : DATASERV::kdataman


Short Description:
All Retro routines convert uniform location data to curvilinear (data services bug)
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Lavoie Philippe, lavoie@gemini.genie.uottawa.ca
Date : 28-Jul-95
HW : SPARCStation II
OS : SunOS 4.1.3
Widget : Motif
C :
Fortran :
Perl :
X :
Win Mgr : mwm
Display : 24 bit, gx12+
Original Rpt:
RETRO toolbox, all the routines + all toolbox relying on the RETRO toolbox

The grid type of the input image is Uniform, the grid type of the output image becomes curvilinear. This causes the images an increase in disk size of 12.6 times for a 512x480 grey level image. Since all routines relying on the retro toolbox reads the whole image, memory problems occurs very easilly.

Is there a fix for that ? Or can I remove the GridType Uniform information from the input image. The bug only occurs when the information is present in the input image.
Notes :
This bug is also logged in $RETRO/repos/info/todo
Keywords :
TB::oname : RETRO/repos/info


Short Description:
Resampling on data read in from rgb PNM format
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Steve J
Date : 24-Jul-96
HW : SGI
OS : Irix 5.3
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
On rgb pnm files, the zoom in editimage freaks out. Note, rgb kdf files work fine. Converting the pnm files to kdf files works fine. Converting a working kdf file to pnm shows same problem. reproduce by: 1. start up editimage with image:colortest 2. open the zoom window 3. move mouse around in original image, note how the zoom window looks..
Notes :
Keywords :
TB::oname : DATASERV::kappserv


Short Description:
Mapping to out-of-bounds map rows results in mapping to the map pad values.
Work-Around : Set the map pad value to some zany number to identify out of bounds mapping.
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By : Scott Wilson
Date : 07-Mar-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Mapping to out-of-bounds map rows results in mapping to the map pad values. It would be useful, if the map interpolation attribute was set to KNONE, if the mapping would fail with an error message. Currently, all out-of-bounds mapping goes to the map pad value.
Notes :
Keywords :
TB::oname : DATASERV::kappserv


Short Description:
kpds_set_attribute sometimes fails with in-line functions
Work-Around : Do not in-line functions for attribute values.
Severity : 2a- Incorrect behavior
Priority : 5 - None
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Set up some code that looks like:

int w1, w2, h1, h2, d1, d2, t1, t2, e1, e2; kobject in1, in2, o;

/* objects are opened using kpds_open_input_object */ /* output object is opened using kpds_open_output_object */

kpds_get_attribute(i1, KPDS_VALUE_SIZE, &w1, &h1, &d1, &t1, &e1); kpds_get_attribute(i2, KPDS_VALUE_SIZE, &w2, &h2, &d2, &t2, &e2); kpds_set_attribute(i1, KPDS_VALUE_SIZE, kmax(w1, w2), kmax(h1, h2), kmax(d1, d2), kmax(t1, t2), kmax(e1,e2)); kpds_set_attribute(i2, KPDS_VALUE_SIZE, kmax(w1, w2), kmax(h1, h2), kmax(d1, d2), kmax(t1, t2), kmax(e1, e2));

/* this works fine but if you then add the following line before initially getting the sizes, the output is incorrect */ kpds_set_attribute(i1, KPDS_MAPPING_MODE, KMAPPED); kpds_set_attribute(i2, KPDS_MAPPING_MODE, KMAPPED);
Notes :
Keywords : data services
TB::oname : DATASERV::kappserv


Short Description:
remove the geometry autoincrement code
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 3 - Medium
Reported By :
Date : 20-Jan-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
remove the geometry autoincrment code. If you explicitly set your position, get your data, and then get a primitive position dependent attribute, you'll get the attribute from the position *after* the one you set. It moves your position on you after you get the data
Notes :
Keywords :
TB::oname : DATASERV::kappserv


Short Description:
the minmax attribute is calculated on the entire value segment, but only a region of the other segments.
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Strangly enough, the minmax attribute is calculated on the entire value segment, but only a region of the other segments.
Notes :
Keywords :
TB::oname : DATASERV::kappserv


Short Description:
running out of memory calling kdatamanip library functions.
Work-Around :
Severity : 3a- Major Inconvenience
Priority : 3 - Medium
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 : DATASERV::kdataman


Short Description:
element vector is shifted by 4 bytes converting a 242 element K2 viff into the xvimage format
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 3 - Medium
Reported By : Jens Hektor, jens@physiology.rwth-aachen.de
Date : 04-Oct-95
HW : Sparc 10/51
OS : Solaris 2.3
Widget : OLIT
C :
Fortran :
Perl :
X :
Win Mgr : olvwm
Display : GX
Original Rpt:
kformats -xvimage I tried to convert a datafile containing 242 elements of 384x288 pixels of type ubyte to the khoros-1 format. The first 4 elements are forgotten, at the end there are 4 empty elements inserted. This happens even if DMS_BUFSIZE is set to 30M. The size of the file is below 27M. Reproduce By: I don't know whether this is due to my data or not. With animate the khoros-2 file is o.k., the khoros-1 file not.
Notes :
Keywords :
TB::oname : DATASERV::kappserv


Short Description:
Depending on the input file format (xv versus Sunraster), different values are returned when retrieveing the attribute KPDS_VALUE_OPTIMAL_REGION_SIZE.
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Depending on the input file format (xv versus Sunraster), different values are returned when retrieveing the attribute KPDS_VALUE_OPTIMAL_REGION_SIZE. The code for this attribute does not take the default presenation index order into consideration and gives you a jumbled region size which reflects the physical index ordering.

This has been verified to be correct behavior, optimal region size is sensitive to format specific information, such as index order. // SK 28-Feb-96
Notes :
Keywords :
TB::oname : DATASERV::kappserv


Short Description:
can not save complex RGB images to xbm format
Work-Around :
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 4 - Low
Reported By : Shannon W
Date : 4-Jul-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
load a complex RGB image, save it as an xbm, load the xbm, watch the floating point exception
Notes :
Keywords :
TB::oname : DATASERV::kappserv


Short Description:
complex RGB not reading properly
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Paula P
Date : 4-Jul-96
HW : Linux
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I saved the test:RGB:complex file in kdf format. When I read it back into editimage, it displayed grey fuzz -- The ankle (?) was no longer there. I couldn't get things to work when I saved to the viff format either!

Reproduce By : Open the files subform Open the test:RGB:complex image Save it in kdf format to a file called test Read test into editimage
Notes :
Keywords :
TB::oname : DATASERV::kdataccess


Short Description:
can not save complex RGB to ascii and reread
Work-Around :
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 4 - Low
Reported By : Shannon W
Date : 4-Jul-96
HW : Alpha
OS : OSF
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
saved test:RGB:complex as ascii, then loaded the ascii file and it is stuck. prob need some sort of error mesg or something...?
Notes :
Keywords :
TB::oname : DATASERV::kdataccess


Short Description:
Poor error messages when trying to insert non-existent segments
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 3 - Medium
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 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 : DATASERV::kdataman ---------- the rest of these are from 1.0.5 -------------------------------


Short Description:
read_pgmfile (K1.0.5) is unable to read some raw pgm files - verify the K2 readers are correct
Work-Around :
Severity : 4b- minor inconvenience
Priority : 2 - High
Reported By : Bourgeois Raphael, bourgeoi@tele.unit.no
Date : 01-Jul-94
HW : Sun4
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Bug in: pbm.c function: read_pgmfile and probably read_pbmfile and read_ppmfile. read_pgmfile (K1.0.5) is unable to read some raw pgm files. The error message is "read_pbm: Error! Attempted to read N bytes from the raw pgm file, but was only able to read N-n bytes." The bug is that after having read the last information from the header, more than one white space are read by read_whitespace. In fact, the raw data may contain some bytes that represent white characters. They are therefore skipped. To avoid this problem, I have replaced the read_whitespace function call between the header and the raw data by a simple getc. I only experienced this bug with pgm files but I guess it also occurs with pbm and ppm files. There is no reason why it would not. Reproduce By: ------------- I have a pgm file that can reproduce the error. Just ask me if interested. Machine & Operating System: not machine dependent bug, but I use a Sun4
Notes :
Also logged in data services

It's likely to still do this, but I suspect the fix may be more problematic than the problem. Not enough time before 2.1 to investigate further :-(
Keywords :
TB::oname : DATASERV::kappserv

kapputils


kdataccess



Short Description:
osf zero casting problem
Work-Around :
Severity : 1b- Data corruption or inaccuracy
Priority : 4 - Low
Reported By : Scott Wilson
Date : 7-Jun-96
HW : DEC Alpha
OS : OSF1
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:


OSF fails when trying to convert a long or ulong to float. This appears to be a new dataservices bug. (Try kconvert test08.sh or test09.sh on and OSF to see the problem. For example test08.sh can be set up to put the result from the kconvert and the standard in ascii so you can see what's happening. The signed long example:

result: 7 127 1 256 0 4 5.3692e+09 0 0 0 but should be: 7 127 1 256 0 1 0 1 0 1
Notes :
Keywords :
TB::oname : DATASERV::kdataccess


Short Description:
image of value all 0 is normalized to 255
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By : Steve K
Date : 4-Jul-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
If you have a floating point image that is all 0.0, and you display it, it will appear all white courtesy the data services normalization code.
Notes :
Keywords :
TB::oname : DATASERV::kdataccess

kdatafmt


kdataman



Short Description:
copy attribute from non-existent segment produces no error
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By : Steve K
Date : 4-Jul-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
If you copy an attribute from a nonexistent data segment, it does not fail.
Notes :
Keywords :
TB::oname : DATASERV::kdataman


Short Description:
strings must be retreived with char *, not char[] (doc this)
Work-Around :
Severity : 4c- Documentation is unclear
Priority : 4 - Low
Reported By : Tim Williams
Date : 6-May-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:


In "Re: Help with set_object_attribute()", Timothy Williams writes: + Hi. + + I had this problem myself a long time ago. You need to pass a char * + for the KPDS_COMMENT attribute, not a char[]. + + >From correspondence with Steve Kubica and Jeremy Worley about a year + ago: + + Another thing to check is the variable data type. It must be a + char * and not a char array. One thing that may not be too + clear from the documentation is that Data Serviecs does not return + a copy of the string, but it returns the actual pointer to the + internal string. This saves you the trouble of having to free it.
Notes :
Keywords :
TB::oname : DATASERV::kdataman


Short Description:
access of initialized variables should fail
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date : 6-May-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
One thing that might be a bug in data services:

In a call like this:

kpds_get_attribute(data_object, KPDS_VALUE_REGION_SIZE, &w, &h, &d, &t, &e);

d, t, and e were all returned as 0, since in the application, KPDS_VALUE_REGION_SIZE had not been initialized properly.

donna mentioned that data services should have displayed an error message here, to warn me that i was getting values that i had not initialized properly.

Notes :
Keywords :
TB::oname : DATASERV::kdataman


Short Description:
Add compression support
Work-Around :
Severity : 10a- Enhancement request
Priority : 3 - Medium
Reported By : Gareth McAleese g.mcaleese@ulst.ac.uk
Date : 29-Apr-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
One usefull addition to khoros would be supporting data which has been compressed using the standard .Z compression and/or the GNU .gz compress program.
Notes :
Keywords :
TB::oname :


Short Description:
when writing to a directory w/o permissions, it doesn't seem to fail.
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 2 - High
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
when writing to a directory w/o permissions, it doesn't seem to fail.
Notes :
Keywords :
TB::oname : DATASERV::kdataman


Short Description:
BIT_LSB supported as a data type?
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
BIT_LSB supported as a data type?
Notes :
Keywords :
TB::oname : DATASERV::kdataman


Short Description:
When operating on bit images, temporary space is allocated as if you were operating on byte images
Work-Around :
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By : Jeremy Worley
Date : 17-Oct-94
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
When operating on bit images, temporary space is allocated as though operating on byte images (i.e. approx 8 times as much as necessary is allocated).
Notes :
Keywords :
TB::oname : DATASERV::kdataman


Short Description:
Request for attributes to appear in man pages
Work-Around :
Severity : 10a- Enhancement request
Priority :
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
It would be nice if all attributes that are documented in the manual both for data services and gui/viz services could be in the man pages for the set attribute calls. Even more desirable would be an on-line hypertext documentation search tool which would allow easy navigation of allowable attributes.
Notes :
Keywords : documentation, man pages
TB::oname : TOOLBOX::manual