Now i am kind of confused do we discuss in forum or in wikipage?
LOL - lets keep it to the forum.
Fallbacks: Although S3TC is present on all recent desktop hardware, PVRTC and ETC are specific to their respective hardware vendors, neither of which support S3TC. Do we provide a fallback which decompresses these formats in software if they are not supported by the current hardware? Do we provide a way for the application to query the supported compression formats at runtime?
Usually there is also hardware support for S3TC (or a subset of the 5 formats) it is just more efficient to use PVRTC or ETC in those platforms.
Most OpenGL ES1.1 hardware doesn't have ST3C, although that may change as ES 2.0+ becomes common.
If the developer is going to use textures at least one of these formats "has to be" (usually is) present in hardware, a software fallback may not be necessary, I would defer this effort for another time if someone needs it.
The ability to query what formats are available at runtime is a very nice feature, i would like to have it, even if most of the time the developer will know ahead of time what formats the platform can handle and will accordingly compress the image data using the appropriate methods.
This requires that the developer use a separate art pipeline for each target device - fair enough.
Containers: Several of these formats have multiple containers, and some containers can contain multiple compression schemes. Which format/container combinations do we want to support?
This is a tricky question, without knowledge of a specific context. In presence of multiple options the support for the fastest and support for high-quality settings provides a nice duality. The thing is, in certain contexts the one format that balances both features is usually optimal (or not, but if it's not available you can't really tell, tricky).
As a specific example, Apple and PowerVR both provide a wrapper format for PVRTC, and a toolchain to produce them. Although they use the same compression, the wrapper format is non-compatible, and supports slightly different features. The Apple tool runs only on Macs, while the PowerVR tool runs only on Linux and Windows.
Support for all formats and containers, would be ideal. However, prioritization by fastest/highquality on a first phase would be enough for most use cases!?
Speed/quality isn't really an issue. However, I do wonder how people would feel about rolling this out of the engine entirely?
I am talking about building a Horde3D-specific (though the format would be open, of course) wrapper format, which can hold all types of compressed/uncompressed image data (uncompressed, RLE, JPEG, S3TC, PVRTC, ETC, etc.). There would be a tool that leveraged FreeImage (or similar) to convert/batch convert other image formats into the Horde format, which would move this whole issue out of the engine and into the content pipeline.
I have a feeling it is too big of a break from tradition to be well received - but it is the approach taken by the WildMagic engine.
Regarding mipmap generation - should it always be done ahead of time, in the art pipeline? Or should there be support for generated mipmaps at all levels (this means additional extensions, and additional work).
All levels, I am afraid. if you are I/O bound, you want to generate them on the fly, CPU bound you want the pre-calculated. You may need to tweak them manually in the content pipeline, or you may need to modify the quality at load-time.
Is there a need to support a heavier image library like freeimage? Is this desirable?
FreeImage doesn't offer anything apart from .PSD support, over what we have already - and it doesn't have mipmap generation or DDS support, last I checked.