2012-01-06 23:49:06 +01:00
|
|
|
// Copyright 2011 Google Inc. All Rights Reserved.
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
//
|
|
|
|
// This code is licensed under the same terms as WebM:
|
|
|
|
// Software License Agreement: http://www.webmproject.org/license/software/
|
|
|
|
// Additional IP Rights Grant: http://www.webmproject.org/license/additional/
|
|
|
|
// -----------------------------------------------------------------------------
|
|
|
|
//
|
|
|
|
// Alpha-plane decompression.
|
|
|
|
//
|
|
|
|
// Author: Skal (pascal.massimino@gmail.com)
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
2011-12-01 04:27:36 +01:00
|
|
|
#include "./vp8i.h"
|
2012-05-23 17:01:44 +02:00
|
|
|
#include "./vp8li.h"
|
2012-05-21 15:22:06 +02:00
|
|
|
#include "../utils/filters.h"
|
2013-02-14 07:21:41 +01:00
|
|
|
#include "../utils/quant_levels_dec.h"
|
2012-05-24 11:21:37 +02:00
|
|
|
#include "../webp/format_constants.h"
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
|
|
|
|
#if defined(__cplusplus) || defined(c_plusplus)
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2012-05-21 15:22:06 +02:00
|
|
|
//------------------------------------------------------------------------------
|
|
|
|
// Decodes the compressed data 'data' of size 'data_size' into the 'output'.
|
|
|
|
// The 'output' buffer should be pre-allocated and must be of the same
|
2013-05-03 03:24:46 +02:00
|
|
|
// dimension 'height'x'width', as that of the image.
|
2012-05-21 15:22:06 +02:00
|
|
|
//
|
|
|
|
// Returns 1 on successfully decoding the compressed alpha and
|
|
|
|
// 0 if either:
|
|
|
|
// error in bit-stream header (invalid compression mode or filter), or
|
|
|
|
// error returned by appropriate compression method.
|
|
|
|
|
|
|
|
static int DecodeAlpha(const uint8_t* data, size_t data_size,
|
2013-05-03 03:24:46 +02:00
|
|
|
int width, int height, uint8_t* output) {
|
2012-05-21 15:22:06 +02:00
|
|
|
WEBP_FILTER_TYPE filter;
|
2012-05-22 11:36:22 +02:00
|
|
|
int pre_processing;
|
|
|
|
int rsrv;
|
2012-05-21 15:22:06 +02:00
|
|
|
int ok = 0;
|
|
|
|
int method;
|
2013-05-03 03:24:46 +02:00
|
|
|
const uint8_t* const alpha_data = data + ALPHA_HEADER_LEN;
|
|
|
|
const size_t alpha_data_size = data_size - ALPHA_HEADER_LEN;
|
2012-05-21 15:22:06 +02:00
|
|
|
|
2013-05-03 03:24:46 +02:00
|
|
|
assert(width > 0 && height > 0);
|
2012-05-21 15:22:06 +02:00
|
|
|
assert(data != NULL && output != NULL);
|
|
|
|
|
|
|
|
if (data_size <= ALPHA_HEADER_LEN) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-22 11:36:22 +02:00
|
|
|
method = (data[0] >> 0) & 0x03;
|
|
|
|
filter = (data[0] >> 2) & 0x03;
|
|
|
|
pre_processing = (data[0] >> 4) & 0x03;
|
|
|
|
rsrv = (data[0] >> 6) & 0x03;
|
2012-05-21 15:22:06 +02:00
|
|
|
if (method < ALPHA_NO_COMPRESSION ||
|
|
|
|
method > ALPHA_LOSSLESS_COMPRESSION ||
|
2012-05-22 11:36:22 +02:00
|
|
|
filter >= WEBP_FILTER_LAST ||
|
|
|
|
pre_processing > ALPHA_PREPROCESSED_LEVELS ||
|
|
|
|
rsrv != 0) {
|
2012-05-21 15:22:06 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (method == ALPHA_NO_COMPRESSION) {
|
2013-05-10 22:39:58 +02:00
|
|
|
const size_t alpha_decoded_size = width * height;
|
2013-05-03 03:24:46 +02:00
|
|
|
ok = (alpha_data_size >= alpha_decoded_size);
|
|
|
|
if (ok) memcpy(output, alpha_data, alpha_decoded_size);
|
2012-05-21 15:22:06 +02:00
|
|
|
} else {
|
2013-05-03 03:24:46 +02:00
|
|
|
ok = VP8LDecodeAlphaImageStream(width, height, alpha_data, alpha_data_size,
|
|
|
|
output);
|
2012-05-21 15:22:06 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ok) {
|
2013-03-14 20:26:39 +01:00
|
|
|
WebPUnfilterFunc unfilter_func = WebPUnfilters[filter];
|
2012-05-22 11:36:22 +02:00
|
|
|
if (unfilter_func != NULL) {
|
2012-05-21 15:22:06 +02:00
|
|
|
// TODO(vikas): Implement on-the-fly decoding & filter mechanism to decode
|
|
|
|
// and apply filter per image-row.
|
2013-05-03 03:24:46 +02:00
|
|
|
unfilter_func(width, height, width, output);
|
2012-05-21 15:22:06 +02:00
|
|
|
}
|
2012-05-23 17:01:44 +02:00
|
|
|
if (pre_processing == ALPHA_PREPROCESSED_LEVELS) {
|
2013-05-03 03:24:46 +02:00
|
|
|
ok = DequantizeLevels(output, width, height);
|
2012-05-23 17:01:44 +02:00
|
|
|
}
|
2012-05-22 11:36:22 +02:00
|
|
|
}
|
|
|
|
|
2012-05-21 15:22:06 +02:00
|
|
|
return ok;
|
|
|
|
}
|
|
|
|
|
2011-08-25 23:22:32 +02:00
|
|
|
//------------------------------------------------------------------------------
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
|
|
|
|
const uint8_t* VP8DecompressAlphaRows(VP8Decoder* const dec,
|
|
|
|
int row, int num_rows) {
|
2013-05-03 03:24:46 +02:00
|
|
|
const int width = dec->pic_hdr_.width_;
|
|
|
|
const int height = dec->pic_hdr_.height_;
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
|
2013-05-03 03:24:46 +02:00
|
|
|
if (row < 0 || num_rows < 0 || row + num_rows > height) {
|
2011-12-01 04:27:36 +01:00
|
|
|
return NULL; // sanity check.
|
|
|
|
}
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
|
2011-12-01 04:27:36 +01:00
|
|
|
if (row == 0) {
|
|
|
|
// Decode everything during the first call.
|
2013-04-05 23:01:07 +02:00
|
|
|
assert(!dec->is_alpha_decoded_);
|
2011-12-01 04:27:36 +01:00
|
|
|
if (!DecodeAlpha(dec->alpha_data_, (size_t)dec->alpha_data_size_,
|
2013-05-03 03:24:46 +02:00
|
|
|
width, height, dec->alpha_plane_)) {
|
2011-12-01 04:27:36 +01:00
|
|
|
return NULL; // Error.
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
}
|
2013-04-05 23:01:07 +02:00
|
|
|
dec->is_alpha_decoded_ = 1;
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
}
|
2011-12-01 04:27:36 +01:00
|
|
|
|
|
|
|
// Return a pointer to the current decoded row.
|
2013-05-03 03:24:46 +02:00
|
|
|
return dec->alpha_plane_ + row * width;
|
EXPERIMENTAL: add support for alpha channel
This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
2011-04-26 01:58:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
#if defined(__cplusplus) || defined(c_plusplus)
|
|
|
|
} // extern "C"
|
|
|
|
#endif
|