Fix pictures URL

docs/_posts/2024-01-08-version-0-2-shortcomings.md

@@ -17,7 +17,7 @@ The asar-focus focusing quality is not ideal, we considered many possible improv
 
 From "Digital Processing of Synthetic Aperture Radar Data"
 
-![](../assets/rda_options.png)
+![](/assets/rda_options.png)
 
 The current version of the processor implements the "Basic RDA" variant.
 
@@ -34,7 +34,7 @@ Thus if the antenna is squinted too much, and the azimuth Doppler history does n
 
 Image from article - Signal Properties of Spaceborne Squint-Mode SAR, visualizing how this happens - if the antenna is not ideally sidelooking, the observed Doppler frequencies may not cross the zero point.
 
-![https://www.researchgate.net/publication/3201663_Signal_Properties_of_Spaceborne_Squint-Mode_SAR](../assets/squint.png)
+![https://www.researchgate.net/publication/3201663_Signal_Properties_of_Spaceborne_Squint-Mode_SAR](/assets/squint.png)
 
 For example, if PRF is 2000HZ, the Doppler centroid is estimated correctly in the +-1000Hz range because the current processor only calculates the fractional part, however if the true Doppler centroid is for example 1500Hz, it would be estimated as 500Hz due to aliasing and no integer part would be estimated. The Doppler centroid DS in the output file would display incorrectly and the focusing quality would be degraded.
 
@@ -45,9 +45,9 @@ This is should be more of an issue with some ERS datasets, where the true Dopple
 The 0.2 processor always assumes the dataset height from WGS84 ellipsoid is 0m. This should cause two immediate issues with dataset not at the sea level - 1. degraded geocoding 2. worse estimate of Vr(processing velocity/radar velocity) used for calculation during azimuth compression.
 
 1. Geocoding is done via finding an zero Doppler point from orbit state vectors, visually something like this:
-![](../assets/geocoding.png)
+![](/assets/geocoding.png)
 2. Vr is estimated from orbit state vector data, as described in the "Digital processing of Synthetic aperture data" in 13.3.
-![](../assets/vr_estimate.png)
+![](/assets/vr_estimate.png)
 
 
 Both operations involve estimating the height of the target point, however we were unsure of the implementation for this - does other focussing software require DEM access to estimate the center scene height.
@@ -59,7 +59,7 @@ Nevertheless, the lack of average terrain height estimate does not explain poore
 The current processor always uses the nominal range chip to generate the reference chirp and use it to perform range compression.
 
 An example nominal chirp look like this for ASAR:
-![](../assets/nom_chirp.png)
+![](/assets/nom_chirp.png)
 
 Potentially using the metadata contained the dataset could be used the replicate the chirp from measurements. This could be used in range compression and this in turn improve the azimuth compression result. However, it is difficult for us to known in advance, how much of a difference it makes in practise.
 
@@ -68,7 +68,7 @@ Potentially using the metadata contained the dataset could be used the replicate
 The processor correctly(?) performs windowing for the range compression.
 
 An window is applied before range compression, the previous reference chip look like this after the window(but before scaling)
-![](../assets/window_chirp.png)
+![](/assets/window_chirp.png)
 
 This windowing is a standard DSP technique for pulse compression. The equivalent should be applied for azimuth compression. However due to the details of the of the azimuth compression(Doppler centroid, applying in frequency domain, rather than time domain) the implementation is more complicated.
 
@@ -80,7 +80,7 @@ Due to this the current version of the processor does not apply azimuth windowin
 
 After range compression, the intensity image of a range compressed image look something like this, with x-axis being range and y-axis azimuth direction.
 
-![](../assets/rc.png)
+![](/assets/rc.png)
 
 
 The core part of Range Doppler Algorithm is to perform azimuth compression in range-time and azimuth frequency domain and for this azimuth FFT is taken of this signal data. The current processor version always does the azimuth direction FFT in one block, meaning the FFT size is azimuth size + FFT padding. This simplifies implementation, however does not allow the implementation to vary Vr(radar velocity) in azimuth direction. An better approach would be to divide the azimuth into blocks, and take multiple smaller FFT that cover the azimuth aperture, to allow individual Vr estimate for each block.