Comments (12)
My plan is to make a new registration for image/ktx2 with new extension and "magic".
from ktx-specification.
I would like the option for a writer to create a file with a ‘.cttf’ suffix, even though it is a subset of KTX2. Would this require a mime type to be registered also?
Rationale:
I want for artists to recognize universal/supercompressed textures by inspecting/sorting just by file type. A ‘ktx2’ suffix could represent anything
from ktx-specification.
If you want browsers to be able to recognize the subset, another mime type will be required. If it's a different mime-type the underlying file may also a need different magic identifier. We should consult the IETF.
from ktx-specification.
Browsers don't care much about unknown MIME types: they will treat image/ktx2
and image/cttf
alike. I don't see a reason for a different magic value - an additional file extension should be enough for expected use cases.
from ktx-specification.
As long as .cttf aliases to ktx2, that's fine. I don't want to be adding extra MIME types if they're not required
from ktx-specification.
What is the reasoning behind adding a new extension for ktx2? I can understand maybe a separate extension as @dewilkinson points out specifically for supercompressed (though I'm not sure .cttf makes sense anymore since the glTF extension no longer calls anything cttf), but why ktx2? Is the version inside the header not enough?
from ktx-specification.
Because there are some platforms that rely entirely on file extensions to determine file type and because not every KTX loader can be relied on to support both KTX 1 and 2 given that 2 is not a superset of 1.
The .cttf idea was to identify KTX2 files that contained CTTF format data. We now have Basis Universal instead of CTTF but otherwise the idea is the same. I don't think this is necessary and would cause confusion as the MIME type would be the same as general KTX2 since there is no way to register 2 mime types with the same file signature (as far as I know).
from ktx-specification.
Because there are some platforms that rely entirely on file extensions to determine file type and because not every KTX loader can be relied on to support both KTX 1 and 2 given that 2 is not a superset of 1.
I think this line of reasoning is true for many files with a version in the header. Some thoughts:
- Loaders should be checking the version in the header and do appropriate things if it doesn't support it.
- File extensions with a number at the end to indicate the version doesn't seem very common.
- Coming from glTF, we have .glb for all versions (1 and 2 so far). Version 1 is not compatible with version 2 and likely neither will version 3.
- If a client supports both .ktx and .ktx2, this clients needs to register two similar extensions with the OS. If we ever have a 3rd version, will it be .ktx3?
The .cttf idea was to identify KTX2 files that contained CTTF format data. We now have Basis Universal instead of CTTF but otherwise the idea is the same. I don't think this is necessary and would cause confusion as the MIME type would be the same as general KTX2 since there is no way to register 2 mime types with the same file signature (as far as I know).
There is no rush for this as we can always add it later, but having a file extension that is more or less guaranteed to load on all platforms is much more compelling than a file extension that might or might not load depending on what is inside it.
from ktx-specification.
So @bghgary your recommendation is to use .ktx
for both versions? And you would like a different extension for BasisU compressed .ktx files? If we do the latter will you want a third extension for UASTC compressed files when they appear?
I need to check the ramifications of these changes on the MIME-type registration. My concern over .ktx is that KTX2 has supercompression which will require an updated security statement vs KTX 1. I suppose we can update the existing registration but I need to verify that. My concern over additional extensions is whether it is permitted for one MIME type to have multiple extensions.
For glTF, isn't using the khr_texture_basisu
extension sufficient indication that the texture will load, provided the extension is supported?
from ktx-specification.
your recommendation is to use .ktx for both versions?
I'm not sure I would say that's my recommendation yet. I want to know the pros and cons of each first.
And you would like a different extension for BasisU compressed .ktx files?
I don't have any specific need for this, but I can see the benefit of it.
If we do the latter will you want a third extension for UASTC compressed files when they appear?
Possibly. Or maybe we should wait until UASTC comes out to decide. I don't think we should do anything yet. Let's agree on .ktx vs .ktx2 first.
For glTF, isn't using the khr_texture_basisu extension sufficient indication that the texture will load, provided the extension is supported?
I'm not looking at this from a glTF perspective. I'm looking at this from a standalone .ktx (or .ktx2) file. If you try to open it in a file explorer of some kind, the question is whether it is better with (.ktx and .ktx2) or just .ktx
from ktx-specification.
This issue is a little old, but there is now an official registration.
*.ktx2
is registered to image/ktx2
from ktx-specification.
Thanks for noticing this is fixed. Closing.
from ktx-specification.
Related Issues (20)
- No support for edge clamp mode and filter mode? HOT 2
- The example file in the spec is invalid with regards to `dfdByteLength` equalling `dfdTotalSize`.
- Confirm prohibited formats HOT 3
- Confirm KTXwriter and KTXwriterScParams encoding HOT 1
- Consider rephrasing format mapping metadata usage HOT 1
- Clarify compressed formats for 1D textures HOT 1
- Confirm mipPadding size HOT 8
- Relax DFD transfer function restrictions HOT 2
- KDF_DF_* vs KHR_DF_* HOT 1
- Please rename default branch from 'master' to 'main' per Khronos policy HOT 1
- Reserve vendor ID for super-compression scheme HOT 3
- Investigate GDeflate supercompression HOT 3
- Definition of 'num_blocks_x' lacks max(1, ...) ? HOT 1
- Chosen source (syntax) highlighter, prettify, is no longer maintained. HOT 1
- Disallow two-plane 444 formats
- typeSize spec for formats with suffix _nPACKxx is wrong
- Allow A8B8G8R8 formats HOT 2
- Confirm R16G16_S10_5 support HOT 17
- Generated format switches not including many Vulkan formats in 2glFormat and 2glType HOT 4
- Some supported formats are not included in the mapping appendix HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ktx-specification.