Comments (15)
The KTX spec. requires an sRGB OETF (transfer function) for _SRGB formats as explained in the error message. If you really want linear, use --format R8G8B8
.
We have discussions underway re clarifying handling of OETF and primaries in the tool and adding support for not-KHR_DF_TRANSFER_LINEAR OETF
s for non-_SRGB
formats which is allowed by the spec. The documentation will be updated as part of that work.
from ktx-software.
Oops. In my example above, I failed to include the --encode
parameter. (Now edited to correct this oversight).
With that correction, I don't understand your answer:
--format
is documented that if "when used with --encode it specifies the format of the input file before the encoding step." (emphasis mine).--convert-oetf
is documented as indicated above. That it can be different from the transfer function of the input file and that difference is sufficient to cause a conversion from the assigned tf to the tf specified by this option.
Based on that, I drew what seemed like very direct, obvious conclusions:
- My
--format
should reflect the format of my input file (which is sRGB). - I can get ktx to convert transfer functions so that my output file is in linear space.
Can I not convert an input sRGB file to an output linear file?
What have I misunderstood in the documentation? The language seems very clear, but inconsistent with the error message.
from ktx-software.
@aqnuep do you have any comment?
from ktx-software.
--format is documented that if "when used with --encode it specifies the format of the input file before the encoding step." (emphasis mine).
Maybe the description needs to be clarified, but the format in this case should still respect the target color space in the sense that for a linear target transfer function you need a non-SRGB format. It matters even if you further encode the texture with BasisLZ, as the image is first converted to the target format (e.g. R8G8B8A8_UNORM) and then encoded with BasisLZ.
from ktx-software.
Certainly clarification of the documentation would be an acceptable way to resolve this. Your responses are certainly painting a different picture from what the documentation claims. So, without some clear reference to the documentation and how I misread it, it suggests a defect in the documentation. I look forward to seeing how the discussions resolving transfer functions play out.
But, putting aside the question of documentation correctness (as, regarding this issues, it appears it can't be trusted), I'll reiterate my core question:
Can ktx be used to convert input sRGB into output linear?
from ktx-software.
Yes, ktx can be used to convert (PNG) input sRGB to linear output.
If the input PNG file already has an sRGB color space encoded, and the target format is a UNORM one then the conversion will happen automatically. If you're not sure the input PNG file actually has the sRGB color space encoded in it, then you can use --assign-oetf srgb
, as you tried to treat the input PNG file as having sRGB color space. Also, the way you use --convert-oetf linear
to force the conversion to linear is correct. Only the --format
was misused (understandably due to the ambiguity in the documentation).
from ktx-software.
One thing I forgot to mention is that if you do want to convert sRGB to linear and you do specify the --assign-oetf srgb
to force the input you also have to force the conversion with --convert-oetf linear
, because assign-only, without convert, means that you simply override the OETF without wanting a conversion to happen.
from ktx-software.
If you look at the original post (with the correcting edit), you'll not I did both --assign-oetf srgb
and --convert-oetf linear
(as suggested by the documentation) and still got the error message. So, maybe there's more defect than just the documentation?
from ktx-software.
If you look at the original post (with the correcting edit), you'll not I did both --assign-oetf srgb and --convert-oetf linear (as suggested by the documentation) and still got the error message. So, maybe there's more defect than just the documentation?
But you also specified --format=R8G8B8_SRGB
instead of --format=R8G8B8_UNORM
, which is the root cause of the error.
from ktx-software.
I feel like I'm walking around in circles. Of course I noted --format=...SRGB
because that is documented to specify the input format when --encode
is specified. But the error seems to arise from the fact that it disagrees with the requested output oetf.
from ktx-software.
--format
is not the input format, it was just ambiguously defined in the help text, as it's only the "input format" of the encoding, and in fact it's really the target format, that just happens to be encoded afterwards.
We already fixed the help text and man page. Please just change the command you use as follows and it should work:
ktx create --encode=basis-lz --format=R8G8B8_UNORM --assign-oetf=srgb --convert-oetf=linear foo.png foo.ktx2
from ktx-software.
I fear there is still a basis of disagreement.
I have a wood-grain png. When loaded it appears (as the attached image shows):
When I run the following
ktx create --encode=basis-lz --format=R8G8B8_SRGB --assign-oetf=srgb --convert-oetf=srgb foo.png foo.ktx2
I get this appearance. This is what we would expect. One can see some compression artifacts, but the color space has been preserved.
However, when I run your command:
ktx create --encode=basis-lz --format=R8G8B8_UNORM --assign-oetf=srgb --convert-oetf=linear foo.png foo.ktx2
I get the following image.
My interpretation is that the --format
is definitely being associated with the input data. The sRGB
values are being misinterpreted as unnormalized linear and, therefore, when I output the linear
result, it's dark.
What am I missing?
from ktx-software.
When you request the conversion from sRGB to linear, obviously, the data will change, because you decode the sRGB values into linear values. By default, transcoding BasisLZ into RGBA will lead you an R8G8B8A8_UNORM image (currently there's no control over this in libktx IIRC).
In the end what matters is whether you present the RGBA texture resulting from transcode through a linear or an sRGB view (which you did not specify here). It is difficult to judge what's happening without knowing the full pipeline you use to achieve these images.
from ktx-software.
Sorry for this tardy delay.
Thanks for your patience and help. We've got it all up and running and your last note was 100% correct and I was misinterpreting the rendering results. Thanks again.
from ktx-software.
Glad you resolved it, @SeanCurtis-TRI.
By default, transcoding BasisLZ into RGBA will lead you an R8G8B8A8_UNORM image (currently there's no control over this in libktx IIRC).
The transcoder selects _SRGB if the DFD's transfer function is sRGB, and there is an SRGB variant of the chosen transcode target, otherwise it selects _UNORM.
from ktx-software.
Related Issues (20)
- Allow A8B8G8R8 PACK32 formats
- Loading KTX1 and KTX2 file on Linux/OpenGL 4.3 leads to weird error if not luch the program with sudo HOT 4
- Project install installs fmt lib HOT 1
- Preceding `ktx` command name with option leads to error HOT 1
- WebGL test gets shader compile error
- samplePositions possibly incorrect for single-plane 4:2:2 YUV formats HOT 4
- The JNI binding for input swizzling is broken
- No option to apply `zstd`/`zlib` compression via JNI HOT 21
- Improvements for the Java/JNI bindings HOT 4
- Synchronizing auto-generated files with bindings HOT 2
- How to call `CreateFromMemory`? HOT 2
- Memoy leak when ktxTexture2_DeflateZstd fails
- Running in docker container (GLIBC not found error) HOT 2
- CI build scripts prevent local use with test updates by initializing CTS submodule
- Skipping mipmaps when loading from disk HOT 2
- The execution speed of the ktxTexture2_CompressBasisEx method is quite slow HOT 15
- No definition for ktxTexture2_Destroy in ktx.h HOT 3
- Enabling Automatic Mipmap Generation Causes Validation Error HOT 1
- ktxTexture_SetImageFromMemory should document pointer lifetime guarantees HOT 2
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-software.