<div dir="ltr"><div>Hi Michael.</div><div><br></div><div>First of all: I do not know a magic function to convert to RGB(A)</div><div>From my experience exactly with this situation, it is never possible to make everybody happy. I detected several issues:</div><div><br></div><div></div><div>- Missing metadata.</div><div>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).</div><div><br></div><div>- Wrong metadata</div><div>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.<br></div><div><br></div><div>- Composed images.</div><div>Multispectral images are some times (many?) stored with one file per band. That makes RGB complicated</div><div>Even when they are all in one file... how do you represent as RGB a file with 5, 10 or 20 bands?</div><div><br></div><div>- Missing bands.</div><div>Again, from multispectral sensors, some have Near Infrared, Red and Green (identified in XMP). There is no blue. How do you fake the blue?</div><div><br></div><div>- Not showing information</div><div>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.<br></div><div><br></div><div>- Normalizing the ranges.</div><div>You want an RGB with 8 bits per band. What do you do with float values? Normalizing them all is... not easy.</div><div><br></div><div>- Gamma correction</div><div>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?<br></div><div><br></div><div>- Single float band</div><div>There is a complete branch of UX on how to represent those images. Different color maps. Choosing one means not choosing all the rest.</div><div><br></div><div>- Palleted colours</div><div>Some format include their own pallete, but some one-band files are just a classification. Again, endless discussion in UX team.<br></div><div><br></div><div>- ... more cases I am missing</div><div>There are more cases that I forgot, or that I am not aware of.<br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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 ;)<br></div><div><br></div><div>Cheers,</div><div>Javier<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 30 Aug 2023 at 22:18, Michael Katz via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px"><div dir="ltr"><div dir="ltr">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?<div><br></div></div></div></div></div>_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>