<div dir="auto">Mr Parker <div dir="auto"><br></div><div dir="auto">I used RGB in my space. There is something called Mrsid.wig format </div><div dir="auto"><br></div><div dir="auto">Please forward me your s</div><div dir="auto"><br></div><div dir="auto">Regardless </div><div dir="auto">Sibonelo </div><div dir="auto">GtgGISc0817 </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Jul 2024, 18:35 Grant Slater via Africa, <<a href="mailto:africa@lists.osgeo.org">africa@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Aslam,<br>
<br>
Answers below...<br>
<br>
On Thu, 11 Jul 2024 at 14:20, Aslam Parker via Africa<br>
<<a href="mailto:africa@lists.osgeo.org" target="_blank" rel="noreferrer">africa@lists.osgeo.org</a>> wrote:<br>
><br>
> Good day<br>
><br>
> Can anyone please advise on recommended compression for 3 Band (RGB) 16 bit aerial imagery that is suitable in a photogrammetric workflow?<br>
><br>
> Also, is there a compression that can be recommended for 4 band 8 bit RGBNIR imagery that can be used in photogrammetric workflow. Although CD: NGI acquires 4 band imagery, it only orthorectifies 3 bands , due to the limitation of JPEG compression, which can only compress three bands.<br>
><br>
<br>
The simple answer is: It depends. There are Saving Performance / Image<br>
Quality / File Size / $$$ cost tradeoffs.<br>
<br>
Do you perhaps have an example of the workflow steps? Ideally with<br>
file load / save steps, because each additional save step is likely to<br>
increase compression artifacts.<br>
Could publish samples of the files in original format?<br>
<br>
Some initial thoughts...<br>
<br>
* ECW: is very common in the proprietary world, but I understand it<br>
has expensive licensing costs. I have no experience with it.<br>
* MrSID: as above.<br>
* JPEG (GeoTIFF): is open, widely adopted, quality / file size is<br>
poor. 12-bit not widely adopted/supported. YCBCR "RGB" only.<br>
* LZW, DEFLATE (GeoTIFF): are open, lossless, but huge file size.<br>
Likely option for intermediate steps.<br>
* ZSTD (GeoTIFF): open, lossless, but large file size. Likely option<br>
for intermediate steps.<br>
* LERC / LERC_DEFLATE / LERC_ZSTD (ESRI) (GeoTIFF): open, lossy /<br>
lossless, limited adoption.<br>
* JPEG2000  (JP2) is open, but software support is poor / mixed<br>
adoption / buggy.<br>
* JPEG-XL / JXL (GeoTIFF) is open, but has very limited adoption / buggy.<br>
* WEBP (GeoTIFF) is very good quality for small file size, Slow to<br>
compress. What I use for <a href="http://aerial.openstreetmap.org.za" rel="noreferrer noreferrer" target="_blank">aerial.openstreetmap.org.za</a><br>
<br>
Outside of compression:<br>
<br>
* Files should be internally tiled. For GeoTIFF this needs to be<br>
specified when saving.<br>
* Published / Archived files should not contain internal "overviews".<br>
This bloats the filesize by 20%+.  gdaladdo, QGIS or similar tools can<br>
create external overviews if needed.<br>
* Ideally RGB and NIR are published as separate files.<br>
<br>
Observations about the 25cm series that are being published:<br>
<br>
* Publish 1 file per grid square. Do not combine squares: eg:<br>
3217DD_23_3317BB_03_2022_1556_RGB_RECT.tif and<br>
2816DA_03_BC_23_2022_1584_RGB_RECT.tif<br>
The combined squares makes it more difficult for end users to find<br>
gaps and find missing files.<br>
Publish a list of grid squares which will / are available.<br>
Sometimes small bits get missed / not published:<br>
eg: 2420CC_01 was missed in 2022 Capture: 1669.<br>
eg: 2523AC_04 and 2523AC_05 were missed in 2021 Capture: 1447<br>
<br>
* Multiple rounds of Compression / Sensor issues?<br>
Quality seems to vary greatly. Output files are JPEG at Q95 or Q97 but<br>
it seems like during workflow the imagery has been over compressed and<br>
has severe compression artifacts.<br>
eg: 2729DD_05_2022_1712_RGB_RECT.tif (poor) vs<br>
2730CC_01_2022_1713_RGB_RECT.tif (ok)<br>
Example view: <a href="https://aerial.openstreetmap.org.za/#zoom=19&lat=-27.754098&lon=30.001725" rel="noreferrer noreferrer" target="_blank">https://aerial.openstreetmap.org.za/#zoom=19&lat=-27.754098&lon=30.001725</a><br>
<br>
* High number of published files are corrupt or truncated and<br>
therefore are unusable.<br>
eg: 3220AD_17_2022_1625_RGB_RECT.tif and 3325CB_24_2021_1437_RGB_RECT.tif<br>
<br>
* High number of published files use a different projection than the<br>
other files in the same 50k grid square.<br>
eg: 2624CC_06_2021_1455_RGB_RECT.tif and 2520AC_01_2022_1669_RGB_RECT.tif<br>
<br>
The imagery published by NGI is an amazing resource. Thank you!<br>
Next 5 year cycle 20cm? ;-)<br>
<br>
Kind regards,<br>
<br>
Grant<br>
_______________________________________________<br>
Africa mailing list<br>
<a href="mailto:Africa@lists.osgeo.org" target="_blank" rel="noreferrer">Africa@lists.osgeo.org</a><br>
You can UNSUBSCRIBE at <a href="https://lists.osgeo.org/mailman/listinfo/africa" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/africa</a><br>
</blockquote></div>