Conversation
| const tile = await self.image.getTile(x, y, options); | ||
| if (tile === null) { | ||
| throw new Error("Tile not found"); | ||
| } |
There was a problem hiding this comment.
We might still want to have a relevant check for whether the tile/band being fetched is in the range of the image.
There was a problem hiding this comment.
Do we get this from the check below?
const result = await self.image.getBytes(offset, imageSize, {
signal: opts.signal,
});
if (result === null) {
throw new Error(
`Band ${b} tile not found at index ${tileIndex}`,
);
}Sorry for the question w/o the answer, I'm still building my mental model here.
|
As a general comment, I think this PR sounds good to set the default decompressor to fzstd, since it says it's only 8KB as a dependency. And then we should document and allow end users to override with a WASM-based zstd dependency if they prefer. |
Something like 653cf42? |
No I think that's extra unnecessary complexity.. We can export the decoder registry from global scope. And then the user can just do registry.set(Compression.Zstd, () =>
import("user-defined zstd module").then((m) => m.decode),
);Or, if they want to always import the module, they can do import { decode } from "some-zstd-decoder";
registry.set(Compression.Zstd, () => Promise.resolve(decode));I think it's probably safe to assume that users won't want different decoders for the same compression type for different images. I.e. it's fine for decoders to be a single registry in global scope. |
|
@gadomski can you split this PR into two? One for adding ZSTD and a separate PR for loading band-separate data? |
Done: #276 |
|
|
||
| [LERC]: https://github.com/Esri/lerc | ||
|
|
||
| You can also override the built-in decoders with your own by using `registry`. For example, to use a custom zstd decoder: |
No description provided.