the TIFFGetField() return for TIFFTAG_EXTRASAMPLES is defined as (count,
types array) [1]. previously the count was being checked rather than the
first element of the array to determine whether the alpha was associated
(pre-multiplied) and the result needed to be unmultiplied.
since:
9273e441 fix TIFF encoder regarding rgbA/RGBA
[1] http://www.libtiff.org/man/TIFFSetField.3t.html
Change-Id: I6e41be9d038fe8afb6d0aa3c8048925dc901113b
This is to prepare the inclusion of <windows.h>
FrameRect => FrameRectangle
CLIP_MASK => CLIP_8b_MASK
Change-Id: Ia4b1fa4ac06137b4102c91e232206a1fb7159ce0
A command line tool to print out the chunk level structure of
WebP files along with basic integrity checks.
BUG=webp:330
Change-Id: Ic69f646f649abb655b1854621d99afedeed158d7
Encoder:
We were always using ExtraSamples=1, which means associated-alpha.
But we don't need the (lossy) excursion to rgbA format. We can save
the samples as RGBA directly, by changing ExtraSamples to '2'.
The TIFF encoder now checks the colorspace properly, to handle
premultiplied format as well as non-premultiplied.
Decoder:
The result of TIFFReadRGBAImageOriented() is always pre-multiply.
So, in case an alpha channel is present, we need to unmultiply it before
calling WebPPictureImportRGBA().
See:
https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf (page 31)
and also http://www.asmail.be/msg0055469184.html
Change-Id: I3258bfdb0eb2e1a53d6c04414f55edb2926c938c
The patch 21735e0 introduced a bug where a goto path was not testing
the eos_ state. If this happened just before a row_sync, a SaveState()
would be called that would store the eos_ state as '1' till the end
of the loop. This usually was not a problem, except for the very last
chunk where we disable the incremental decoding altogether (we have all
the data). The termination tests were then going wrong.
The fix is to add a proper eos_ test and avoid falling in this inconsistent
state.
(21735e06f7)
BUG=webp:332
Change-Id: Ib16773aee26bfd068fbf4e9db3d2313bd978b269
The FLAGS_LIBS was dropped at some point.
There is still an SDL_Main / main problem though, but it's a
separate topic.
Change-Id: Ief4d79624e94e7904134df8d84a4ac7c77c48ce7
Before, the color cache size was chosen optimally for LZ77 and
the same value was used for RLE. Now, we optimize its value
taking both LZ77 and RLE into account.
Unfortunately, that comes with a small CPU hit.
Change-Id: I6261f04af78cf0784bb8e8fc4b4af5f566a0e071
Between each iteration we keep track of the previously found
potential merge hence less work to do.
Change-Id: I2b6237447e79443516a6111727d96c24f10bd98a
It was a bad implementation of a Lehmer random number generator
(the saturation was done wrong and mostly & was used instead of % .....).
That lead to "for" loop stuck with the same values given a specific seed,
hence wasted "for" loops (e.g. seed getting at 374988608 and modulo of 64
later leads to 0 even when updating the seed with the old formula).
As the "for" loops now always return a proper pair of histograms, their
number can greatly be reduced, hence a speedup.
Change-Id: I9f5b44d66cc96fd4824189d92276c3756c8ead5b
This code is ultra-critical for lossless decoding, especially on ARM.
The extra call VP8LIsEndOfStream() was causing unnecessary slow-down.
Now, we check for bitstream-end separately in the main loop.
Change-Id: I739b5d74cc29578e2b712ba99b544fd995ef0e0d
