I've made some modifications to r.in.tiff to hopefully make it a bit
more useable. I completely removed all of the color reduction
code and am just forcing all RGB TIFF's into respective band files.
Since, r.in.tiff was completely unusable for me here, due to the
ridiculous stack allocation for the color reduction code, I would
propose that folks grab it and build it, and if stable we push it to
the release branch.
There have been alot of complaints about r.in.tiff, and given both the
extra work required to get r.in.gdal up and running and the ubiquity of
TIFF files for imagery, I think it's a worthy thing to get it working
better for folks. So, I need your help testing it!
I've tried it with gray, palette and RGB without trouble (with and
without a world file). I haven't tested the monochrome and less than 8
bits per pixel code, but that's mostly unchanged...
--
Eric G. Miller <egm2@jps.net>
Eric G. Miller wrote:
I've made some modifications to r.in.tiff to hopefully make it a bit
more useable. I completely removed all of the color reduction
code and am just forcing all RGB TIFF's into respective band files.
I've done something similar for r.in.png.
It now supports paletted, grey-scale and true-colour images, with or
without an alpha channel. In all cases, pixel values are imported
verbatim, including sBIT information (where present) and
16-bit-per-component images; any translations are performed in the
colour table.
AFAICT, the only image importer left to fix is r.in.sunrast.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
> I've made some modifications to r.in.tiff to hopefully make it a bit
> more useable. I completely removed all of the color reduction
> code and am just forcing all RGB TIFF's into respective band files.
I've done something similar for r.in.png.
It now supports paletted, grey-scale and true-colour images, with or
without an alpha channel. In all cases, pixel values are imported
verbatim, including sBIT information (where present) and
16-bit-per-component images; any translations are performed in the
colour table.
I've tested all of the options for which I can actually generate test
images (8-bit grey, paletted and true-color formats, alpha channel,
transparency, gamma setting, and interlace).
However, I haven't been able to generate test images with bit depths
other than 8, or with sBIT information. Does anyone know of programs
which can generate a greater variety of PNG image formats?
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, May 09, 2002 at 09:08:42AM +0100, Glynn Clements wrote:
Glynn Clements wrote:
> > I've made some modifications to r.in.tiff to hopefully make it a bit
> > more useable. I completely removed all of the color reduction
> > code and am just forcing all RGB TIFF's into respective band files.
>
> I've done something similar for r.in.png.
>
> It now supports paletted, grey-scale and true-colour images, with or
> without an alpha channel. In all cases, pixel values are imported
> verbatim, including sBIT information (where present) and
> 16-bit-per-component images; any translations are performed in the
> colour table.
I've tested all of the options for which I can actually generate test
images (8-bit grey, paletted and true-color formats, alpha channel,
transparency, gamma setting, and interlace).
However, I haven't been able to generate test images with bit depths
other than 8, or with sBIT information. Does anyone know of programs
which can generate a greater variety of PNG image formats?
Maybe 'gdal_translate' generates at least 16 bit images:
http://www.remotesensing.org/gdal/frmt_various.html#PNG
"PNG files can be created with a type of PNG, using the CreateCopy() method,
requiring a prototype to read from. Writing includes support for the various
image types, and will preserve transparency/nodata values. Georeferencing
.wld files are written if option WORLFFILE setted. All pixel types other
than 16bit unsigned will be written as eight bit."
Markus