Option -mipmax without effect about kram HOT 14 CLOSED

Great. Make sure that you use the zstd or zlib compressors in kram with ktx2. That way you can ship the textures, and only decompress mips slowly as needed. For example, on low end, you could drop the top mips. The loader in kramv is an example of how to do loading. There isn't a great ktx2 setting for tiling for partially-resident textures, so entire mip levels must be decompressed at a time. But PRT have platform-specific tile size requirements (usually 256x256 for BC).

from kram.

Hmm, that should all be handled here. I use it to gen all the test image with -mipmax 1024

KramImage.cpp, line 1539.
dstImage.initMipLevels(info.doMipmaps, info.mipMinSize, info.mipMaxSize, info.mipSkip, mipConstructData.numSkippedMips);

from kram.

Try it with lastest source. I didn't tag the build yet, so the prebuilt versions don't have the change yet. I think the addition of mipskip broke the mipmin/mipmax handling. Seems to be working. If you set -v, that enables verbose mode so you can see the mips generated.

from kram.

Thank you very much for looking into it so quickly!

I've built the latest source, but its usage gives me some interesting results.
The resulting .ktx2 file is just 544 Bytes large and kram viewer says when opening it:

"Could not load file from
basecolor.ktx2
mip sizes arent' equal"

Opening the file with an older version of kram viewer just shows black, but in the info it shows the desired mip size of 1024.
When omitting the -mipmax option, the latest build produces the same kind of unreadable ktx2 files.

v 1.5.2 works fine here - except for -mipmax.

from kram.

kramc wasn't updated in the cibuild.sh script. I've updated that on main for now. I also noted that ktx2 are opening as black, but I though that was before my fix. Try the latest sources and/or build when it finishes. Also the encode times look terrible of late on ASTC/ETC, but BC7enc is okay. I'll take a look at this more today.

I've been breaking out the KTX1/2 save code so that another dev could go from dds to ktx/2. I hope that hasn't led to some of the ktx2 issues.

from kram.

The issue remains here - .ktx2 files still show as black and they are just 500 bytes large, even if they should contain 4k textures.

It's probably related to the KTX1/2 save code indeed, I guess with this commit right after the 1.5.2 release: 0565bb1

from kram.

Having some technical difficulties with xcodebuild not updating kram or kramv in the bin folder. I'm working on that first. I think once those are in sync, that should help. Then I'll take a look at the ktx2 export.

from kram.

Okay, cibuld.sh scripts that prebuild kram and kramv.app are now working. xcodebuild has so many bugs. Now I'll try to see if ktx2 is displaying as black. The thumbnails should work from Finder, but the preview.appex code isn't working yet.

from kram.

Okay, I think everything is working now. The thumbnails for ktx/ktx2 are fine, and when I open the files all the mips are correct. Preview (hitting space on an image) is still all black. I need to figure out why the preview.appex extension is failing, but there's very little documentation on how to make this work.

Remember that if you build kramv from source, you need to copy it from the bin folder over to /Applications. The easy way to build is go to the root folder, and call the following. This builds the release copies of everything into the /bin folder and then zips them up. There's a similar option for "win" using MSVC.

./scripts/cibuild.sh macos

from kram.

Previewer is now fixed, but it wasn't working since I first wrote it. So that should hold kram and kramv over for a while.

Still need to hook HDR data to the BC6H encoder, and there are several other features I want to finish. Also thumbnails with alpha look off like ColorMap-a.ktx. I think the thumbnail is blending against some garbage.

from kram.

Thanks for the update, (nearly) everything seems to work fine now!
Good to have a kram executable for mac in the release, which is certainly very comfortable for some users (including me :).

It's still the ktx2 conversion which stopped working completely here after 0565bb1
I have tested converting to ktx2 with both kramc built from source and with the released executable in 1.5.9 (all on an Intel Mac).
But kramc is just producing kind of "empty" ktx2 files of a few bytes in size from large 4K input textures.
Converting to ktx1 or dds works fine in contrast.

from kram.

I have a repro on that. I was testing ktx, but you're right the ktx2 path is somehow bust.

from kram.

Should be fixed now. My test ktx2 file works. I was referencing a dummy variable in splitting that call off. Now it's using the src KTXImage.

from kram.

Perfect - ktx2 conversion is working fine and with mipmax support. Thank you!

from kram.