Way back in a different career stage, I published this method for displaying colour-infrared as fairly convincing pseudo-true colour: https://www.researchgate.net/publication/242078137_A_simplified_method_for_generation_of_pseudo_natural_colours_from_colour_infrared_aerial_photos
At least one company provided material based on this algorithm, as a commercial service around 2005. /Thomas Den man. 22. apr. 2024 kl. 20.13 skrev Javier Jimenez Shaw via gdal-dev < gdal-dev@lists.osgeo.org>: > In addition to all the previous, what about gamma correction? > Maybe your RGB images are gamma corrected, while the other bands are not. > In that case you will be comparing apples and oranges (in addition to the > scaling problems described before). > That also means that using the multispectral images (even if you had a > Blue one) without gamma correction will have a strange color for us humans > using a monitor. > > What I did in the past was to "fake" blue as a combination of red and > green (yes, it is not perfect, but better than nothing), and apply a gamma > of 2 to all the bands. > > Other "nice" option is to display them as CIR > https://www.mngeo.state.mn.us/chouse/airphoto/cir.html > > Cheers > Javier > > On Mon, 22 Apr 2024 at 17:49, Andrew C Aitchison via gdal-dev < > gdal-dev@lists.osgeo.org> wrote: > >> On Mon, 22 Apr 2024, Raley, Nathan via gdal-dev wrote: >> >> > Hmm, good catch. Looking at the stats for the red band: >> > >> > Band 1 Block=128x128 Type=UInt16, ColorInterp=Gray >> > Min=130.000 Max=36265.000 >> > Minimum=130.000, Maximum=36265.000, Mean=10415.962, StdDev=3502.933 >> > NoData Value=0 >> > Metadata: >> > STATISTICS_MAXIMUM=36265 >> > STATISTICS_MEAN=10415.961859513 >> > STATISTICS_MINIMUM=130 >> > STATISTICS_STDDEV=3502.9325925887 >> > STATISTICS_VALID_PERCENT=49 >> > >> > So, is there no way to actually do this via command line, or am I going >> to have to write a python lib to actually read through these and determine >> what they should be scaled to? >> >> There is gdal_transform -scale (and -scale_2 etc.) >> >> What are you going to do with the resulting file ? >> QGIS allows you to make these sorts of adjustments at view-time. >> >> Remember that the max and min values present in an image may not represent >> the full range and the next-door image may have a larger or smaller range >> (or just a shifted range). Imagine a row of three tiles; the middle on on >> the edge of a glacier, the first entirely on the glacier and the last >> entirely off the glacier. You may wish to apply the same scaling to all >> three. >> >> > From: Daniel Evans <daniel.fred.ev...@gmail.com> >> > Sent: Monday, April 22, 2024 9:29 AM >> > To: Raley, Nathan <nra...@gaig.com> >> > Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) < >> gdal-dev@lists.osgeo.org> >> > Subject: [External] Re: [gdal-dev] Question on building multi band >> composite and going back to RGB GeoTiff >> > >> > Hi Nathan, My initial suspicion might just be that the scaling the data >> provider did to go from the raw data to a human-eye-friendly RGB composite >> isn't the conversion you're assuming. I know that with the data I regularly >> work with, >> > >> > Hi Nathan, >> > >> > My initial suspicion might just be that the scaling the data provider >> did to go from the raw data to a human-eye-friendly RGB composite isn't the >> conversion you're assuming. >> > >> > I know that with the data I regularly work with, it may be provided as >> Uint16, but the data range doesn't extend all the way to 65535. >> > >> > If you compare the values in the separate R and G images to the RGB >> composite, do they appear to match the conversion you're assuming, or is >> there a different scaling (and possibly offset)? >> > >> > Cheers, >> > Daniel >> > >> > On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, < >> gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> wrote: >> > I currently have a RGB geotiff composite image that has a Byte >> datatype. I also have individual band images for R, G, Redge, and NIR that >> are UInt16 datatypes. Since I’m missing the Blue band from the individual >> bands, I was attempting to extract the blue band from the RGB composite >> image, scale it up to the UInt16 datatype, and build a composite VRT with >> R, G, B, NIR, RE bands included in it. I was then attempting to extract >> the RGB bands from the multispec VRT in order to see if the process was >> working as intended, but I’m getting an extremely blue image. >> > >> > Can anyone shed some light as to what I may be doing wrong here? >> > >> > I started by building a VRT for each band: >> > gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 >> 255 0 65535 >> > gdalbuildvrt -b 1 r.vrt source_R.tif >> > gdalbuildvrt -b 1 g.vrt source_G.tif >> > gdalbuildvrt -b 1 nir.vrt source_NIR.tif >> > gdalbuildvrt -b 1 re.vrt source_RE.tif >> > >> > I then merged the VRTs: >> > gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt >> > >> > I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all >> with a UInt16 datatype. >> > >> > Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with >> something like: >> > gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 >> -co PHOTOMETRIC=RGB multispec.vrt multispec.tif >> > >> > Viewing the result in QGIS appears overly blue. What am I doing wrong >> here? >> > >> > Thanks, >> > Nathan >> > >> > ________________________________ >> > This email transmission, including any attachments, is intended solely >> for the addressee named above, and may contain confidential or privileged >> information. If you are not the intended recipient, be aware that any >> disclosure, copying, distribution or use of the contents of this e-mail is >> prohibited. If you have received this e-mail in error, please notify the >> sender immediately by reply email and destroy the message and its >> attachments. >> > _______________________________________________ >> > gdal-dev mailing list >> > gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> >> > https://lists.osgeo.org/mailman/listinfo/gdal-dev< >> https://urldefense.com/v3/__https:/lists.osgeo.org/mailman/listinfo/gdal-dev__;!!CsmrWXz9mOkSc4Hdn1fjj00!wHjHtqIprjw9nQ3elKNFMUWmEwR3sKx-zrxpsNEk-kBIhomauYshqPep8-beAmn7Ma8NlmL95Mqf9c8fol37c2o$ >> > >> > >> > This email transmission, including any attachments, is intended solely >> for the addressee named above, and may contain confidential or privileged >> information. If you are not the intended recipient, be aware that any >> disclosure, copying, distribution or use of the contents of this e-mail is >> prohibited. If you have received this e-mail in error, please notify the >> sender immediately by reply email and destroy the message and its >> attachments. >> > >> >> -- >> Andrew C. Aitchison Kendal, UK >> and...@aitchison.me.uk >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
