nicastel / renderscript_texture_compressor Goto Github PK

ETC2 is the improved successor of ETC1 and it will be soon available on all new Android terminals. It will be interesting to add a compressor for this format. The algorithm basic principle are very similar so it should not be too much difficult to implement it.

Reference :
http://www.jacobstrom.com/publications/StromPetterssonGH07.pdf
http://www.graphicshardware.org/previous/www_2007/presentations/strom-etc2-gh07.pdf
https://www.khronos.org/assets/uploads/developers/library/2012-siggraph-opengl-es-bof/Ericsson-ETC2-SIGGRAPH_Aug12.pdf

The DDS format can perfectly handle an ETC1 texture (with the FOURCC "ETC1" in the header) since the size and structure (4x4 pixel block encoded as 64 bit) is exactly the same as DXT1.

The DDS format as some advantages over PKM : mipmap in the same file, texture array (to have 2 textures ETC1 in the same file : 1 RGB / 1 ALPHA).

Handle alpha band via "ETC1(RGB)+ETC1(ALPHA)" as adobe did in ATF : http://wiki.starling-framework.org/manual/atf_textures#creating_an_atf_texture

Most of ETC1/ETC2 tool use the KTX file format : http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/

Supporting this format will make easier quality/performance comparison and the exchange of data with others library/tools.

The addition of mipmap could be easily added but it comes with an important degradation of performance in the renderscript implementation (remark : not in the Java one).

The simple solution is to call the renderscript kernel for each mipmap level but each call have a cost that become prohibitive and even bring lower performance than the Java implementation for smaller level.

Hi @nicastel , I'm looking at this wonderful repo to find out if it could be possibile to write to a file the ETC1 compressed texture as pkm format instead of writing the PNGs.

I have done a swing application that from a GEOTIFF creates the tiles for worldwind but it writes PNG files.
Since in the worldwind app, PNGs must be read, compressed and then showed, I'd prefer to compress the tiles in the desktop app since it is made one time only (the app will be offline, so tiles are prepared in desktop app).
I am looking at the pure Java implementation but i see that in the file ETC1Benchmarck.testJavaETC1ImageCompressor
you have a "testing purpose" file writing that states:

if (texture != null) {
int estimatedMemorySize = ETC1.ETC_PKM_HEADER_SIZE+ texture.getHeight() * texture.getWidth() / 2;
File f = new
File(Environment.getExternalStorageDirectory(),"bmngpkm.pkm");
f.delete();
f.createNewFile();
ETC1Util.writeTexture(texture, new FileOutputStream(f));
System.out.println("Texture PKM created ");
}

Do you think we can make ETC1Util.writeTexture available for Swing Application too?
I was looking at what the method does
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/android/opengl/ETC1Util.java#ETC1Util.writeTexture%28android.opengl.ETC1Util.ETC1Texture%2Cjava.io.OutputStream%29
and it seems to rely on "convertable" code, but two functions are native:
ETC1.formatHeader and ETC1.getEncodedDataSize

from your expertees and knowledge, do you think is feasible or do you have already tried/done it?

The signature method of ETC1Util can be changed from:
(ETC1Texture texture, OutputStream output)
to
(ByteBuffer dataBuffer, int width, int height, OutputStream output)
and all the references to ETC1Texture on desktop are removed, but I'm scared about those native methods.

Many Thanks,
Nicola

Here is the problem found during integration with WorldWind :

I have found some texture corruption problem when using the client side renderscript compressor. They are mostly visible when you tilt the view (with a very strange effect) wich means this is mot likely due to some problems during mipmap compression. For the time being it is better to deactivate client side texture compression by putting :
.jpg in BMNGWMSLayer.xml and EarthElevationModelAsBil16.xml

There is no such problem with server side on the fly compression with Geoserver (based on my JavaETC1) and Mapserver (based on gdal/crunch)

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.