feature/custom-overlays-updated

[ted-at-rtr]

I had difficulty trying to merge my updates into the features/custom-overlays branch - that branch had the main merged into it at some point, and for some reason it just would not build for me, even after a fresh clone.

The easiest thing for me to do was to start a new branch from the head of the main branch (1.y), and manually merge in the Custom Overlays feature.

Thus, this branch contains the initial development of the Custom Overlays feature, plus the following fixes:

• UI latency fixes:
  • Load custom overlays via web workers
  • Create Custom Overlay layer immediately.
• Support vanilla TIFFs, but warn about needing to add projection/extent.
• Support Palette bands.
• Support UInt16 RGB

The code now displays all the GeoTIFFs you provided so far, (with the appropriate modifications to the metadata files when necessary). I'll email a .zip with my test images and their metadata as an FYI.

Notes regarding the UI latency issues:

• Previously, when reloading the JCC page, the Custom Overlays feature sequentially loaded the most recent overlay selections. If the overlays were large, this froze the UI at various times. Furthermore, the "Custom Overlays" entry in the layer switcher did not show up until all the selected overlays were loaded.
• Now, the UI will almost immediately add a "Custom Overlays" entry to the UI switcher (but only if there are custom overlays present), and it will populate the checkboxes per the most recent overlay selections. However, the overlays are loaded and displayed in the background. During this time, the UI largely reacts normally (i.e. no freezes), but there can be 2-3 pauses per image (the duration of these pauses depends on the size of the overlay) and the UI can appear a bit sluggish (again, depending on the size of the overlays).
• The zurich.tif file is huge - it's raster is ~1GB, and internally it requires ~3 copies of the raster so it causes the Chrome process to take ~+3GB during its construction (Chrome frees this up after a couple of minutes.) It takes ~1 minute to load (on my laptop), and the 2-3 pauses are no longer than about 4 seconds. After the zurich overlay image is loaded, the UI is noticeably sluggish when the zurich overlay layer is on screen, particularly during zoom operations. I believe that this occurs because the image is being re-sampled and re-projected at every zoom level; I have no control over this.
• The tech behind the recent changes is: "web workers". The geotiff NPM package already supported web workers for image decompression and decoding, but I needed to enable it. When web workers are enabled in the geotiff module, by default it will allocate one worker per CPU core on your machine. Instead, we use 2 less CPUs for the decoder and give those CPUs to the code that transfers the decoded raster to the image canvas and adjusts it (for min/max scaling, colorization, inversion, etc.). At the current settings, the geotiff module decode time and the raster transfer time are roughly equal, so I think the balance is proper.
• You can see the web workers in the Chrome Task Manager (Shift-Esc). The workers appear when needed and are deallocated after 30 idle seconds.
• The reason the GeoTIFF image decoding is sluggish: All this code is in JavaScript. There is a "fast GeoTIFF" NPM package out there that boasts a 10x improvement by streamlining the code and using Web Assembly where necessary. That is the correct solution to this problem. However, that fast NPM package is underdeveloped (and not suitable for our use in its current form), and it is downloaded less than 10x per week (compare to the geotiff NPM package we are using that is downloaded >100,000x per week). The point here is that getting custom overlays to be faster for large TIFFs could be challenging.

Last, if/when this pull request is accepted and merged, we should additionally delete the features/custom-overlays branch and PR.

[michael-jaia]

For original code and comments see: https://github.com/jaiarobotics/jaiabot/pull/833

[michael-jaia]

Ted, thank you for making these changes. The code handled the TIFFs very well. I tried a variety of GeoTIFFs, TIFFs, and PNGs. The final test was creating a TIFF from Google Earth of the Bristol office testing area (this video is great for creating GeoTIFFs: https://www.youtube.com/watch?v=USOARDNEdg0), and it loaded smoothly and fit the map with near perfect precision.