Support grayscale (ZeroIsBlack)

[mdsumner]

See #172 and so we can point at gebco and obvious range scaling

https://source.coop/alexgleith/gebco-2024/GEBCO_2024.tif

[kylebarron]

Yes, this will be pretty simple. Just needs an extra case here:

deck.gl-raster/packages/deck.gl-geotiff/src/geotiff/render-pipeline.ts

Lines 222 to 225 in 807be9e

	default:
	throw new Error(
	`Unsupported PhotometricInterpretation ${PhotometricInterpretation}`,
	);

We can create another module like the above cmyk/ycbcr/etc modules for converting the grayscale single-band to 3-band rgb grayscale

[mdsumner]

I'll PR this one, I got close to it just needs to be next week 🙏

[kylebarron]

That would be great!

I'm bad at it so far, but I'd like to add small (as small as possible) versions of COGs into the test fixtures so that we can test the default image render pipeline creation with different images. See https://github.com/developmentseed/deck.gl-raster/blob/main/packages/deck.gl-geotiff/tests/render-pipeline.test.ts

[kylebarron]

See #179

[kylebarron]

@mdsumner With #179 and #182, and #180 I think your image might be able to be viewed.

If you want to test it out on a dev branch that merges those three together, be my guest.

I'd ideally like to have some sort of test for each of those PRs in isolation so that we have better certainty.

My time is super limited right now because of jury duty. If you'd like to help:

• Do you know of an example image we can add to tests for this issue? I.e. a one-band uint8 GeoTIFF that lets us test that grayscale rendering is working?
• Do you know of an example image that spans -90 to 90 in latitude (but is small and we could add to tests) to validate fix: Clamp to Web Mercator latitude bounds #182

Or, maybe I should get better at GDAL, and then we create fake data just for the tests.

[mdsumner]

ah, I had to warm into this a bit again ... with a full-globe longlat tif I see tile issues, with an Australian Albers image it works fine, butwith a polar (IBCSO) subset image it doesn't recognize the specific EPSG 9354 (... because proj4js doesn't ship with proj.db support - hence #185 ).

I'm not super au fait with the the workflow but I was able to merge those 3 PRs and build and host it but having non-definitive feeback still - a thing that would help me most rn is the ability to input a COG url

const params = new URLSearchParams(window.location.search);
const COG_URL = params.get('cog') || 'https://projects.pawsey.org.au/image-cogs/images/IBCSO_v2_digital_chart_bl.tif';

Would you like to convert cog-basic to allow that? Maybe keep undocumented, but harmless so we can test without duplicating much.

I will continue to explore and create test COGs and share a meaningful set. But, in terms of a test fixture the GDAL approach is something like:

 gdal pipeline ! read  /vsicurl/https://data.source.coop/alexgleith/gebco-2024/GEBCO_2024.tif ! clip --bbox -180,-85,180,85 ! resize --size 512,256 ! write --of COG --co COMPRESS=ZSTD --co OVERVIEW_COUNT=3  /tmp/mycogs/gebco_boxmerc_512.tif 

(the default overview calc won't create any because the raster is so small) when it's considered workable replace /tmp/ with the '/vsis3/mycogs/' path and the env vars for auth/config opts ). It's somehwat easier to use 'reproject' (or gdalwarp) because you don't have to pipe line combos of output properties - crs/bbox/size/resolution - they are all optional and specifiable for a one step convert. I'll keep notes and share.

[kylebarron]

When I test a new COG url, I just swap out the const value of COG_URL in the cog-basic app.

[mdsumner]

Ok but why not have a general one that users can try and give feedback with? I think I'm just not familiar enough with the workflow/s, I'll pull back and explore more

[mdsumner]

Oh, because someone has to maintain that ... ok, yeah. I need more exp with this 🙏