[gdal-dev] Universal raster to rgba?

[Javier Jimenez Shaw]

Hi Michael.

First of all: I do not know a magic function to convert to RGB(A)
>From my experience exactly with this situation, it is never possible to
make everybody happy. I detected several issues:

- Missing metadata.
Many images do not specify the "meaning" of each band. If you have 3 bands
assuming that they are R,G and B probably works, but not always. With
multispectral images there is no enum for Near Infrared, Red Edge, and so
on. So they should be identified in a different way (most of them in the
file name).

- Wrong metadata
There are some images with wrong metadata. Sometimes it could make sense
(kind of). For example, modified lenses remove the infrared filer from the
optics, so the blue band becomes a Near Infrared band... but the firmware
is still telling that it is an RGB jpeg. They look pretty strange in the
screen.

- Composed images.
Multispectral images are some times (many?) stored with one file per band.
That makes RGB complicated
Even when they are all in one file... how do you represent as RGB a file
with 5, 10 or 20 bands?

- Missing bands.
Again, from multispectral sensors, some have Near Infrared, Red and Green
(identified in XMP). There is no blue. How do you fake the blue?

- Not showing information
If you omit some bands from the RGB (like Near Infrared) then you will not
notice any mistake there... because you are looking only to the RGB. That
happened to me.

- Normalizing the ranges.
You want an RGB with 8 bits per band. What do you do with float values?
Normalizing them all is... not easy.

- Gamma correction
Some images do not have gamma correction (or use gamma = 1 if you prefer).
(those images try to measure something -like reflectance-, not look pretty
in the screen). That output is strange of human beings nowadays. How do you
detect that?

- Single float band
There is a complete branch of UX on how to represent those images.
Different color maps. Choosing one means not choosing all the rest.

- Palleted colours
Some format include their own pallete, but some one-band files are just a
classification. Again, endless discussion in UX team.

- ... more cases I am missing
There are more cases that I forgot, or that I am not aware of.


Personally I am kind of ok with QGIS solution in the "Layer Stiling" panel.
I have to select what I want to do. Yes every time, it is not convenient.

If you want to create a function that is doing "its best", great. I do not
know exactly where it would fit in GDAL. I would guess it is going to be a
function full of "ifs" and many lines of code ;)

Cheers,
Javier

On Wed, 30 Aug 2023 at 22:18, Michael Katz via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> In our program, we want the user to be able to open and view any raster
> map. As I understand it, and as we use it in our program, the GDAL API lets
> you read all sorts of raster files, but it presents them to you in a
> general form: a certain number of bands, where the bands can have a certain
> data type (e.g., a double or an unsigned byte) and a certain meaning (e.g.,
> red or grayscale or transparency). But we are left having to deal with all
> of the cases in order to transform it into an array of (unsigned byte) rgba
> pixels (i.e., an image to show on the screen). I was surprised there was no
> such function, and I also realize that expecting there to be such a
> function might show my lack of understanding of the range of possible
> raster file data types. But even if some files don't have a default rgba
> representation, it would be great to have a function that does its best
> with any given file. I asked Even R. about it a few years ago and his
> comment was "probably somebody must have done it". But I haven't found a
> library. Our current implementation takes care of many common cases but no
> doubt there are files out there that we display incorrectly even though
> they have a natural rgba representation. Am I wrong to think there
> could/should be such a function? Is there such a function?
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230831/3bb1c558/attachment.htm>