[gdal-dev] Universal raster to rgba?

[Michael Katz]

 Hi Javier, thanks for the detailed breakdown. I had a sense of some of those cases but didn't know all. Still, I think there is a use case, like for users of my program, where they have a file that covers a certain region, and they prefer to see *something* rather than nothing.
I imagine a function that can output the rgba along with a list of notes, warnings, and errors, representing three levels of alerts about what was missing from (e.g., metadata, bands), modified from (e.g., precision loss), or had to be assumed about (e.g., metadata) the data to generate the image. A fancier version would let you specify the way that certain decisions would be made, so that would let the user try different settings to play around with things (perhaps like the Layer Settings in QGIS).



    On Thursday, August 31, 2023 at 01:19:28 AM PDT, Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:  
 
 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 metadataThere 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 complicatedEven 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 informationIf 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 correctionSome 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 bandThere is a complete branch of UX on how to represent those images. Different color maps. Choosing one means not choosing all the rest.
- Palleted coloursSome format include their own pallete, but some one-band files are just a classification. Again, endless discussion in UX team.

- ... more cases I am missingThere 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/a1a4c5c9/attachment.htm>