Hi,
I would like to ask if a developer is willing to update r.in.gdal
(Frank Warmerdam told me that he won't do that at time):
Outstanding
- fix the grey color tables issue for RGB maps
- fix the compression issue
As I am not fully sure where to apply that (and how for the
second case), I prefer to ask first.
Thanks in advance,
Markus
Markus Neteler wrote:
I would like to ask if a developer is willing to update r.in.gdal
(Frank Warmerdam told me that he won't do that at time):Outstanding
- fix the grey color tables issue for RGB maps
The main problem here is determining the overall range of the data,
i.e. which values correspond to black and white. Black is almost
certain to be 0, but determining white is more difficult. Usually it's
((1<<bit_depth)-1), but you need to know what bit_depth is.
Once that's been determined, generating the colour table is trivial.
NB: this is why d.rgb, r.composite etc need the grey-scale colour
tables; so that they can translate a cell value to an intensity.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
Markus Neteler wrote:
I would like to ask if a developer is willing to update r.in.gdal
(Frank Warmerdam told me that he won't do that at time):Outstanding
- fix the grey color tables issue for RGB mapsThe main problem here is determining the overall range of the data,
i.e. which values correspond to black and white. Black is almost
certain to be 0, but determining white is more difficult. Usually it's
((1<<bit_depth)-1), but you need to know what bit_depth is.Once that's been determined, generating the colour table is trivial.
NB: this is why d.rgb, r.composite etc need the grey-scale colour
tables; so that they can translate a cell value to an intensity.
Glynn,
After completing the raster import, the GRASS library will have min/max
information won't it, using the G_get_fp_range_min_max()?
If that isn't practical, the GDALComputeRasterMinMax() function could be
used. In some cases it is optimized to use range info in the source file
void CPL_DLL GDALComputeRasterMinMax( GDALRasterBandH hBand, int bApproxOK,
double adfMinMax[2] );
Later,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
Frank Warmerdam wrote:
> >I would like to ask if a developer is willing to update r.in.gdal
> >(Frank Warmerdam told me that he won't do that at time):
> >
> >Outstanding
> > - fix the grey color tables issue for RGB maps
>
>
> The main problem here is determining the overall range of the data,
> i.e. which values correspond to black and white. Black is almost
> certain to be 0, but determining white is more difficult. Usually it's
> ((1<<bit_depth)-1), but you need to know what bit_depth is.
>
> Once that's been determined, generating the colour table is trivial.
>
> NB: this is why d.rgb, r.composite etc need the grey-scale colour
> tables; so that they can translate a cell value to an intensity.Glynn,
After completing the raster import, the GRASS library will have min/max
information won't it, using the G_get_fp_range_min_max()?
That isn't the right information. What's required are the values which
correspond to 0% and 100% intensity; e.g. for a 24-bpp colour image,
the appropriate values are 0 and 255, regardless of the minimum and
maximum values which occur in the data.
If that isn't practical, the GDALComputeRasterMinMax() function could be
used. In some cases it is optimized to use range info in the source file
I don't know for certain what that function does, but the name leads
me to suspect that it isn't the right tool.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
> I would like to ask if a developer is willing to update r.in.gdal
> (Frank Warmerdam told me that he won't do that at time):
>
> Outstanding
> - fix the grey color tables issue for RGB mapsThe main problem here is determining the overall range of the data,
i.e. which values correspond to black and white. Black is almost
certain to be 0, but determining white is more difficult. Usually it's
((1<<bit_depth)-1), but you need to know what bit_depth is.
The upshot of a private conversation with Frank is that GDAL doesn't
make this information available. Consequently, you would need to use
heuristics to determine the bit depth (and hope that the image isn't
too dark).
--
Glynn Clements <glynn.clements@virgin.net>
I get a lot of errors compiling /lib/forms/form.c on 5.1 on Solaris 8
Sparc. Looks like a missing include file or library. I ran "make mix;
make":
make[2]: Entering directory `/usr3/grass51_030103/lib/form'
gcc -L/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib -o
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/etc/form/form
OBJ.sparc-sun-solaris2.8/form.o
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libdbmi.a
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libgis.a -ltk8.3 -lm
-ltcl8.3 -lm \
-lm -lnsl -lz
OBJ.sparc-sun-solaris2.8/form.o: In function `close_form':
/usr3/grass51_030103/lib/form/form.c:30: undefined reference to `G_debug'
OBJ.sparc-sun-solaris2.8/form.o: In function `set_value':
/usr3/grass51_030103/lib/form/form.c:51: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:54: undefined reference to `G_store'
/usr3/grass51_030103/lib/form/form.c:56: undefined reference to `G_store'
/usr3/grass51_030103/lib/form/form.c:58: undefined reference to `G_store'
/usr3/grass51_030103/lib/form/form.c:60: undefined reference to `G_store'
/usr3/grass51_030103/lib/form/form.c:66: undefined reference to `G_store'
OBJ.sparc-sun-solaris2.8/form.o:/usr3/grass51_030103/lib/form/form.c:67:
more undefined references to `G_store' follow
OBJ.sparc-sun-solaris2.8/form.o: In function `submit':
/usr3/grass51_030103/lib/form/form.c:86: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:94: undefined reference to `G_warning'
/usr3/grass51_030103/lib/form/form.c:102: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:105: undefined reference to
`G_warning'
/usr3/grass51_030103/lib/form/form.c:111: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:115: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:117: undefined reference to
`G_warning'
/usr3/grass51_030103/lib/form/form.c:124: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:128: undefined reference to
`G_warning'
/usr3/grass51_030103/lib/form/form.c:143: undefined reference to
`G_strcasecmp'
/usr3/grass51_030103/lib/form/form.c:147: undefined reference to
`G_strcasecmp'
/usr3/grass51_030103/lib/form/form.c:155: undefined reference to
`G_warning'
/usr3/grass51_030103/lib/form/form.c:171: undefined reference to
`G_strcasecmp'
/usr3/grass51_030103/lib/form/form.c:187: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:196: undefined reference to
`G_warning'
OBJ.sparc-sun-solaris2.8/form.o: In function `main':
/usr3/grass51_030103/lib/form/form.c:221: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:231: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:234: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:237: undefined reference to
`G_fatal_error'
/usr3/grass51_030103/lib/form/form.c:239: undefined reference to
`G_fatal_error'
/usr3/grass51_030103/lib/form/form.c:251: undefined reference to
`G_gisbase'
/usr3/grass51_030103/lib/form/form.c:254: undefined reference to
`G_fatal_error'
/usr3/grass51_030103/lib/form/form.c:255: undefined reference to
`G_fatal_error'
/usr3/grass51_030103/lib/form/form.c:261: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:265: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:273: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:277: undefined reference to `G_debug'
/usr3/grass51_030103/lib/form/form.c:287: undefined reference to `G_debug'
OBJ.sparc-sun-solaris2.8/form.o:/usr3/grass51_030103/lib/form/form.c:299:
more undefined references to `G_debug' follow
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libdbmi.a(column.o): In
function `db_get_column':
/usr3/grass51_030103/lib/db/dbmi/column.c:561: undefined reference to
`G_warning'
/usr3/grass51_030103/lib/db/dbmi/column.c:568: undefined reference to
`G_debug'
/usr3/grass51_030103/lib/db/dbmi/column.c:572: undefined reference to
`G_strcasecmp'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libdbmi.a(table.o): In
function `db_table_exists':
/usr3/grass51_030103/lib/db/dbmi/table.c:357: undefined reference to
`G_warning'
/usr3/grass51_030103/lib/db/dbmi/table.c:365: undefined reference to
`G_strcasecmp'
/usr3/grass51_030103/lib/db/dbmi/table.c:376: undefined reference to
`G_strcasecmp'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libdbmi.a(connect.o): In
function `db_set_connection':
/usr3/grass51_030103/lib/db/dbmi/connect.c:15: undefined reference to
`G_setenv2'
/usr3/grass51_030103/lib/db/dbmi/connect.c:18: undefined reference to
`G_setenv2'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libdbmi.a(connect.o): In
function `db_get_connection':
/usr3/grass51_030103/lib/db/dbmi/connect.c:47: undefined reference to
`G__getenv2'
/usr3/grass51_030103/lib/db/dbmi/connect.c:48: undefined reference to
`G__getenv2'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libdbmi.a(db.o): In
function `db_start_driver_open_database':
/usr3/grass51_030103/lib/db/dbmi/db.c:16: undefined reference to `G_debug'
/usr3/grass51_030103/lib/db/dbmi/db.c:22: undefined reference to
`G_warning'
/usr3/grass51_030103/lib/db/dbmi/db.c:27: undefined reference to
`G_warning'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libdbmi.a(dbmscap.o): In
function `db_read_dbmscap':
/usr3/grass51_030103/lib/db/dbmi/dbmscap.c:156: undefined reference to
`G_gisbase'
/usr3/grass51_030103/lib/db/dbmi/dbmscap.c:170: undefined reference to
`G_gisbase'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libgis.a(alloc.o): In
function `G_malloc':
/usr3/grass51_030103/lib/gis/alloc.c:64: undefined reference to
`G_fatal_error'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libgis.a(alloc.o): In
function `G_calloc':
/usr3/grass51_030103/lib/gis/alloc.c:78: undefined reference to
`G_fatal_error'
/usr3/grass51_030103/dist.sparc-sun-solaris2.8/lib/libgis.a(alloc.o): In
function `G_realloc':
/usr3/grass51_030103/lib/gis/alloc.c:91: undefined reference to
`G_fatal_error'
collect2: ld returned 1 exit status
make[2]: *** [/usr3/grass51_030103/dist.sparc-sun-solaris2.8/etc/form/form]
Error 1
make[2]: Leaving directory `/usr3/grass51_030103/lib/form'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr3/grass51_030103/lib'
make: *** [default] Error 1
My mistake, I was using out of date 5.0 code in the build.
I cannot compile "/visualization/nviz/src/getCat.c" due to a non-existant
include file "pg.h" that is needed. If I comment out the #include line, I
get many undefined variable errors, etc. I cant find any files by that name
in the source for 5.0.1 or 5.1, or in the postgresql source files.
Before I found this, there were several other build issues. I have fixed up
many of them by direct editing of makefiles because I don't know anything
about how configure and make really work. I hope someone can translate them
into real fixes
Other fixups:
Had to add "-lresolv" to XEXTRALIBS in Platform.make to support
"inet_aton" in several .c files.
The variable PQLIB is set equal to "-lpq" in
/include/Make/Platform.make. This does not work wit the way the variable is
used in the Makefiles. I edited "/include/Make/Grass.make" to replace
$(PQLIB) with the absolute path to the library
("/usr/local/pgsql/lib/libpq.a" in my case) in the "VECTLIB=" definition.
That fixed the "-lpq not found" error in many makefiles.
Solaris did not accept the syntax "@test -e". I replaced it with
"@test -r" in:
/include/Make/Module.make
/db/base/Makefile
/general/manage/cmd/Makefile
/lib/init/init.sh
/scripts/postgisdb
To get -lsocket and -lresolve in the necessary places, I had to add
$(XEXTRALIBS) to LIBES in the Makefile for:
/display/d.erase
/display/d.vect
/display/d.rast
/display/d.what.vect
/display/d.what.rast
/display/d.mon/pgms
/display/d.path
/display/d.zoom
/general/g.region/cmd
/general/manage/cmd
/vector/v.ascii
/vector/v.build
/vector/v.build.polylines
/vector/v.clean
/vector/v.clean/test
/vector/v.convert
/vector/v.database
/vector/v.db.connect
/vector/v.digit
/vector/v.extract
/vector/v.in.sites
/vector/v.info
/vector/v.net.alloc
/vector/v.net.iso
/vector/v.patch
/vector/v.surf.rst
/vector/v.to.rast
/vector/v.transform
cheg01@attbi.com wrote:
Before I found this, there were several other build issues. I have fixed up
many of them by direct editing of makefiles because I don't know anything
about how configure and make really work. I hope someone can translate them
into real fixesOther fixups:
Had to add "-lresolv" to XEXTRALIBS in Platform.make to support
"inet_aton" in several .c files.
1. That *shouldn't* work. XEXTRALIBS is only meant to be used by
programs which use X11 (i.e. XDRIVER, NVIZ, maybe a couple of other
programs).
2. This problem is equally applicable to 5.0. If any module uses
inet_aton(), the configure script should check for it, and the
module's Makefile should have an appropriate library dependency.
The variable PQLIB is set equal to "-lpq" in
/include/Make/Platform.make. This does not work wit the way the variable is
used in the Makefiles.
This was reported a long time ago; I'm surprised that it hasn't been
fixed yet.
I edited "/include/Make/Grass.make" to replace
$(PQLIB) with the absolute path to the library
("/usr/local/pgsql/lib/libpq.a" in my case) in the "VECTLIB=" definition.
That fixed the "-lpq not found" error in many makefiles.
The correct fix is not to use $(PQLIB) as a dependency in the
Makefiles. If you can provide a list of modules which generate errors,
I'll fix them.
Solaris did not accept the syntax "@test -e". I replaced it with
"@test -r" in:
/include/Make/Module.make
/db/base/Makefile
/general/manage/cmd/Makefile
/lib/init/init.sh
/scripts/postgisdb
I would think that "test -x" would be preferable; does Solaris support
that?
More generally, there should be a predefined function for generating a
link, rather than repeating the code for each executable. Actually,
the entire body of the rule should probably be a predefined function.
To get -lsocket and -lresolve in the necessary places, I had to add
$(XEXTRALIBS) to LIBES in the Makefile for:
OK; I didn't expect it to work. Right approach, wrong variable.
XEXTRALIBS is meant to be specific to X11.
The right solution is to create additional variables, e.g. SOCKETLIB
and RESOLVLIB, and use those in the appropriate Makefiles. However, a
module's Makefile should only mention those libraries if the module
itself requires those functions.
In most of the cases you list, it's more likely that one of the
libraries which the module uses requires the library. In which case,
the variable for the library should include the necessary
dependencies, so the module would get the dependencies automatically.
E.g. the raster library uses socket functions, so the definition of
RASTERLIB should include the socket library (at present, full
pathnames are being used, which is wrong).
--
Glynn Clements <glynn.clements@virgin.net>
I built 5.1 on Solaris 8 Sparc (without nviz due to the missing "pg.h")
with the following changes:
Changed "@test -e" to "@test -x" everywhere it appeared in the source code:
/lib/init/init.sh
/include/Make/Module.make
/general/manage/cmd/Makefile
/db/base/Makefile
Removed $(PQLIB) from "VECTLIB = " in /include/Make/Grass.make
Added direct path to postgres library (/usr/local/pgsql/lib/libpq.a) in
LIBES section of Makefiles:
in /db:
/drivers/postgres
in /display:
d.erase,d.path,d.path,d.vect,d.what.rast,d.what.vect,d.what.vect,d.zoom
in /general:
g.region/cmd,manage/cmd
in /vector:
v.ascii,v.build,v.build.polylines,v.category,v.clean,v.clean/test,v.convert
,v.db.connect,v.digit,v.extract,v.info,v.in.sites,v.net.alloc,v.net.iso,v.n
et.salesman,v.net.steiner, v.patch, v.transform, v.to.rast, v.surf.rst
Added -lresolv to Makefiles:
in /db:
/drivers/postgres
in /display:
d.erase,d.mon/pgms,d.path,d.vect,d.what.rast,d.what.vect,d.zoom
in /general:
g.region/cmd,manage/cmd
in /vector:
v.ascii,v.build,v.build.polylines,v.category,v.clean,v.clean/test,v.convert
,v.db.connect,v.digit,v.extract,v.info,v.in.sites,v.net.alloc,v.net.iso,v.n
et.salesman,v.net.steiner, v.patch, v.transform, v.to.rast, v.surf.rst
Added $(XEXTRALIBS) (== "-lsocket -lnsl") to LIBES in Makefile:
in /display:
d.path,d.rast,d.vect,d.what.rast,d.zoom
in /general:
g.region,manage/cmd
in /vector:
v.ascii,v.build,v.build.polylines,v.category,v.clean,v.clean/test,v.convert
,v.db.connect,v.digit,v.extract,v.info,v.in.sites,v.net.alloc,v.net.iso,v.n
et.salesman,v.net.steiner, v.patch, v.transform, v.to.rast, v.surf.rst
The new CVS head fails to build on Solaris 8 Sparc because (it
seems) -lsocket is missing from XDRLIB. all of the failed files use
$(XDRLIB). How do I add it and make it effective? What file do I edit and
what commands do I have to run to change the definition of XDRLIB?
Here is the failed file list:
Start of compilation: Wed Mar 5 07:45:09 PST 2003
Errors:
Compilation error in module: src/display/devices/CELL (ignored)
Compilation error in module: src/display/d.3d (ignored)
Compilation error in module: src/display/d.area (ignored)
Compilation error in module: src/display/d.ask (ignored)
Compilation error in module: src/display/d.barscale (ignored)
Compilation error in module: src/display/d.colormode (ignored)
Compilation error in module: src/display/d.colors (ignored)
Compilation error in module: src/display/d.colortable (ignored)
Compilation error in module: src/display/d.db (ignored)
Compilation error in module: src/display/d.display (ignored)
Compilation error in module: src/display/d.erase (ignored)
Compilation error in module: src/display/d.extend (ignored)
Compilation error in module: src/display/d.font (ignored)
Compilation error in module: src/display/d.frame (ignored)
Compilation error in module: src/display/d.geodesic (ignored)
Compilation error in module: src/display/d.graph (ignored)
Compilation error in module: src/display/d.grid (ignored)
Compilation error in module: src/display/d.his (ignored)
Compilation error in module: src/display/d.histogram (ignored)
Compilation error in module: src/display/d.icons (ignored)
Compilation error in module: src/display/d.label (ignored)
Compilation error in module: src/display/d.labels (ignored)
Compilation error in module: src/display/d.leg.thin (ignored)
Compilation error in module: src/display/d.mapgraph (ignored)
Compilation error in module: src/display/d.measure (ignored)
Compilation error in module: src/display/d.menu (ignored)
Compilation error in module: src/display/d.mon (ignored)
Compilation error in module: src/display/d.p.labels (ignored)
Compilation error in module: src/display/d.pan (ignored)
Compilation error in module: src/display/d.points (ignored)
Compilation error in module: src/display/d.profile (ignored)
Compilation error in module: src/display/d.rast (ignored)
Compilation error in module: src/display/d.rast.arrow (ignored)
Compilation error in module: src/display/d.rast.edit (ignored)
Compilation error in module: src/display/d.rast.num (ignored)
Compilation error in module: src/display/d.rgb (ignored)
Compilation error in module: src/display/d.rhumbline (ignored)
Compilation error in module: src/display/d.save (ignored)
Compilation error in module: src/display/d.scale (ignored)
Compilation error in module: src/display/d.site.labels (ignored)
Compilation error in module: src/display/d.sites (ignored)
Compilation error in module: src/display/d.sites.qual (ignored)
Compilation error in module: src/display/d.text (ignored)
Compilation error in module: src/display/d.vect (ignored)
Compilation error in module: src/display/d.vect.area (ignored)
Compilation error in module: src/display/d.vect.labels (ignored)
Compilation error in module: src/display/d.vect.line (ignored)
Compilation error in module: src/display/d.what.db (ignored)
Compilation error in module: src/display/d.what.rast (ignored)
Compilation error in module: src/display/d.what.sites (ignored)
Compilation error in module: src/display/d.what.vect (ignored)
Compilation error in module: src/display/d.where (ignored)
Compilation error in module: src/display/d.zoom (ignored)
Compilation error in module: src/imagery/i.ask (ignored)
Compilation error in module: src/imagery/i.class (ignored)
Compilation error in module: src/imagery/i.colors (ignored)
Compilation error in module: src/imagery/i.ortho.photo (ignored)
Compilation error in module: src/imagery/i.points (ignored)
Compilation error in module: src/imagery/i.points3 (ignored)
Compilation error in module: src/imagery/i.vpoints (ignored)
Compilation error in module: src/mapdev/v.area (ignored)
Compilation error in module: src/mapdev/v.digit (ignored)
Compilation error in module: src/mapdev/v.what (ignored)
Compilation error in module: src/paint/Drivers/preview (ignored)
Compilation error in module: src/paint/Drivers/preview2 (ignored)
Compilation error in module: src/ps.map (ignored)
Compilation error in module: src/raster/r.combine (ignored)
Compilation error in module: src/raster/r.digit (ignored)
Compilation error in module: src/raster/r.le (ignored)
Compilation error in module: src/raster/r.profile (ignored)
Compilation error in module: src/raster/r.weight (ignored)
Compilation error in module: src/raster/wildfire (ignored)
Compilation error in module: src.contrib/CERL/raster/r.water.fea/src
(ignored)
Compilation error in module: src.contrib/PURDUE/d.linegraph (ignored)
Compilation error in module: src.contrib/SCS/display/d.fix.ortho (ignored)
Compilation error in module: src/display/devices/PNGdriver (ignored)
Compilation error in module: src.contrib/GMSL/NVIZ2.2 (ignored)
End of compilation: Wed Mar 5 08:22:51 PST 2003
DONE generating GRASS GIS binary code
Chris Heg wrote:
The new CVS head fails to build on Solaris 8 Sparc because (it
seems) -lsocket is missing from XDRLIB. all of the failed files use
$(XDRLIB). How do I add it and make it effective? What file do I edit and
what commands do I have to run to change the definition of XDRLIB?
To add it manually, edit the file src/CMD/head/head after running
configure but before running make (this file is generated from head.in
by configure and renamed to head.<arch> at the beginning of the make
process).
The reason why it may have worked before was that XDRLIB included the
value of X_EXTRA_LIBS from the autoconf AC_PATH_XTRA macro:
- Macro: AC_PATH_XTRA
An enhanced version of `AC_PATH_X'. It adds the C compiler flags
that X needs to output variable `X_CFLAGS', and the X linker flags
to `X_LIBS'. If X is not available, adds `-DX_DISPLAY_MISSING' to
`X_CFLAGS'.
This macro also checks for special libraries that some systems
need in order to compile X programs. It adds any that the system
needs to output variable `X_EXTRA_LIBS'. And it checks for
special X11R6 libraries that need to be linked with before
`-lX11', and adds any found to the output variable `X_PRE_LIBS'.
X_EXTRA_LIBS is specific to X11, and shouldn't have been used by
anything other than XDRIVER, xganim and NVIZ. Additionally, there's no
guarantee that it would actually contain -lsocket (if libX11 had
libsocket as a dependency, there would be no need for an explicit
reference), and it might also contain switches which were completely
unnecessary (or even harmful) for non-X programs.
I'll add the appropriate checks to the configure script.
--
Glynn Clements <glynn.clements@virgin.net>
5.0.2 CVS head did not seem to install completely on Solaris 8 Sparc. All of
the files were in /usr/local/grass5/etc/bin but were not accessible because
many were not initially listed in /usr/local/grass5/bin.
I ran "make", "make install", and had to run "gmakelinks5 -i" afterwards to
get everything in place.
On Sun, Mar 02, 2003 at 06:53:56PM +0000, Glynn Clements wrote:
Glynn Clements wrote:
> > I would like to ask if a developer is willing to update r.in.gdal
> > (Frank Warmerdam told me that he won't do that at time):
> >
> > Outstanding
> > - fix the grey color tables issue for RGB maps
>
> The main problem here is determining the overall range of the data,
> i.e. which values correspond to black and white. Black is almost
> certain to be 0, but determining white is more difficult. Usually it's
> ((1<<bit_depth)-1), but you need to know what bit_depth is.The upshot of a private conversation with Frank is that GDAL doesn't
make this information available. Consequently, you would need to use
heuristics to determine the bit depth (and hope that the image isn't
too dark).
We may start to implement it only for RGB images at time. Usually
they should be 8 bit. GDAL cannot deliver the bit depth of the
read format (maybe GetRasterDataType())?
Markus
Markus Neteler wrote:
On Sun, Mar 02, 2003 at 06:53:56PM +0000, Glynn Clements wrote:
Glynn Clements wrote:
I would like to ask if a developer is willing to update r.in.gdal
(Frank Warmerdam told me that he won't do that at time):Outstanding
- fix the grey color tables issue for RGB mapsThe main problem here is determining the overall range of the data,
i.e. which values correspond to black and white. Black is almost
certain to be 0, but determining white is more difficult. Usually it's
((1<<bit_depth)-1), but you need to know what bit_depth is.The upshot of a private conversation with Frank is that GDAL doesn't
make this information available. Consequently, you would need to use
heuristics to determine the bit depth (and hope that the image isn't
too dark).We may start to implement it only for RGB images at time. Usually
they should be 8 bit. GDAL cannot deliver the bit depth of the
read format (maybe GetRasterDataType())?
Markus,
I think Glynn is referring to the fact that GDAL doesn't return the
real dynamic range of the original sensor. For instance, an 11bit sensor
would be represented via GDAL as 16 bit (depending on the format it is
stored in of course), not 11. So, of course GDAL returns information on
the data type but GDAL can't transport the meaningful dynamic range of
the original sensor since that isn't even available in most formats.
In short, if it is GDB_Byte assume a dynamic range of 0-255 otherwise the
data should be sampled.
Later,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
On Mon, Mar 10, 2003 at 10:01:18AM -0500, Frank Warmerdam wrote:
Markus Neteler wrote:
> On Sun, Mar 02, 2003 at 06:53:56PM +0000, Glynn Clements wrote:
>>> Markus Neteler wrote:
[...]
>>>>Outstanding
>>>> - fix the grey color tables issue for RGB maps
[...]
I think Glynn is referring to the fact that GDAL doesn't return the
real dynamic range of the original sensor. For instance, an 11bit sensor
would be represented via GDAL as 16 bit (depending on the format it is
stored in of course), not 11. So, of course GDAL returns information on
the data type but GDAL can't transport the meaningful dynamic range of
the original sensor since that isn't even available in most formats.In short, if it is GDB_Byte assume a dynamic range of 0-255 otherwise the
data should be sampled.
So far I have added a test for GDT_Byte:
if yes, then
G_make_grey_scale_colors (&colors, 0, 255);
is applied to the channel. The resulting color file contains then
% 0 255
0:0 255:255
Also I have added GDALGetColorInterpretationName() to write out
channel.Red, channel.Green, channel.Blue
instead of
channel.1, channel.2, channel.3
in case of a multi-channel image. This works as for 'gdalinfo'.
- tested with GeoTIFF RGB. -> channel.Red etc..
- tested with GeoTIFF Palette -> channel
- tested with LANDSAT 7 CEOS -> channel
- tested with LANDSAT 7 FAST -> channel.1, channel.2 ...
(if ColorInterpretationName == Undefined, the channel number is used)
Outstanding issue:
The CELL compression - I don't know how to apply that suggestion
(Eric ?).
Please update directly in CVS if required.
Markus
On Thu, Mar 13, 2003 at 01:49:46PM +0100, Markus Neteler wrote:
Outstanding issue:
The CELL compression - I don't know how to apply that suggestion
(Eric ?).
***********************************************************
* G_set_cell_format(n)
*
* sets the format for subsequent opens on new integer cell files
* (uncompressed and random only)
* warning - subsequent put_row calls will only write n+1 bytes
* per cell. If the data requires more, the cell file
* will be written incorrectly (but with n+1 bytes per cell)
*
***********************************************************
Hmm, apparently this hint is ignored for compressed CELL files (the
default). So, for it to work:
G_set_cell_format(nbytes-1);
G_open_cell_new_uncompressed (name);
--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse
On Fri, Mar 14, 2003 at 10:05:41PM -0800, Eric G. Miller wrote:
On Fri, Mar 14, 2003 at 02:29:42PM +0100, Markus Neteler wrote:
> On Thu, Mar 13, 2003 at 07:22:46AM -0800, Eric G. Miller wrote:
> > On Thu, Mar 13, 2003 at 01:49:46PM +0100, Markus Neteler wrote:
r.in.gdal update:
> > > Outstanding issue:
> > > The CELL compression - I don't know how to apply that suggestion
Find attached a patch for testing from Eric Miller. Some test maps are
compressed now much (!) better - some files consumed only 10% of the space
after patching main.c of r.in.gdal.
Before submitting to CVS it needs tested with all possible raster types.
patch -p0 main.c < ringdal_main.c.diff
Enjoy,
Markus
PS: I have used cvs diff to create the file, hopefully in the right way.
ringdal_main.c.diff (1.24 KB)
Markus Neteler wrote:
PS: I have used cvs diff to create the file, hopefully in the right way.
Use either "diff -u" (unified) or "diff -c" (context).
Those formats include some context (lines before and after those being
added/removed/modified), which makes them more robust. They are also
easier to read.
Patches which use the default format are only safe to apply to the
exact code which was used for creating them. Applying them to code
which has changed in any way is unreliable (patching may fail
unnecessarily) and risky (patching may appear to succeed but produce
the wrong result).
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, Apr 18, 2003 at 12:15:57AM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> PS: I have used cvs diff to create the file, hopefully in the right way.
Use either "diff -u" (unified) or "diff -c" (context).
Those formats include some context (lines before and after those being
added/removed/modified), which makes them more robust. They are also
easier to read.Patches which use the default format are only safe to apply to the
exact code which was used for creating them. Applying them to code
which has changed in any way is unreliable (patching may fail
unnecessarily) and risky (patching may appear to succeed but produce
the wrong result).
Thanks for the recommendations! Again the patch, now unified.
Markus
ringdal_main.c.diff (2.09 KB)