3

I am using 'Clip raster by mask layer' in QGIS to clip a raster temperature layer down to the size of the area I'm interested in using a polygon. The resulting clipped layer is a raster that has pixel values significantly different from the original.

I am doing this same process with different raster layers and it usually works fine, but some clipped layers come out with pixel values totally off. This is not an issue of values display. It's just that the pixels have different values. For example, when I right-click with 'identifier features' option on a random pixel it gives me values of 26.95 in the original (which makes complete sense as this is the value of mean annual temperature) and a value of 3001 in the clipped raster.

enter image description here

Does anyone know what's going wrong?

I couldn't attach the image in my previous comment. Here it is:

enter image description here

Improve this question
7
  • 1
    Does your clipped raster have the same bit depth as the original? It may be that the clipped raster is of integer type and cannot store floating point values.
    – Matt
    Commented Mar 21, 2022 at 15:16
  • I agree with @Matt, you can start by comparing the pixel depth and nodata values of the input and outputs
    – Kartograaf
    Commented Mar 21, 2022 at 15:54
  • If the issue was data type then would the result be 11 in the example provided?
    – GBG
    Commented Mar 21, 2022 at 16:07
  • 1
    8-bit range is 0-255 and 16-bit range is 0-65535. 65536/2844=23.04 and 256/11=23.27. Thus about the same proportion of the full scale. You may have changed the datatype. Another option is that the original image is of higher bit depth but it has scale and offset stored into the image metadata and QGIS know to make the conversion into temperature units. I do not know if it can do that. You should add gdalinfo reports about your images.
    – user30184
    Commented Mar 21, 2022 at 16:22
  • 1
    With gdalinfo report I meant the report that this utility creates gdal.org/programs/gdalinfo.html. I could not find reference for scale and offset. This is what they do: if you have a pixel with value 2000, offset 1000 and scale 0.001, then first add the offset (2000+1000=3000) and then multiply with the scale (3000*0.001=3). So pixel value 2000 means measurement value 3. I hope I got the signs correctly but compare with gis.stackexchange.com/questions/229719/…. See also -unscale in gdal.org/programs/gdal_translate.html and experiment.
    – user30184
    Commented Mar 21, 2022 at 20:20

1 Answer 1

Reset to default
1

Before you run the mask tool, use the GDAL Translate (convert format) tool to unscale your input raster as follows:

  1. Select tool from toolbox under GDAL->Raster conversion -> Translate
  2. Choose your input raster as the input layer for the translate tool
  3. Type -unscale -co DECIMAL_PRECISION=2 in the Additional command-line parameters (don't forget the leading hyphen)
  4. Choose output filename and location
  5. Run the Translate tool and use the output (unscaled tiff) as the input to 'clip raster from mask' as you did before.

enter image description here

Improve this answer
8
  • Thanks, I already tried that, but that doesn't solve the issue. The pixel values in the clipped raster are still different from the original raster.
    – M.G.
    Commented Mar 21, 2022 at 20:03
  • OK thanks, can you pull up the properties of your input data (right click -> properties) then click the information tab on the left menu and tell me what you see under "Information from Provider -> data type" ?
    – Kartograaf
    Commented Mar 21, 2022 at 20:09
  • It says: "Float32 - Thirty two bit floating point".
    – M.G.
    Commented Mar 21, 2022 at 20:27
  • can you try adding -unscale in the blank directly below the one circled in red above? The one labeled "additional command-line parameters [optional]".
    – Kartograaf
    Commented Mar 21, 2022 at 20:41
  • It gives the following error: ERROR 4: unscale: No such file or directory
    – M.G.
    Commented Mar 21, 2022 at 21:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.