Add support for Apple KTX format
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- csharp
- Domain
- computer-graphics
Research direction
Start by reviewing the ImageSharp.Textures code and the proof-of-concept commit, then inspect the linked LzfseSharp implementation and the existing ASTC support. Done means loading the documented Apple KTX chunks, decoding the LZFSE payload, and exposing the result as standard ASTC texture data despite the unpublished format specification.
Written by the indexing model from the issue text.
Description
Would there be any interest in adding support for the Apple KTX format? It would be very useful, at least for us, to be able to use this directly in ImageSharp. I saw that a request for adding support for CgBI images (another internal Apple image format) had been accepted, and this is a very similar situation.
It is a supercompressed variant of KTX1 using LZFSE. Once decrompressed from LZFSE, the textures can be decompressed as a standard ASTC compressed KTX texture.
The main challenge would be incorporating an LZFSE decoder in ImageSharp.Textures. I have an implementation that could, with a little improvement, be incorporated in ImageSharp.Textures as I have done for ASTC. LZFSE is thankfully a lot simpler and the scope is therefore much smaller than ASTC.
The other challenge is that this is an internal Apple variant with no published spec (that I could find).
I have made a proof of concept implementation: https://github.com/Erik-White/ImageSharp.Textures/commit/163f828bd9801917e5fd542e59a1fff5f37c8c17
Layout
[8 bytes] Magic: AAPL\r\n\x1A\n (0x4141504C 0D0A1A0A)
[chunks] Sequence of tagged chunks until end of file
Each chunk has an 8-byte header:
[4 bytes] Data size (little-endian uint32)
[4 bytes] Identifier (ASCII, e.g. "HEAD", "LZFS", "FILL")
[N bytes] Chunk data
HEAD chunk (84 bytes) contains texture metadata. Key fields at byte offsets within the
chunk data:
| Offset | Size | Field |
|---|---|---|
| 16 | 4 | Internal pixel format (OpenGL enum, e.g. 0x93B0 = ASTC 4x4) |
| 24 | 4 | Width |
| 28 | 4 | Height |
| 32 | 4 | Depth |
| 36 | 4 | Number of array elements |
| 40 | 4 | Number of faces |
| 44 | 4 | Number of mipmap levels |
LZFS chunk holds the texture payload. The first 4 bytes after the chunk header are skipped,
and the remainder is LZFSE-compressed ASTC block data.
- Dominant language
- C#
- Stars
- 67
- Forks
- 17
- PR merge metrics
- No merged PRs in 30d
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SixLabors/ImageSharp.Textures
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
SixLabors/ImageSharp.Textures#14 · 3 comments ·
-
KTX2 supportOpen
Difficulty 5/5 Over a week Newbie friendliness 25/100
SixLabors/ImageSharp.Textures#3 · 5 comments ·
All issues in SixLabors/ImageSharp.Textures
Similar issues
-
area-ai untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
dotnet/extensions#7790 ·
Maintainers usually reply within 1 day
-
P2 testing
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
area-Infrastructure-coreclr os-ios os-maccatalyst os-tvos untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
dotnet/runtime#134766 · 3 comments ·
Maintainers usually reply within 1 day
-
0 - Backlog Bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
BrighterCommand/Brighter#4444 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day