[gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

Tue Apr 23 12:39:33 PDT 2024

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 at 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 at 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.evans at gmail.com>
>> > Sent: Monday, April 22, 2024 9:29 AM
>> > To: Raley, Nathan <nraley at gaig.com>
>> > Cc: 'gdal-dev at lists.osgeo.org' (gdal-dev at lists.osgeo.org) <
>> gdal-dev at 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 at lists.osgeo.org<mailto:gdal-dev at 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 at lists.osgeo.org<mailto:gdal-dev at 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
>>                     andrew at aitchison.me.uk
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> _______________________________________________
> 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/20240423/edb30eb8/attachment.htm>