I have a projected tiff file from sentinel1 data (s1a-ew-grd-hh-20180208t071218-20180208t071323-020512-023164-001.tiff) (lets call it test.tiff) with the following projection in WKT format:
PROJCS["WGS 84",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]],PROJECTION["Polar_Stereographic"],PARAMETER["latitude_of_origin",70],PARAMETER["central_meridian",-45],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]]]
This should be equivalent to the Arctic Polar Stereographic (epsg 3995). My goal is to slightly tune the image by inserting some GCP's and warp it. To double check this method I am starting with the trivial case, where I get the corner coordinates from the projected image (test.tiff):
Size is 17959, 18039
Corner Coordinates:
Upper Left ( 457598.467, -240151.021) ( 17d18'33.06"E, 85d13'55.33"N)
Lower Left ( 457598.467,-1142101.021) ( 23d 9'56.93"W, 78d40'39.65"N)
Upper Right ( 1355548.467, -240151.021) ( 34d57'13.08"E, 77d20'28.88"N)
Lower Right ( 1355548.467,-1142101.021) ( 4d53' 4.53"E, 73d44'33.76"N)
Center ( 906573.467, -691126.021) ( 7d40'47.73"E, 79d30'17.56"N)
and I set the GCP according to that. Hence:
gdal_translate -gcp 0.0 0.0 457598.467 -240151.021 -gcp 0.0 18039.0 1355548.467 -240151.021 -gcp 17959.0 18039.0 1355548.467 -1142101.021 -gcp 17959.0 0.0 457598.467 -1142101.021 -a_srs WKT_PROJECTION test.tiff gcp.tiff
Then I warp the image using the -tps option to force warping using the GCP information.
gdalwarp -tps gcp.tiff gcp_warped.tiff
One would expect that the test.tiff and the gcp_warped.tiff files should coincide which is unfortunately not the case:
Is there something that I miss during the above mentioned procedure? Or is there another work around?
Related
I have been trying to implement some of the layer blending modes of GIMP (GEGL) to Python. Currently, I am stuck in Subtract Blending mode. As per documentation, Subtract = max(Background - Foreground, 0). However, doing a simple test in GIMP, with Background image = (205,36,50) and Foreground image = (125,38,85), the resultant composite image/colour comes to be (170, 234, 0) which doesn't quite follow the math above.
As per understanding, Subtract does not use Alpha Blending. So, could this be a compositing issue? Or Subtract follows different math? More details and background can be find in a separate SO question.
EDIT [14/10/2021]:
I tried with this image as my Source. Performed following steps on images normalised in range [0, 1]:
Applied a Colour Dodge (no prior conversion from sRGB -> linear RGB was done) and obtained this from my implementation which matches with GIMP result.
sRGB -> linear RGB conversion on Colour Dodge and Source image. [Reference]
Apply Subtract blending with Background = Colour Dodge and Foreground = Source Image
Reconvert linear RGB-> sRGB
I obtain this from POC. Left RGB triplet: (69,60,34); Right RGB triplet: (3,0,192). And the GIMP result. Left RGB triplet: (69,60,35); Right RGB triplet: (4,255,255)
If you are looking at channel values in the 0 ➞ 255 range they are likely gamma-corrected. The operation is possibly done like this:
convert each layer to "linear light" in the 0.0 ➞ 1.0 range using something like
L = ((V/255) ** gamma) (*)
apply the "difference" formula
convert the result back to gamma-corrected:
V = (255 * (Diff ** (1/gamma)))
With gamma=2.2 you obtain 170 for the Red channel, but I don't see why you get 234 on the Green channel.
(*) The actual formula has a special case for the very low values IIRC.
I’m trying to convert a full globe Robinson Projection to Mercator. For example, I use this image.
First, I apply geo-tagging:
gdal_translate -a_ullr -180 90 180 -90 -a_srs ESRI:54030 source.jpg source_tagged.tif
and finally warp it to Mercator:
gdalwarp -t_srs ESRI:54030 -s_srs EPSG:3857 source_tagged.tif target.tif
The outcome is slightly stretched vertically but nowhere near proper Mercator. What am I doing wrong?
There are a couple of issues in your commands. The first is that -180 90 isn't in the top left corner pixel of global Robinson projection GeoTIFFs. The top left corner would be something like -338.2187147689 90, and the bottom right would be 338.2187147689 -90. However, you're also specifying your srs as ESRI:54030, so those bounds need to be in projected coordinates, not lat/lons. The command to generate a GeoTIFF from your image would be:
gdal_translate -a_ullr -17005833.3305252 8625154.47184994 17005833.3305252 -8625154.47184994 -a_srs ESRI:54030 source.jpg source_tagged.tif
Your second command has the -t_srs and -s_srs switched. Given that you're projecting to EPSG:3857, you'll also need to provide bounds since Mercator goes to infinity at the poles. So the updated command will look like:
gdalwarp -s_srs ESRI:54030 -t_srs EPSG:3857 -te -180 -81 180 81 -te_srs EPSG:4326 source_tagged.tif target.tif
I made the following projected image from your example using these commands (cropping the whitespace in the image prior to running them).
I am trying to use gdalwarp to project a polar stereographic image to a mercator projection epsg 28992 (for use in leaflet)
gdalinfo "HDF5:\"RAD_NL25_PCP_NA_202010271205.h5\"://image1/image_data"
Driver: HDF5Image/HDF5 Dataset
Files: RAD_NL25_PCP_NA_202010271205.h5
Size is 700, 765
Metadata:
geographic_geo_column_offset=0
geographic_geo_dim_pixel=KM,KM
geographic_geo_number_columns=700
geographic_geo_number_rows=765
geographic_geo_par_pixel=X,Y
geographic_geo_pixel_def=LU
geographic_geo_pixel_size_x=1.0000035
geographic_geo_pixel_size_y=-1.0000048
geographic_geo_product_corners=0 49.362064 0 55.973602 10.856453 55.388973 9.0093002 48.895302
geographic_geo_row_offset=3649.9819
geographic_map_projection_projection_indication=Y
geographic_map_projection_projection_name=STEREOGRAPHIC
geographic_map_projection_projection_proj4_params=+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378.14 +b=6356.75 +x_0=0 y_0=0
image1_calibration_calibration_flag=Y
image1_calibration_calibration_formulas=GEO = 0.500000 * PV + -32.000000
image1_calibration_calibration_missing_data=0
image1_calibration_calibration_out_of_image=255
image1_image_bytes_per_pixel=1
image1_image_geo_parameter=REFLECTIVITY_[DBZ]
image1_image_product_name=RAD_NL25_PCP_H1.5_NA
image1_image_size=535500
image1_statistics_stat_max_value=44.5
image1_statistics_stat_min_value=-31.5
overview_hdftag_version_number=3.6
overview_number_image_groups=1
overview_number_radar_groups=3
overview_number_satellite_groups=0
overview_number_station_groups=0
overview_products_missing=NA
overview_product_datetime_end=27-OCT-2020;12:05:00.000
overview_product_datetime_start=27-OCT-2020;12:05:00.000
overview_product_group_name=RAD_NL25_PCP_NA
radar1_radar_location=5.17834 52.101681
radar1_radar_name=DeBilt
radar1_radar_operational=0
radar2_radar_location=4.7999701 52.953339
radar2_radar_name=DenHelder
radar2_radar_operational=1
radar3_radar_location=5.1381001 51.836899
radar3_radar_name=Herwijnen
radar3_radar_operational=1
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 765.0)
Upper Right ( 700.0, 0.0)
Lower Right ( 700.0, 765.0)
Center ( 350.0, 382.5)
Band 1 Block=700x765 Type=Byte, ColorInterp=Undefined
Metadata:
image1_image_data_CLASS=IMAGE
image1_image_data_PALETTE=
image1_image_data_VERSION=1.2
gdalwarp -s_srs "+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378.14 +b=6356.75 +x_0=0 y_0=0" -t_srs "epsg:28992" "HDF5:\"RAD_NL25_PCP_NA_202010271205.h5\"://image1/image_data" output.tif
which results in this error message:
Processing HDF5:"RAD_NL25_PCP_NA_202010271205.h5"://image1/image_data [1/1] : 0ERROR 1: The transformation is already "north up" or a transformation between pixel/line and georeferenced coordinates cannot be computed for HDF5:"RAD_NL25_PCP_NA_202010271205.h5"://image1/image_data. There is no affine transformation and no GCPs. Specify transformation option SRC_METHOD=NO_GEOTRANSFORM to bypass this check.
What am i missing? If i set the flag SRC_METHOD=NO_GEOTRANSFORM i dont get the expected result
Georeference support for HDF5 data in GDAL is very limited (https://gdal.org/drivers/raster/hdf5.html). Therefore, your HDF5 file is not recognized by GDAL as georeferenced data.
My solution is to divide your command into two steps:
Georeferencing to stereographic projection using gdal_translate
Transformation to epsg:28992 using gdalwarp
First, the definition of SRS, the size of the Earth should be expressed in m as follows.
+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378140 +b=6356750 +x_0=0 +y_0=0
Next, assuming that the metadata geographic_geo_product_corners represents the latitude and longitude of the four corners of the image, we find the projected coordinates of the corners of the image.
LL (0, -4415002.84084825)
UL (0, -3649999.11191775)
UR (700002.437056242, -3649999.05174429)
LR (700002.440031711, -4415003.15918867)
I used gdaltransform to find this.
gdaltransform -s_srs "+proj=latlong" -t_srs "+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378140 +b=6356750 +x_0=0 y_0=0"
So, the conversion in your question can be done with the following command
gdal_translate -of VRT -a_srs "+proj=stere +lat_0=90 +lon_0=0 +lat_ts=60 +a=6378140 +b=6356750 +x_0=0 +y_0=0" -a_ullr 0 -3649999.05174429 700002.440031711 -4415003.15918867 "HDF5:\"RAD_NL25_PCP_NA_202010271205.h5\"://image1/image_data" /vsistdout/ | gdalwarp -of GTiff -t_srs epsg:28992 /vsistdin/ output.tif
For information on how to combine two gdal command with a pipe, see the answer in How to convert projection of png tile from epsg:4326 to epsg:3857 by one command using gdal.
I'm trying to use NVIDIA NPP to experiment with some image resizing routines. I want to resize to an exact dimension. I've been looking at image resizing using NVIDIA NPP but all of its resize functions take scale factors for X and Y Dimensions, and I could not see any API taking direct destination dimensions.
As an example, this is one API:
NppStatus nppiResizeSqrPixel_8u_C1R(const Npp8u * pSrc, NppiSize oSrcSize, int nSrcStep, NppiRect oSrcROI, Npp8u * pDst, int nDstStep, NppiRect oDstROI, double nXFactor, double nYFactor, double nXShift, double nYShift, int eInterpolation);
I realize one way could be to find the appropriate scale factor the destination dimension, but we don't exactly know how the API decides destination ROI based on scale factor (since it is floating point math). We could reverse the calculation in the jpegNPP sample to find the scale factor, but the API itself does not make any guarantees so I'm not sure how safe it is. Any ideas what are the possibilities?
As a side question, the API also takes two params, nXShift and nYShift, but just says "Source pixel shift in x-direction". I'm not exactly clear what shift is being talked about here. Do you have an idea?
If I wanted to map the whole SRC image to the smaller rectangle in the DST image as shown in the image below I would use xFactor = yFactor = 0.5 and xShift = 0.5*DST.width and yShift = 0.
Mapping src to half size destination image
In other words, the pixel at (x,y) in the SRC is mapped to the pixel (x',y') in the DST as
x' = xFactor * x + xShift
y' = yFactor * y + yShift
In this case, both the source and dest ROI could be the entire support of the respective images.
I'm using gdal to create different kinds of layers, such as color reliefs and hillshades, and Mapnik to combine them into a single image to use as texture for the 3D dem model obtained from a single .hgt file.
Premising that I'm new to gdal, I'm facing some problem with the hillshade layer.By using the gdal command:gdal_translate N44E007.hgt N44E007.tif
I get the N44E007.tif file, which in IrfanView looks like this
With the following gdal command:gdaldem hillshade -of PNG .\tif\N44E007.tif .\hillshade_png\N44E007_hillshade.png
The N44E007_hillshade.png file I get is the following
How can I prevent gdal from creating these artifacts in the hillshade .png?
I'm using Windows 7 and cmd.
Update 1
This is the image I get by replacing gdal_translate N44E007.hgt N44E007.tif with gdalwarp -t_srs EPSG:32632 -r bilinear N44E006.hgt N44E006.tif
The problem is that the reprojected image is slightly rotated and stretched. How can I get a squared and straight image to use as texture for a 3d plane?
The reason for the artefacts in the first attempt is because the raster horizontal distance units are in degrees, and the vertical are in meters. You can use a scale option to normalise horizontal and vertical distance units, e.g. try:
gdaldem hillshade -s 111120 -compute_edges -of PNG N44E007.hgt N44E007_hs.png
The second attempt (Update 1) reprojects to WGS84 UTM zone 32, which is a transverse Mercator projection centred on a meridian at 9°E, which is close to the SRTM raster, which is centred on 7.5°E. Since the two meridians are not the same, it is expected the raster to be rotated. And it is stretched since the true distance of degrees are not equal in N-S and E-W directions, except at the equator.