[GRASS5] Re: [GRASSLIST:2833] core dumps after i.rectify

GRASS GRASS developer
1

Hi,

below sound very much like the "i.rectify-doesn't-write-the-file-completely"
bug.

Frank, can you verify that the hard drive *always* provides enough
space? At time i.rectify silently dies if the drive is full.
However, there might be other bugs in certain cases...

Markus

On Sat, Dec 29, 2001 at 06:34:33PM +0100, grass@gevaerts.be wrote:

Hi,

I am using Grass 5.0pre2 on a linux system (debian unstable , kernel
2.4.16, gcc 2.95.4)

After importing an image with r.in.tiff and rectifying it with i.rectify
(after doing all intermediate steps), every tool I tried coredumps on the
resulting raster (d.rast,r.support,r.compress,nviz,...)
The backtrace is :

(gdb) bt
#0 0x400c3c3b in free () from /lib/libc.so.6
#1 0x400c3ac3 in free () from /lib/libc.so.6
#2 0x08050a9b in close_old (fd=6) at closecell.c:76
#3 0x080508d6 in G_close_cell (fd=6) at closecell.c:44
#4 0x0804a595 in cell_draw (name=0x809a8d8 "meren",
    mapset=0x809aa28 "PERMANENT", colors=0xbffff8f8, overlay=0, invert=0,
    data_type=0) at display.c:134
#5 0x0804a34d in display (name=0x809a8d8 "meren",
    mapset=0x809aa28 "PERMANENT", overlay=0, bg=0x0, data_type=0,
invert=0)
    at display.c:59
#6 0x08049ba1 in main (argc=2, argv=0xbffffb74) at main.c:110
#7 0x4006e65f in __libc_start_main () from /lib/libc.so.6

(for d.rast, the others are identical from G_close_cell up, except that
nviz crashes on line 75 in closecell.c)

line 75 is : free (FCB.row_ptr);
line 76 is : free (FCB.col_map);

FCB seems to be :

(gdb) print G__.fileinfo[fd]
$1 = {open_mode = 1, cellhd = {format = 0, compressed = 1, rows = 2680,
    cols = 1558, proj = 3, zone = 0, ew_res = 0.0083333333333333367,
    ns_res = 0.0083320377567371474, north = 1.9559478066666667,
    south = -20.373913381388888, east = 36.412333333333336,
    west = 23.428999999999998}, reclass = {name = '\000' <repeats 49
times>,
    mapset = '\000' <repeats 49 times>, type = 0, num = 0, min = 0, max =
0,
    table = 0x0}, statf = {node = 0x0, tlen = 0, N = 0, curp = 0,
    null_data_count = 0, curoffset = 0}, range = {min = 0, max = 0,
    first_time = 0}, fp_range = {min = 0, max = 0, first_time = 0},
  compression_bits = 0, want_histogram = 0, reclass_flag = 0,
  row_ptr = 0x8093850, col_map = 0x8096238, C1 = 1, C2 = 0.5, cur_row =2679,
  null_cur_row = -1, cur_nbytes = 1, data = 0x8097a98 "", nbytes = 1,
  map_type = 0, temp_name = 0x0, null_temp_name = 0x0, null_file_exists =
1,
  name = 0x808da68 "meren", mapset = 0x808da78 "PERMANENT", io_error = 0,
  xdrstream = {x_op = XDR_ENCODE, x_ops = 0x0, x_public = 0x0,
    x_private = 0x0, x_base = 0x0, x_handy = 0}, NULL_ROWS = {
    0x8093148 "HÍ\032@HÍ\032@", 'ÿ' <repeats 184 times>, "È",
    0x8093210 'ÿ' <repeats 192 times>, "\220\001",
    0x80932d8 'ÿ' <repeats 192 times>, "X\002",
    0x80933a0 'ÿ' <repeats 192 times>, " \003",
    0x8093468 'ÿ' <repeats 192 times>, "è\003",
    0x8093530 'ÿ' <repeats 192 times>, "°\004",
    0x80935f8 'ÿ' <repeats 192 times>, "x\005",
  null_work_buf = 0x8093788 'ÿ' <repeats 192 times>, "\b\a",
  min_null_row = 2672, quant = {truncate_only = 0, round_only = 0,
    defaultDRuleSet = 0, defaultCRuleSet = 0, infiniteLeftSet = 0,
    infiniteRightSet = 0, cRangeSet = 0, maxNofRules = 0, nofRules = 0,
    defaultDMin = 0, defaultDMax = 0, defaultCMin = 0, defaultCMax = 0,
    infiniteDLeft = 0, infiniteDRight = 0, infiniteCLeft = 0,
    infiniteCRight = 0, dMin = 0, dMax = 0, cMin = 0, cMax = 0, table =
0x0,
    fp_lookup = {vals = 0x0, rules = 0x0, nalloc = 0, active = 0,
      inf_dmin = 0, inf_dmax = 0, inf_min = 0, inf_max = 0}}}

Is this a known problem, or am I doing something wrong ?
Please ask if you need more info

Frank

HI! I'm a .signature virus! cp me into your .signature file to help me spread!

2

On Sun, 30 Dec 2001, Markus Neteler wrote:

Hi,

below sound very much like the "i.rectify-doesn't-write-the-file-completely"
bug.

Frank, can you verify that the hard drive *always* provides enough
space? At time i.rectify silently dies if the drive is full.

I checked that. There always is more than 400 MB free.
One more point : after trying to decompress the file, one of the leftover
temp files has (rowsxcolumns) size, so if this file is written out
linearly as it is decompressed , the compressed file can't be much too
short. Also, d.rast crashes after it seems to have finished (the display
looks correct)

Frank

However, there might be other bugs in certain cases...

Markus

On Sat, Dec 29, 2001 at 06:34:33PM +0100, grass@gevaerts.be wrote:
> Hi,
>
> I am using Grass 5.0pre2 on a linux system (debian unstable , kernel
> 2.4.16, gcc 2.95.4)
>
> After importing an image with r.in.tiff and rectifying it with i.rectify
> (after doing all intermediate steps), every tool I tried coredumps on the
> resulting raster (d.rast,r.support,r.compress,nviz,...)
> The backtrace is :
>
> (gdb) bt
> #0 0x400c3c3b in free () from /lib/libc.so.6
> #1 0x400c3ac3 in free () from /lib/libc.so.6
> #2 0x08050a9b in close_old (fd=6) at closecell.c:76
> #3 0x080508d6 in G_close_cell (fd=6) at closecell.c:44
> #4 0x0804a595 in cell_draw (name=0x809a8d8 "meren",
> mapset=0x809aa28 "PERMANENT", colors=0xbffff8f8, overlay=0, invert=0,
> data_type=0) at display.c:134
> #5 0x0804a34d in display (name=0x809a8d8 "meren",
> mapset=0x809aa28 "PERMANENT", overlay=0, bg=0x0, data_type=0,
> invert=0)
> at display.c:59
> #6 0x08049ba1 in main (argc=2, argv=0xbffffb74) at main.c:110
> #7 0x4006e65f in __libc_start_main () from /lib/libc.so.6
>
> (for d.rast, the others are identical from G_close_cell up, except that
> nviz crashes on line 75 in closecell.c)
>
> line 75 is : free (FCB.row_ptr);
> line 76 is : free (FCB.col_map);
>
> FCB seems to be :
>
> (gdb) print G__.fileinfo[fd]
> $1 = {open_mode = 1, cellhd = {format = 0, compressed = 1, rows = 2680,
> cols = 1558, proj = 3, zone = 0, ew_res = 0.0083333333333333367,
> ns_res = 0.0083320377567371474, north = 1.9559478066666667,
> south = -20.373913381388888, east = 36.412333333333336,
> west = 23.428999999999998}, reclass = {name = '\000' <repeats 49
> times>,
> mapset = '\000' <repeats 49 times>, type = 0, num = 0, min = 0, max =
> 0,
> table = 0x0}, statf = {node = 0x0, tlen = 0, N = 0, curp = 0,
> null_data_count = 0, curoffset = 0}, range = {min = 0, max = 0,
> first_time = 0}, fp_range = {min = 0, max = 0, first_time = 0},
> compression_bits = 0, want_histogram = 0, reclass_flag = 0,
> row_ptr = 0x8093850, col_map = 0x8096238, C1 = 1, C2 = 0.5, cur_row =2679,
> null_cur_row = -1, cur_nbytes = 1, data = 0x8097a98 "", nbytes = 1,
> map_type = 0, temp_name = 0x0, null_temp_name = 0x0, null_file_exists =
> 1,
> name = 0x808da68 "meren", mapset = 0x808da78 "PERMANENT", io_error = 0,
> xdrstream = {x_op = XDR_ENCODE, x_ops = 0x0, x_public = 0x0,
> x_private = 0x0, x_base = 0x0, x_handy = 0}, NULL_ROWS = {
> 0x8093148 "HÍ\032@HÍ\032@", 'ÿ' <repeats 184 times>, "È",
> 0x8093210 'ÿ' <repeats 192 times>, "\220\001",
> 0x80932d8 'ÿ' <repeats 192 times>, "X\002",
> 0x80933a0 'ÿ' <repeats 192 times>, " \003",
> 0x8093468 'ÿ' <repeats 192 times>, "è\003",
> 0x8093530 'ÿ' <repeats 192 times>, "°\004",
> 0x80935f8 'ÿ' <repeats 192 times>, "x\005",
> null_work_buf = 0x8093788 'ÿ' <repeats 192 times>, "\b\a",
> min_null_row = 2672, quant = {truncate_only = 0, round_only = 0,
> defaultDRuleSet = 0, defaultCRuleSet = 0, infiniteLeftSet = 0,
> infiniteRightSet = 0, cRangeSet = 0, maxNofRules = 0, nofRules = 0,
> defaultDMin = 0, defaultDMax = 0, defaultCMin = 0, defaultCMax = 0,
> infiniteDLeft = 0, infiniteDRight = 0, infiniteCLeft = 0,
> infiniteCRight = 0, dMin = 0, dMax = 0, cMin = 0, cMax = 0, table =
> 0x0,
> fp_lookup = {vals = 0x0, rules = 0x0, nalloc = 0, active = 0,
> inf_dmin = 0, inf_dmax = 0, inf_min = 0, inf_max = 0}}}
>
>
> Is this a known problem, or am I doing something wrong ?
> Please ask if you need more info
>
> Frank
>
> HI! I'm a .signature virus! cp me into your .signature file to help me spread!

HI! I'm a .signature virus! cp me into your .signature file to help me spread!

3

On Sun, 30 Dec 2001, Markus Neteler wrote:

Hi,

below sound very much like the "i.rectify-doesn't-write-the-file-completely"
bug.

Frank, can you verify that the hard drive *always* provides enough
space? At time i.rectify silently dies if the drive is full.
However, there might be other bugs in certain cases...

I think I found it.
The cellhd file for the rectified image was :
proj: 3
zone: 0
north: 1:57:21.412104N
south: 20:22:26.088173S
east: 36:24:44.4E
west: 23:25:44.4E
cols: 1558
rows: 2680
e-w resol: 0:00:30
n-s resol: 0:00:29.995336
format: 0
compressed: 1

After I changed 'format' from 0 to 1 everything seems to wrok fine. So
i.rectify apparently sets this wrong (at least in some cases).

Markus

On Sat, Dec 29, 2001 at 06:34:33PM +0100, grass@gevaerts.be wrote:
> Hi,
>
> I am using Grass 5.0pre2 on a linux system (debian unstable , kernel
> 2.4.16, gcc 2.95.4)
>
> After importing an image with r.in.tiff and rectifying it with i.rectify
> (after doing all intermediate steps), every tool I tried coredumps on the
> resulting raster (d.rast,r.support,r.compress,nviz,...)
> The backtrace is :
>
> (gdb) bt
> #0 0x400c3c3b in free () from /lib/libc.so.6
> #1 0x400c3ac3 in free () from /lib/libc.so.6
> #2 0x08050a9b in close_old (fd=6) at closecell.c:76
> #3 0x080508d6 in G_close_cell (fd=6) at closecell.c:44
> #4 0x0804a595 in cell_draw (name=0x809a8d8 "meren",
> mapset=0x809aa28 "PERMANENT", colors=0xbffff8f8, overlay=0, invert=0,
> data_type=0) at display.c:134
> #5 0x0804a34d in display (name=0x809a8d8 "meren",
> mapset=0x809aa28 "PERMANENT", overlay=0, bg=0x0, data_type=0,
> invert=0)
> at display.c:59
> #6 0x08049ba1 in main (argc=2, argv=0xbffffb74) at main.c:110
> #7 0x4006e65f in __libc_start_main () from /lib/libc.so.6
>
> (for d.rast, the others are identical from G_close_cell up, except that
> nviz crashes on line 75 in closecell.c)
>
> line 75 is : free (FCB.row_ptr);
> line 76 is : free (FCB.col_map);
>
> FCB seems to be :
>
> (gdb) print G__.fileinfo[fd]
> $1 = {open_mode = 1, cellhd = {format = 0, compressed = 1, rows = 2680,
> cols = 1558, proj = 3, zone = 0, ew_res = 0.0083333333333333367,
> ns_res = 0.0083320377567371474, north = 1.9559478066666667,
> south = -20.373913381388888, east = 36.412333333333336,
> west = 23.428999999999998}, reclass = {name = '\000' <repeats 49
> times>,
> mapset = '\000' <repeats 49 times>, type = 0, num = 0, min = 0, max =
> 0,
> table = 0x0}, statf = {node = 0x0, tlen = 0, N = 0, curp = 0,
> null_data_count = 0, curoffset = 0}, range = {min = 0, max = 0,
> first_time = 0}, fp_range = {min = 0, max = 0, first_time = 0},
> compression_bits = 0, want_histogram = 0, reclass_flag = 0,
> row_ptr = 0x8093850, col_map = 0x8096238, C1 = 1, C2 = 0.5, cur_row =2679,
> null_cur_row = -1, cur_nbytes = 1, data = 0x8097a98 "", nbytes = 1,
> map_type = 0, temp_name = 0x0, null_temp_name = 0x0, null_file_exists =
> 1,
> name = 0x808da68 "meren", mapset = 0x808da78 "PERMANENT", io_error = 0,
> xdrstream = {x_op = XDR_ENCODE, x_ops = 0x0, x_public = 0x0,
> x_private = 0x0, x_base = 0x0, x_handy = 0}, NULL_ROWS = {
> 0x8093148 "HÍ\032@HÍ\032@", 'ÿ' <repeats 184 times>, "È",
> 0x8093210 'ÿ' <repeats 192 times>, "\220\001",
> 0x80932d8 'ÿ' <repeats 192 times>, "X\002",
> 0x80933a0 'ÿ' <repeats 192 times>, " \003",
> 0x8093468 'ÿ' <repeats 192 times>, "è\003",
> 0x8093530 'ÿ' <repeats 192 times>, "°\004",
> 0x80935f8 'ÿ' <repeats 192 times>, "x\005",
> null_work_buf = 0x8093788 'ÿ' <repeats 192 times>, "\b\a",
> min_null_row = 2672, quant = {truncate_only = 0, round_only = 0,
> defaultDRuleSet = 0, defaultCRuleSet = 0, infiniteLeftSet = 0,
> infiniteRightSet = 0, cRangeSet = 0, maxNofRules = 0, nofRules = 0,
> defaultDMin = 0, defaultDMax = 0, defaultCMin = 0, defaultCMax = 0,
> infiniteDLeft = 0, infiniteDRight = 0, infiniteCLeft = 0,
> infiniteCRight = 0, dMin = 0, dMax = 0, cMin = 0, cMax = 0, table =
> 0x0,
> fp_lookup = {vals = 0x0, rules = 0x0, nalloc = 0, active = 0,
> inf_dmin = 0, inf_dmax = 0, inf_min = 0, inf_max = 0}}}
>
>
> Is this a known problem, or am I doing something wrong ?
> Please ask if you need more info
>
> Frank
>
> HI! I'm a .signature virus! cp me into your .signature file to help me spread!

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

HI! I'm a .signature virus! cp me into your .signature file to help me spread!

4

On Mon, Dec 31, 2001 at 11:04:50AM +0100, grass@gevaerts.be wrote:

On Sun, 30 Dec 2001, Markus Neteler wrote:

> Hi,
>
> below sound very much like the "i.rectify-doesn't-write-the-file-completely"
> bug.
>
> Frank, can you verify that the hard drive *always* provides enough
> space? At time i.rectify silently dies if the drive is full.
> However, there might be other bugs in certain cases...

I think I found it.
The cellhd file for the rectified image was :
proj: 3
zone: 0
north: 1:57:21.412104N
south: 20:22:26.088173S
east: 36:24:44.4E
west: 23:25:44.4E
cols: 1558
rows: 2680
e-w resol: 0:00:30
n-s resol: 0:00:29.995336
format: 0
compressed: 1

After I changed 'format' from 0 to 1 everything seems to wrok fine. So
i.rectify apparently sets this wrong (at least in some cases).

Wow - excellent. Now we have to identify the problem in i.rectify.
A candidate is
src/imagery/i.rectify2/rectify.c
[...]
   G_set_cell_format (cellhd.format);
  
Mhhh, why is this function needed here?

Happy new year to everybody!

Markus

>
> Markus
>
>
> On Sat, Dec 29, 2001 at 06:34:33PM +0100, grass@gevaerts.be wrote:
> > Hi,
> >
> > I am using Grass 5.0pre2 on a linux system (debian unstable , kernel
> > 2.4.16, gcc 2.95.4)
> >
> > After importing an image with r.in.tiff and rectifying it with i.rectify
> > (after doing all intermediate steps), every tool I tried coredumps on the
> > resulting raster (d.rast,r.support,r.compress,nviz,...)
> > The backtrace is :
> >
> > (gdb) bt
> > #0 0x400c3c3b in free () from /lib/libc.so.6
> > #1 0x400c3ac3 in free () from /lib/libc.so.6
> > #2 0x08050a9b in close_old (fd=6) at closecell.c:76
> > #3 0x080508d6 in G_close_cell (fd=6) at closecell.c:44
> > #4 0x0804a595 in cell_draw (name=0x809a8d8 "meren",
> > mapset=0x809aa28 "PERMANENT", colors=0xbffff8f8, overlay=0, invert=0,
> > data_type=0) at display.c:134
> > #5 0x0804a34d in display (name=0x809a8d8 "meren",
> > mapset=0x809aa28 "PERMANENT", overlay=0, bg=0x0, data_type=0,
> > invert=0)
> > at display.c:59
> > #6 0x08049ba1 in main (argc=2, argv=0xbffffb74) at main.c:110
> > #7 0x4006e65f in __libc_start_main () from /lib/libc.so.6
> >
> > (for d.rast, the others are identical from G_close_cell up, except that
> > nviz crashes on line 75 in closecell.c)
> >
> > line 75 is : free (FCB.row_ptr);
> > line 76 is : free (FCB.col_map);
> >
> > FCB seems to be :
> >
> > (gdb) print G__.fileinfo[fd]
> > $1 = {open_mode = 1, cellhd = {format = 0, compressed = 1, rows = 2680,
> > cols = 1558, proj = 3, zone = 0, ew_res = 0.0083333333333333367,
> > ns_res = 0.0083320377567371474, north = 1.9559478066666667,
> > south = -20.373913381388888, east = 36.412333333333336,
> > west = 23.428999999999998}, reclass = {name = '\000' <repeats 49
> > times>,
> > mapset = '\000' <repeats 49 times>, type = 0, num = 0, min = 0, max =
> > 0,
> > table = 0x0}, statf = {node = 0x0, tlen = 0, N = 0, curp = 0,
> > null_data_count = 0, curoffset = 0}, range = {min = 0, max = 0,
> > first_time = 0}, fp_range = {min = 0, max = 0, first_time = 0},
> > compression_bits = 0, want_histogram = 0, reclass_flag = 0,
> > row_ptr = 0x8093850, col_map = 0x8096238, C1 = 1, C2 = 0.5, cur_row =2679,
> > null_cur_row = -1, cur_nbytes = 1, data = 0x8097a98 "", nbytes = 1,
> > map_type = 0, temp_name = 0x0, null_temp_name = 0x0, null_file_exists =
> > 1,
> > name = 0x808da68 "meren", mapset = 0x808da78 "PERMANENT", io_error = 0,
> > xdrstream = {x_op = XDR_ENCODE, x_ops = 0x0, x_public = 0x0,
> > x_private = 0x0, x_base = 0x0, x_handy = 0}, NULL_ROWS = {
> > 0x8093148 "HÍ\032@HÍ\032@", 'ÿ' <repeats 184 times>, "È",
> > 0x8093210 'ÿ' <repeats 192 times>, "\220\001",
> > 0x80932d8 'ÿ' <repeats 192 times>, "X\002",
> > 0x80933a0 'ÿ' <repeats 192 times>, " \003",
> > 0x8093468 'ÿ' <repeats 192 times>, "è\003",
> > 0x8093530 'ÿ' <repeats 192 times>, "°\004",
> > 0x80935f8 'ÿ' <repeats 192 times>, "x\005",
> > null_work_buf = 0x8093788 'ÿ' <repeats 192 times>, "\b\a",
> > min_null_row = 2672, quant = {truncate_only = 0, round_only = 0,
> > defaultDRuleSet = 0, defaultCRuleSet = 0, infiniteLeftSet = 0,
> > infiniteRightSet = 0, cRangeSet = 0, maxNofRules = 0, nofRules = 0,
> > defaultDMin = 0, defaultDMax = 0, defaultCMin = 0, defaultCMax = 0,
> > infiniteDLeft = 0, infiniteDRight = 0, infiniteCLeft = 0,
> > infiniteCRight = 0, dMin = 0, dMax = 0, cMin = 0, cMax = 0, table =
> > 0x0,
> > fp_lookup = {vals = 0x0, rules = 0x0, nalloc = 0, active = 0,
> > inf_dmin = 0, inf_dmax = 0, inf_min = 0, inf_max = 0}}}
> >
> >
> > Is this a known problem, or am I doing something wrong ?
> > Please ask if you need more info
> >
> > Frank
> >
> > HI! I'm a .signature virus! cp me into your .signature file to help me spread!
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>

HI! I'm a .signature virus! cp me into your .signature file to help me spread!

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

On Mon, 31 Dec 2001, Markus Neteler wrote:

On Mon, Dec 31, 2001 at 11:04:50AM +0100, grass@gevaerts.be wrote:
> On Sun, 30 Dec 2001, Markus Neteler wrote:
>
> > Hi,
> >
> > below sound very much like the "i.rectify-doesn't-write-the-file-completely"
> > bug.
> >
> > Frank, can you verify that the hard drive *always* provides enough
> > space? At time i.rectify silently dies if the drive is full.
> > However, there might be other bugs in certain cases...
>
> I think I found it.
> The cellhd file for the rectified image was :
> proj: 3
> zone: 0
> north: 1:57:21.412104N
> south: 20:22:26.088173S
> east: 36:24:44.4E
> west: 23:25:44.4E
> cols: 1558
> rows: 2680
> e-w resol: 0:00:30
> n-s resol: 0:00:29.995336
> format: 0
> compressed: 1
>
> After I changed 'format' from 0 to 1 everything seems to wrok fine. So
> i.rectify apparently sets this wrong (at least in some cases).

Another possibly related problem : if the source raster is not compressed,
the rectified raster is compressed, but marked as not compressed.

Frank

Wow - excellent. Now we have to identify the problem in i.rectify.
A candidate is
src/imagery/i.rectify2/rectify.c
[...]
   G_set_cell_format (cellhd.format);
  
Mhhh, why is this function needed here?

Happy new year to everybody!

Markus

HI! I'm a .signature virus! cp me into your .signature file to help me spread!

6

Markus Neteler wrote:

> After I changed 'format' from 0 to 1 everything seems to wrok fine. So
> i.rectify apparently sets this wrong (at least in some cases).

Wow - excellent. Now we have to identify the problem in i.rectify.
A candidate is
src/imagery/i.rectify2/rectify.c
[...]
   G_set_cell_format (cellhd.format);

grass@gevaerts.be wrote:

> > After I changed 'format' from 0 to 1 everything seems to wrok fine. So
> > i.rectify apparently sets this wrong (at least in some cases).

Another possibly related problem : if the source raster is not compressed,
the rectified raster is compressed, but marked as not compressed.

Both of these problems seem rather odd, as src/libes/gis/closecell.c
does this:

        if ( FCB.map_type != CELL_TYPE)
           FCB.cellhd.format = -1;
        else /* CELL map */
     FCB.cellhd.format = FCB.nbytes - 1;

  FCB.cellhd.compressed = (open_mode == OPEN_NEW_COMPRESSED ? 1 : 0);
/* write header file */
        G_put_cellhd (FCB.name, &FCB.cellhd);

IOW, both the "format" and "compressed" fields which are written to
the "cellhd" file are being set to the values which should have been
used in writing the "cell" file.

Unfortunately, this problem is almost impossible to track down simply
by looking at the source. Cell_head structures are used and modified
in far too many places, both in libgis and i.rectify, to keep track
of. Someone will need to trace through i.rectify with a debugger,
observing all of the changes to the format/compressed fields in all of
the Cell_head structures.

PS: this would probably be easier if the G_fork() stuff was removed.

--
Glynn Clements <glynn.clements@virgin.net>

7

On Tue, 1 Jan 2002 05:10:08 +0000, Glynn Clements <glynn.clements@virgin.net> wrote:

Markus Neteler wrote:

> > After I changed 'format' from 0 to 1 everything seems to wrok fine. So
> > i.rectify apparently sets this wrong (at least in some cases).
>
> Wow - excellent. Now we have to identify the problem in i.rectify.
> A candidate is
> src/imagery/i.rectify2/rectify.c
> [...]
> G_set_cell_format (cellhd.format);

grass@gevaerts.be wrote:

> > > After I changed 'format' from 0 to 1 everything seems to wrok fine. So
> > > i.rectify apparently sets this wrong (at least in some cases).
>
> Another possibly related problem : if the source raster is not compressed,
> the rectified raster is compressed, but marked as not compressed.

Both of these problems seem rather odd, as src/libes/gis/closecell.c
does this:

        if ( FCB.map_type != CELL_TYPE)
           FCB.cellhd.format = -1;
        else /* CELL map */
     FCB.cellhd.format = FCB.nbytes - 1;

  FCB.cellhd.compressed = (open_mode == OPEN_NEW_COMPRESSED ? 1 : 0);
/* write header file */
        G_put_cellhd (FCB.name, &FCB.cellhd);

IOW, both the "format" and "compressed" fields which are written to
the "cellhd" file are being set to the values which should have been
used in writing the "cell" file.

Unfortunately, this problem is almost impossible to track down simply
by looking at the source. Cell_head structures are used and modified
in far too many places, both in libgis and i.rectify, to keep track
of. Someone will need to trace through i.rectify with a debugger,
observing all of the changes to the format/compressed fields in all of
the Cell_head structures.

PS: this would probably be easier if the G_fork() stuff was removed.

Alright, the problem seems to be that in "exec.c", G_put_cellhd() is
called after the raster has been written. I think it is entirely
unnecessary (and obviously screws up some critical info). I created
an integer test file (floats didn't seem to be affected), and after
commenting the G_put_cellhd() call, the rectified image doesn't
cause a segfault. Would others care to try... ?

It's around, line 75 or so...
        
        ...
        if (rectify (name, mapset, result,order))
        {
            select_target_env();
/* G_put_cellhd (result,&target_window); */
            if(cats_ok)
            {
        ...

--
Eric G. Miller <egm2@jps.net>

8

On Tue, 1 Jan 2002, Eric G. Miller wrote:

<clipped>

Alright, the problem seems to be that in "exec.c", G_put_cellhd() is
called after the raster has been written. I think it is entirely
unnecessary (and obviously screws up some critical info). I created
an integer test file (floats didn't seem to be affected), and after
commenting the G_put_cellhd() call, the rectified image doesn't
cause a segfault. Would others care to try... ?

It seems to work here

Frank

It's around, line 75 or so...
        
        ...
        if (rectify (name, mapset, result,order))
        {
            select_target_env();
/* G_put_cellhd (result,&target_window); */
            if(cats_ok)
            {
        ...

--
Eric G. Miller <egm2@jps.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

HI! I'm a .signature virus! cp me into your .signature file to help me spread!