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