Hi,
the NVIZ image dump to TIFF no longer works for me.
The result image is replicated inside the output
file and basically useless.
If I recall correctly, someone modified this recently
(Hamish?).
Markus
the NVIZ image dump to TIFF no longer works for me.
The result image is replicated inside the output
file and basically useless.
It works fine for me.
I seem to remember this same problem was reported to the mailing list
just a few days/week ago. You are using 64bit, correct? I've got a
feeling that previous report was 64bit too.
The htdig search engine is broken currently (even a search for "grass"
gives 0 hits), and I can't connect to Gmane - so sorry no link.
Did it work with yesterday's CVS? (lib/ogsf/gs_bm.c change)
If I recall correctly, someone modified this recently
(Hamish?).
Mine was just to change a G_fatal_error() to G_warning(), and to guard
against unwanted ".tif.tif" output file extensions. Nothing to do with
rendering (you'll have to ask Bob about that).
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/ogsf/gsd_img_tif.c
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/ogsf/?sortby=date#dirlist
Hamish
On Wed, May 03, 2006 at 06:34:53PM +1200, Hamish wrote:
> the NVIZ image dump to TIFF no longer works for me.
> The result image is replicated inside the output
> file and basically useless.It works fine for me.
I seem to remember this same problem was reported to the mailing list
just a few days/week ago. You are using 64bit, correct? I've got a
feeling that previous report was 64bit too.
Right. I am using 64bit.
The htdig search engine is broken currently (even a search for "grass"
gives 0 hits), and I can't connect to Gmane - so sorry no link.
No, it's Wednesday monring in Italy and the htdig job is running.
This takes a few hours on the old 500 MHz server... It will be
back in 2 hours from now, I guess. The new server should be way
faster and I can schedule it to mid Pacific Ocean daytime or so.
Did it work with yesterday's CVS? (lib/ogsf/gs_bm.c change)
Yes, I did.
> If I recall correctly, someone modified this recently
> (Hamish?).Mine was just to change a G_fatal_error() to G_warning(), and to guard
against unwanted ".tif.tif" output file extensions. Nothing to do with
rendering (you'll have to ask Bob about that).http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/ogsf/gsd_img_tif.c
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/ogsf/?sortby=date#dirlist
OK, I will try harder. But if you manage to find the mails,
I would be grateful.
thanks
Markus
> > the NVIZ image dump to TIFF no longer works for me.
> > The result image is replicated inside the output
> > file and basically useless.
..
> I seem to remember this same problem was reported to the mailing list
> just a few days/week ago. You are using 64bit, correct? I've got a
> feeling that previous report was 64bit too.Right. I am using 64bit.
ht/dig is back online; gmane is still down-
here's the thread:
http://grass.itc.it/pipermail/grassuser/2006-April/033819.html
Hamish
On Wed, May 03, 2006 at 10:14:09PM +1200, Hamish wrote:
> > > the NVIZ image dump to TIFF no longer works for me.
> > > The result image is replicated inside the output
> > > file and basically useless.
..
> > I seem to remember this same problem was reported to the mailing list
> > just a few days/week ago. You are using 64bit, correct? I've got a
> > feeling that previous report was 64bit too.
>
> Right. I am using 64bit.ht/dig is back online; gmane is still down-
here's the thread:
http://grass.itc.it/pipermail/grassuser/2006-April/033819.html
This is exactly my problem!
Where should I look for that?
Markus
Markus,
I took a look at the thread below and it appears that the image is being
read incorrectly on 64 bit machines. The image buffer is created from
gsd_getimage in gsd_prim.c in ogsf. Unfortunately, I am not an expert on
64 bit machines, but I would guess that that either the malloc is wrong
or glReadPixels is wrong. Is an "unsigned long" a different size on 64
bit architecture? It appears that the dimension of the image is correct,
but the image buffer is wrong.
On a separate issue, I have found that with the recent NVIZ I get a
segfault if I try to load a saved state or save a state if I have a
vector/site file loaded. I assume this is due to the recent changes to
the Sites panel, but I have not had time to investigate. If you can
confirm, it should be added to the bugtracker.
--
Bob
On Wed, 2006-05-03 at 12:18 +0200, Markus Neteler wrote:
On Wed, May 03, 2006 at 10:14:09PM +1200, Hamish wrote:
> > > > the NVIZ image dump to TIFF no longer works for me.
> > > > The result image is replicated inside the output
> > > > file and basically useless.
> ..
> > > I seem to remember this same problem was reported to the mailing list
> > > just a few days/week ago. You are using 64bit, correct? I've got a
> > > feeling that previous report was 64bit too.
> >
> > Right. I am using 64bit.
>
> ht/dig is back online; gmane is still down-
>
> here's the thread:
> http://grass.itc.it/pipermail/grassuser/2006-April/033819.htmlThis is exactly my problem!
Where should I look for that?
Markus
On a separate issue, I have found that with the recent NVIZ I get a
segfault if I try to load a saved state or save a state if I have a
vector/site file loaded. I assume this is due to the recent changes to
the Sites panel, but I have not had time to investigate. If you can
confirm, it should be added to the bugtracker.
Same here,
spearfish60:
nviz -q
Panel -> Vector points
New
bugsites
File -> Save State
filename
<ok>
segfault.
It happens in panel_site.c, proc Nviz_site_save (line 176),
on this call:
# useatt
puts $file_hook "[Nsite$i get_att useatt]"
which takes us to get_att() in src/map_obj.c line 1516.
then in
case SITE:{
case SV_ATT_USEATT:
it tries atoi(argv[3]) but there is no 4th arguement to convert:
argc=3
argv[0]=[Nsite21720]
argv[1]=[get_att]
argv[2]=[useatt]
argv[3]=[(null)]
The atoi() is trying to fetch the attribute number for this:
int site_attr_get(Tcl_Interp *interp, geosite * gp, int nattr)
{
char buf[1024];
sprintf(buf, "%d", gp->use_attr[nattr]);
Tcl_AppendElement(interp, buf);
return(TCL_OK);
}
If I change argv[3] to argv[2] it gets rid of the segfault, but I don't
know if that is the intended logic.
Hamish
Bob Covill wrote:
I took a look at the thread below and it appears that the image is being
read incorrectly on 64 bit machines. The image buffer is created from
gsd_getimage in gsd_prim.c in ogsf. Unfortunately, I am not an expert on
64 bit machines, but I would guess that that either the malloc is wrong
or glReadPixels is wrong. Is an "unsigned long" a different size on 64
bit architecture?
Very probably; I would expect long to be 64 bits on a 64-bit system.
If you need a 32-bit type, either use uint32_t from <stdint.h> (C99,
but present on most systems) or use AC_CHECK_SIZEOF in configure.in.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, May 03, 2006 at 09:40:42PM +0100, Glynn Clements wrote:
Bob Covill wrote:
> I took a look at the thread below and it appears that the image is being
> read incorrectly on 64 bit machines. The image buffer is created from
> gsd_getimage in gsd_prim.c in ogsf. Unfortunately, I am not an expert on
> 64 bit machines, but I would guess that that either the malloc is wrong
> or glReadPixels is wrong. Is an "unsigned long" a different size on 64
> bit architecture?Very probably; I would expect long to be 64 bits on a 64-bit system.
If you need a 32-bit type, either use uint32_t from <stdint.h> (C99,
but present on most systems) or use AC_CHECK_SIZEOF in configure.in.
GDAL contains such tests:
dnl Check for 64 bit file API
AC_HAVE_LONG_LONG
AC_UNIX_STDIO_64
AC_CHECK_SIZEOF(int)
AC_CHECK_SIZEOF(long)
But I didn't check in detail.
Markus