JP2Grok: let Grok handle jp2 box read/write

[boxerab]

What does this PR do?

The current JP2Grok driver handles read, write and rewrite of JP2 boxes. This PR allows Grok to handle read
and write (not re-write), as it is more efficient to let the codec itself manage the boxes.

No new unit tests have been added as the existing ones will test these changes.

AI tool usage

• AI (Copilot or something similar) supported my development of this PR. See our policy about AI tool use. Use of AI tools must be indicated.

Tasklist

• Make sure code is correctly formatted (cf pre-commit configuration)
• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed

[rouault]

I'm skeptical about the added benefit vs maintenance overhead. Would you have done this PR without AI assistance? They are pretty good at cluttering code bases...

[aaron-boxer]

I'm skeptical about the added benefit vs maintenance overhead. Would you have done this PR without AI assistance? They are pretty good at cluttering code bases...

I hear your point, I appreciate your rapid code reviews, and don't want to flood the project with PRs. My plan, which is now easier with AI help, is to shift as much functionality as possible away from the driver and into the codec. Since Grok is already parsing the metadata, it isn't efficient to have the driver duplicate this effort with a second parse.

After this PR, and a second one to shift Box rewrite to the library, there won't be any more significant code churn on the driver. Just bug fixes as they show themselves.

[rouault]

My plan, which is now easier with AI help, is to shift as much functionality as possible away from the driver and into the codec

yes but that actually turns into more code being written... I'm a bit skeptical about the performance impact of doing the JP2 boxes analysis twice. Is that significant compared to actual JPEG2000 decompression... ?

[boxerab]

My plan, which is now easier with AI help, is to shift as much functionality as possible away from the driver and into the codec

yes but that actually turns into more code being written... I'm a bit skeptical about the performance impact of doing the JP2 boxes analysis twice. Is that significant compared to actual JPEG2000 decompression... ?

You're right, there is more code. The way I see it is:

1. this is a micro-optimization : it's not a significant perf hit to parse twice, but when combined with other micro optimizations, it begins to add up.

2. we get more separation of concerns: the driver is mainly passing metadata and pixels back and forth, and letting the Grok library worry about the details of the codec implementation.

3. we can support transcoding: with box rewriting, we can add support for Grok transcoding: the library can, among other things, add PLT, TLM and SOP/EPH markers, or change progression. No new GDAL API is needed as the driver can simply detect when input and output are both JP2 and do the transcoding.

4. the code is already written, tested and will be maintained by me

And, as I said, there only a few more iterations needed on the code and then it will enter maintenance mode.

[boxerab]

@rouault I have reworked the PR to minimize code changes - it still avoids reading the JP2 header twice in the JP2Grok driver.

[aaron-boxer]

Thanks for the reviews and merge!