Add of a DXT1/3 to ETC1 renderscript transcoder

[nicastel]

The DDS with DXT1/3 texture compression is a format already available on some WMS. It will be cheaper and more efficient to trans-code from this format directly in the renderscript kernel at block level instead of using JPEG/PNG source that needs to be completely decoded then re-encoded.
The only drawback is that this can cause some additional artifact.

[ndorigatti]

but you want to download a dds from a device, and transcode directly to ETC1 via renderscript?
Why not leave DDS support to "GPU" of the device? DDS is also heavy in terms of kb...

[nicastel]

If a DDS with ETC1 can be downloaded directly from server it will be better but actually lot of nasa worldwind layers only have DDS with DXT available on servers. Transcoding from DDS DXT to DDS ETC1 will be faster than from PNG/JPEG but I have some doubt about quality so I need to try.

For the kernel code I will borrow this code http://www.ffmpeg.org/doxygen/2.0/s3tc_8c_source.html from FFMPEG lib.

[ndorigatti]

hi @nicastel , regarding this issue, my colleague is trying to create DDS with ETC1 compression via pure java appliication (after succesfully managed to write PNG2PKM in pure java), because of the transparency. But he told me he has problems of pictures not perfect and there should be a "tool" to check the textures. All the tools i've tryed are for DDS with DXT so, do you have or know a tool for such checks? Even if closed source and not java is welcome

[nicastel]

You put this comment on the wrong issue no? It should be on the "Handle Alpha band" one.

You have this one : https://code.google.com/p/crunch/
This lib can encode/decode DDS with ETC1 (I implemented the gdal/mapserver plugin with this one).

Just perform a checkout of the svn trunk, you will have precompiled binaries of the command line tool for windows/linux. If you have some trouble I have some binaries compiled for linux32 by myself also that I can provide.

[ndorigatti]

No no,i was referring to dds conversion, not to alpha handling! Thank for the answer,I will point him out!

[nicastel]

OK I understand. Well it is true that the quality of a conversion PNG -> DDS with DXT -> DDS with ETC1 can be verified with crunch before starting any implementation. If it is not OK with crunch I do not think we can do better.