No need to write out alpha in a RGBA color when only
the RGB values are used by the distance op.
Also, add a comment on the byte order. Maybe I'm wrong
but I believe the operations are fine wrt. byte order :)
There is still some C99 code in the file in the form of
for (int k = 0; ...)
If there's a strong requirement not to use this form, I'll
change it, otherwise I find this specific code style more
readable (k is local to this iteration).
This patch and the previous one even give a ~10% speedup
on the encoding time. Sweet :)
So I guess always compiling with debug flags and no
optimizations isn't the best idea as some really bad warnings
can be hidden. Thanks raster for the notice.
And this completes the first version of this ETC2 encoder.
It's pretty slow and not exhaustive.
Color selection for T and H modes could probably be optimized
for both performance and quality. As for the planar mode, there
is no selection to speak of, as we just take the values of the
pixels directly (no scan, very fast)
On a sample image with lots of blue, white and noisy gradients,
T+H+Planar mode boost the PNSR from 41.22dB to 42.01dB.
Without planar mode, the PSNR was 41.94dB.
@feature
In this mode, two colors are encoded in RGB444, a multiplier and
distance (index) are selected. Two extra colors are extrapolated
from the main base color. As in ETC1 we have 4 base colors to paint
our block.
@feature
Implement Alpha encoding, brute force way, but doesn't scan
all possibilities either (only based on average alpha).
RGB encoding is still entirely left to the rg-etc1 encoder.
T, H and Planar mode will come in the next commits.
@feature: Implement an ETC2 encoder from scratch for RGB8 and RGBA8
Summary:
Mainly from the examples but also from libunibreak and tests/eet.
I'm not sure if it's really worth to remove warnings from the examples
-- because it adds pedantic-ness to something supposed to be didatic,
but I leave for you guys to judge.
Reviewers: tasn, cedric
CC: felipealmeida, raster, smohanty, cedric
Differential Revision: https://phab.enlightenment.org/D896
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Evas uses BGRA data while rg_etc1 uses RGBA data, so there
were incompatibilities between the two.
Now, rg_etc1 will take BGRA data as input and output.
So I must have been a bit tired last Friday when "fixing" some
code producing artifacts, as I was just basically disabling part
of the code without realizing it :)
Let's just disable it then.
Add some comments as I'm reading and understanding the code.
Fix some rare artifacts happening mostly with medium quality
encoding, where a few pixels (2x2, 2x4 or 4x2) will have a
horrible contrast with their surroundings (eg. pink over black).
The ETC1 encoder is expected to write all 8 bytes of the
output data. But in case of a solid color block, it was writing
only 1 of the first 3 bytes (R, G, B). So lots of solid blocks
were containing invalid data (for instance: R + dR < 0 or > 255).
Make it clear which local variable we really want to use by changing
the names. All of these seem to be fine but this can really bite us
so have better clarity here.
In 4053911e we tried to fix the debug build and failed. The function API
actually asks for coords as first parameter. Our nightly builds expose
this debug build and have been failing due to this.
It also makes clear that the debug part of this code was never really
used upstream...
Carefully compared 'svn export' and 'make dist' results and couple of
files were missing.
Changes:
* Makefile.am: removed all .pc from EXTRA_DIST, we shouldn't
distribute them here as they will contain ./configure data such as
install location.
* src/Makefile.am: moved all if-endif to files, otherwise EXTRA_DIST
won't work properly. We must EXTRA_DIST outside of the if-endif
block.
* static_libs/liblinebreak: removed couple of unused files.
SVN revision: 82241
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895