Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1680333004:
Add support for encoding/decoding WebP images. (Closed)
|
Created:
4 years, 10 months ago by nyquist Modified:
4 years, 10 months ago CC:
chromium-reviews, anandc+watch-blimp_chromium.org, maniscalco+watch-blimp_chromium.org, sriramsr+watch-blimp_chromium.org, nyquist+watch-blimp_chromium.org, marcinjb+watch-blimp_chromium.org, kmarshall+watch-blimp_chromium.org, dtrainor+watch-blimp_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@serialize-deserialize-images-framework Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionAdd support for encoding/decoding WebP images.
This CL adds support for always encoding all images within SkPicture to
WebP. On the decoding side it also assumes that the input will be WebP.
The pixels from Skia are premultiplied, but the import functions available
from WebP only supports un-premultiplied data, so the code unpremultiples
the values during the encoding step. Also, the quality and method
configuration is hard coded since any change in it would change the
hash of the data.
Also, the alpha-channel is always used, since the WebP encoder will
optimize the alpha-channel if all values are 255.
BUG=577262
Committed: https://crrev.com/6c3ec5f996e1d405bec3bf7dd46eaba4ae5f2a80
Cr-Commit-Position: refs/heads/master@{#376034}
Patch Set 1 #
Total comments: 10
Patch Set 2 : Merged in BlimpImageSerializationProcessor::Mode split #Patch Set 3 : Simplify WebPDecoder and assume premultiplied alpha channel #
Total comments: 10
Patch Set 4 : Add unpremultiply-step #Patch Set 5 : Always assume alpha-channel in decoder #
Total comments: 7
Patch Set 6 : Addressed comments about WebP again #Patch Set 7 : merged origin/master #
Total comments: 2
Patch Set 8 : address minor last comments #
Messages
Total messages: 31 (12 generated)
nyquist@chromium.org changed reviewers: + dtrainor@chromium.org, urvang@chromium.org
dtrainor: PTAL //blimp urvang: PTAL WebP-related code and DEPS
https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... File blimp/common/compositor/blimp_remote_image_serializer.cc (right): https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... blimp/common/compositor/blimp_remote_image_serializer.cc:24: if (len < 10) Don't you need first 14 bytes? (8 + 6) https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... blimp/common/compositor/blimp_remote_image_serializer.cc:61: bool success = WebPEncode(&config, &picture) != 0; "!= 0" isn't really needed https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... blimp/common/compositor/blimp_remote_image_serializer.cc:82: bool RgbPictureImport(const unsigned char* pixels, These parts were taken from an OLD version of https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit... I believe. (1) That code was simplified a lot recently: https://codereview.chromium.org/1319113002/diff/1/Source/platform/image-encod... So, let me ask this question: in your case also, don't you know for sure if you expect pre-multiplied RGB or not? If you do, this import logic will become much simpler here as well. (2) That code has a missing part: it only imports RGB channels and alpha is discarded. There's ongoing work to fix that: http://crrev.com/1302423004 Once that's done, you'll need the alpha channel imported here too. https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/web... File blimp/common/compositor/webp_decoder.cc (right): https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/web... blimp/common/compositor/webp_decoder.cc:28: // Assuming only one frame. A few choices here, based on the expected behavior: (1) If you want to support animated WebP (now or in future), I'd suggest using the WebPAnimDecoder API: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libweb... It's takes care of demuxing + decoding + frame disposal etc all internally. [Chrome isn't using WebPAnimDecoder right now, because it needs to do a lot more things: like caching some of the decoded frames, removing them from cache if short on memory and re-decoding some frames etc. But I think it will be suitable in your case, as, IIUC, you only need to decode all frames in sequence just once]. (2) If you are sure you will get non-animated (one frame) images only, then you do NOT even need to create a WebPDemuxer object. You can directly decode by - WebPGetFeatures() to get width/height and flags - WebPINewDecoder() + WebPIUpdate() to decode the single-frame image directly [Or even just WebPDecode() if whole image data will always be available. See comment below]. (3) If you want to decode the first frame only -- for both non-animated and animated images -- then: Using demuxer + decoder as you are doing right now would be most efficient. https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/web... blimp/common/compositor/webp_decoder.cc:51: WebPIDecoder* decoder = WebPINewDecoder(&decoderBuffer); Note that WebPIDecoder is used for incremental decoding of WebP -- that is, if you had image data downloading over a network gradually and wanted to decode as many pixels as possible from data available so far, that's the way to go. In that case, you basically keep calling WebPIUpdate() as you get more data. But looking at your code, I think you have all the image data (in 'input') in the first go itself, right? If so, you can use the simpler WebPDecode() call: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libweb...
The CQ bit was checked by nyquist@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1680333004/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1680333004/20001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
The CQ bit was checked by nyquist@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1680333004/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1680333004/40001
urvang: PTAL https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... File blimp/common/compositor/blimp_remote_image_serializer.cc (right): https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... blimp/common/compositor/blimp_remote_image_serializer.cc:24: if (len < 10) On 2016/02/10 23:54:42, urvang wrote: > Don't you need first 14 bytes? (8 + 6) Done. https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... blimp/common/compositor/blimp_remote_image_serializer.cc:61: bool success = WebPEncode(&config, &picture) != 0; On 2016/02/10 23:54:42, urvang wrote: > "!= 0" isn't really needed Done. https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/bli... blimp/common/compositor/blimp_remote_image_serializer.cc:82: bool RgbPictureImport(const unsigned char* pixels, On 2016/02/10 23:54:42, urvang wrote: > These parts were taken from an OLD version of > https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit... > I believe. > > (1) That code was simplified a lot recently: > https://codereview.chromium.org/1319113002/diff/1/Source/platform/image-encod... > > So, let me ask this question: in your case also, don't you know for sure if you > expect pre-multiplied RGB or not? If you do, this import logic will become much > simpler here as well. > > (2) That code has a missing part: it only imports RGB channels and alpha is > discarded. There's ongoing work to fix that: http://crrev.com/1302423004 > Once that's done, you'll need the alpha channel imported here too. So, I tried to change the code so that it assumed that it was always premultiplied. I'm not sure if I understood it correctly though. Should I also check has_alpha = pixmap.alphaType() != kOpaque_SkAlphaType; and then use that to see if I need to do the !premultiplied parts below? Please advise. https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/web... File blimp/common/compositor/webp_decoder.cc (right): https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/web... blimp/common/compositor/webp_decoder.cc:28: // Assuming only one frame. On 2016/02/10 23:54:42, urvang wrote: > A few choices here, based on the expected behavior: > > (1) If you want to support animated WebP (now or in future), I'd suggest using > the WebPAnimDecoder API: > https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libweb... > It's takes care of demuxing + decoding + frame disposal etc all internally. > > [Chrome isn't using WebPAnimDecoder right now, because it needs to do a lot more > things: like caching some of the decoded frames, removing them from cache if > short on memory and re-decoding some frames etc. > But I think it will be suitable in your case, as, IIUC, you only need to decode > all frames in sequence just once]. > > (2) If you are sure you will get non-animated (one frame) images only, then you > do NOT even need to create a WebPDemuxer object. You can directly decode by > - WebPGetFeatures() to get width/height and flags > - WebPINewDecoder() + WebPIUpdate() to decode the single-frame image directly > [Or even just WebPDecode() if whole image data will always be available. > See comment below]. > > (3) If you want to decode the first frame only -- for both non-animated and > animated images -- then: > Using demuxer + decoder as you are doing right now would be most efficient. Going for (2) for now, using WebPDecode. I'll definitely keep this in mind though. https://codereview.chromium.org/1680333004/diff/1/blimp/common/compositor/web... blimp/common/compositor/webp_decoder.cc:51: WebPIDecoder* decoder = WebPINewDecoder(&decoderBuffer); On 2016/02/10 23:54:43, urvang wrote: > Note that WebPIDecoder is used for incremental decoding of WebP -- that is, if > you had image data downloading over a network gradually and wanted to decode as > many pixels as possible from data available so far, that's the way to go. In > that case, you basically keep calling WebPIUpdate() as you get more data. > > But looking at your code, I think you have all the image data (in 'input') in > the first go itself, right? If so, you can use the simpler WebPDecode() call: > https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libweb... Thanks! That was for sure simpler. Updated to use WebPDecode now.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
blimp lgtm. webp stuff lgtm as well but i'm not an expert in that area.
https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... File blimp/common/compositor/blimp_image_serialization_processor.cc (right): https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/blimp_image_serialization_processor.cc:89: return RgbPictureImport(pixels, &WebPPictureImportRGBA, picture); WebPPictureImportRGBA() and WebPPictureImportBGRA() both assume that RGB is NOT premultiplied by alpha, actually. So, you should assume both in encoder and decoder that you are using non-premultiplied mode. https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... File blimp/common/compositor/webp_decoder.cc (right): https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:15: return hasAlpha ? MODE_rgbA : MODE_RGBA; I'm thinking you can always use MODE_RGBA here (and MODE_BGRA below). Was there a specific reason for the if/else? Note: In Chrome, both premultiplied and non-premultiplied modes had to be supported. And also, there's ICC profile to support. Hence the complexity there. https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:29: Also DCHECK() that AlphaType is as expected (opaque or non-premultiplied) https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:46: } You can ensure ur assumption in code: DCHECK_EQ(config.input.has_animation, 0); https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:79: bitmap->setAlphaType(config.input.has_alpha ? kPremul_SkAlphaType As discussed, assume and use non-premultiplied mode everywhere. So: bitmap->setAlphaType(config.input.has_alpha ? kUnpremul_SkAlphaType : kOpaque_SkAlphaType;
The CQ bit was checked by nyquist@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1680333004/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1680333004/80001
urvang: PTAL Difference between patch set 4 and 5 is just what the decoder assumes. It's not too much overhead to have support for alpha and not, so I do kind of like patch set 4 a bit. However, since you said that the encoder is smart for when everything is alpha=255, I guess patch set 5 should be OK. https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... File blimp/common/compositor/blimp_image_serialization_processor.cc (right): https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/blimp_image_serialization_processor.cc:89: return RgbPictureImport(pixels, &WebPPictureImportRGBA, picture); On 2016/02/13 00:24:36, urvang wrote: > WebPPictureImportRGBA() and WebPPictureImportBGRA() both assume that RGB is NOT > premultiplied by alpha, actually. > > So, you should assume both in encoder and decoder that you are using > non-premultiplied mode. Always assuming premultiplied, and applying unpremultiplication on the fly. https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... File blimp/common/compositor/webp_decoder.cc (right): https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:15: return hasAlpha ? MODE_rgbA : MODE_RGBA; On 2016/02/13 00:24:36, urvang wrote: > I'm thinking you can always use MODE_RGBA here (and MODE_BGRA below). Was there > a specific reason for the if/else? > > Note: In Chrome, both premultiplied and non-premultiplied modes had to be > supported. And also, there's ICC profile to support. Hence the complexity there. Done. https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:29: On 2016/02/13 00:24:36, urvang wrote: > Also DCHECK() that AlphaType is as expected (opaque or non-premultiplied) So, I added DCHECK(config.input.has_alpha); Is that enough? https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:46: } On 2016/02/13 00:24:36, urvang wrote: > You can ensure ur assumption in code: > DCHECK_EQ(config.input.has_animation, 0); Done. https://codereview.chromium.org/1680333004/diff/40001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:79: bitmap->setAlphaType(config.input.has_alpha ? kPremul_SkAlphaType On 2016/02/13 00:24:36, urvang wrote: > As discussed, assume and use non-premultiplied mode everywhere. So: > > bitmap->setAlphaType(config.input.has_alpha ? kUnpremul_SkAlphaType : > kOpaque_SkAlphaType; Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
Mostly OK, just a few suggestions... https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... File blimp/common/compositor/blimp_image_serialization_processor.cc (right): https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... blimp/common/compositor/blimp_image_serialization_processor.cc:66: config.quality = 100.0; // between 0 (smallest file) and 100 (biggest). You should stick to the default quality (=75) & method (=4) selected by WebPConfigInit() automatically -- unless you have a very specific reason to do this. Even if you want to have a really good quality, tweak only quality if possible (say, q=80 or 85) and stick to method = 4. This is something to experiment for you though, and I'll leave it upto you. https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... blimp/common/compositor/blimp_image_serialization_processor.cc:123: int row_stride = static_cast<int>(picture->width * 4); Isn't picture->width already an int? https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... File blimp/common/compositor/webp_decoder.cc (right): https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:74: bitmap->setAlphaType(kUnpremul_SkAlphaType); Given that you are assuming pre-multiplied always, shouldn't this be "kPremul_SkAphaType"?
urvang: PTAL https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... File blimp/common/compositor/blimp_image_serialization_processor.cc (right): https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... blimp/common/compositor/blimp_image_serialization_processor.cc:66: config.quality = 100.0; // between 0 (smallest file) and 100 (biggest). On 2016/02/17 01:49:08, urvang wrote: > You should stick to the default quality (=75) & method (=4) selected by > WebPConfigInit() automatically -- unless you have a very specific reason to do > this. > > Even if you want to have a really good quality, tweak only quality if possible > (say, q=80 or 85) and stick to method = 4. This is something to experiment for > you though, and I'll leave it upto you. OK. Kept at the defaults, but hard-coded them for our purposes. https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... blimp/common/compositor/blimp_image_serialization_processor.cc:123: int row_stride = static_cast<int>(picture->width * 4); On 2016/02/17 01:49:08, urvang wrote: > Isn't picture->width already an int? Doh. My bad. Done. https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... File blimp/common/compositor/webp_decoder.cc (right): https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:74: bitmap->setAlphaType(kUnpremul_SkAlphaType); On 2016/02/17 01:49:08, urvang wrote: > Given that you are assuming pre-multiplied always, shouldn't this be > "kPremul_SkAphaType"? Hmm... Maybe I'm not understanding correctly: We get images from Skia, encode them, serialize them, deserialize them, and then decode them and give them to Skia. As part of encoding them in the WebPImageEncoder, I unpremultiplied the data and though I had to express that here. I do see though that skia seems to always operate on premultiplied pixels. I have checked the end result of this, and I am physically unable to see any difference between the two outputs, as in; they get the same SHA1 sum in a screenshot. Changed to premultiplied though.
Description was changed from ========== Add support for encoding/decoding WebP images. This CL adds support for always encoding all images within SkPicture to WebP. On the decoding side it also assumes that the input will be WebP. BUG=577262 ========== to ========== Add support for encoding/decoding WebP images. This CL adds support for always encoding all images within SkPicture to WebP. On the decoding side it also assumes that the input will be WebP. The pixels from Skia are premultiplied, but the import functions available from WebP only supports un-premultiplied data, so the code unpremultiples the values during the encoding step. Also, the quality and method configuration is hard coded since any change in it would change the hash of the data. Also, the alpha-channel is always used, since the WebP encoder will optimize the alpha-channel if all values are 255. BUG=577262 ==========
lgtm one or two minor suggestions https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... File blimp/common/compositor/webp_decoder.cc (right): https://codereview.chromium.org/1680333004/diff/80001/blimp/common/compositor... blimp/common/compositor/webp_decoder.cc:74: bitmap->setAlphaType(kUnpremul_SkAlphaType); On 2016/02/17 16:56:44, nyquist - OOO back 2-16 wrote: > On 2016/02/17 01:49:08, urvang wrote: > > Given that you are assuming pre-multiplied always, shouldn't this be > > "kPremul_SkAphaType"? > > Hmm... Maybe I'm not understanding correctly: We get images from Skia, encode > them, serialize them, deserialize them, and then decode them and give them to > Skia. > > As part of encoding them in the WebPImageEncoder, I unpremultiplied the data and > though I had to express that here. I do see though that skia seems to always > operate on premultiplied pixels. > > I have checked the end result of this, and I am physically unable to see any > difference between the two outputs, as in; they get the same SHA1 sum in a > screenshot. > > Changed to premultiplied though. From what I understand, the only important part is that you are decoding a WebP image into an SkBitmap. And given that you chose colorspace MODE_rgbA or MODE_bgrA, you should mark this SkBitmap to have premultiplied alpha type. And actually, I just realized that allocN32Pixels() takes care of this automatically: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/skia/i... So, you don't explicitly have to do this. You can just: DCHECK(bitmap->alphatype() == kPremul_SkAlphaType) instead. https://codereview.chromium.org/1680333004/diff/120001/blimp/common/composito... File blimp/common/compositor/blimp_image_serialization_processor.cc (right): https://codereview.chromium.org/1680333004/diff/120001/blimp/common/composito... blimp/common/compositor/blimp_image_serialization_processor.cc:101: // alpha channel is kept the unchanged. s/the unchanged/unchanged/
all done. Also did the part about the DCHECK you suggested. https://codereview.chromium.org/1680333004/diff/120001/blimp/common/composito... File blimp/common/compositor/blimp_image_serialization_processor.cc (right): https://codereview.chromium.org/1680333004/diff/120001/blimp/common/composito... blimp/common/compositor/blimp_image_serialization_processor.cc:101: // alpha channel is kept the unchanged. On 2016/02/17 18:48:34, urvang wrote: > s/the unchanged/unchanged/ Done.
The CQ bit was checked by nyquist@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dtrainor@chromium.org, urvang@chromium.org Link to the patchset: https://codereview.chromium.org/1680333004/#ps140001 (title: "address minor last comments")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1680333004/140001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1680333004/140001
Message was sent while issue was closed.
Description was changed from ========== Add support for encoding/decoding WebP images. This CL adds support for always encoding all images within SkPicture to WebP. On the decoding side it also assumes that the input will be WebP. The pixels from Skia are premultiplied, but the import functions available from WebP only supports un-premultiplied data, so the code unpremultiples the values during the encoding step. Also, the quality and method configuration is hard coded since any change in it would change the hash of the data. Also, the alpha-channel is always used, since the WebP encoder will optimize the alpha-channel if all values are 255. BUG=577262 ========== to ========== Add support for encoding/decoding WebP images. This CL adds support for always encoding all images within SkPicture to WebP. On the decoding side it also assumes that the input will be WebP. The pixels from Skia are premultiplied, but the import functions available from WebP only supports un-premultiplied data, so the code unpremultiples the values during the encoding step. Also, the quality and method configuration is hard coded since any change in it would change the hash of the data. Also, the alpha-channel is always used, since the WebP encoder will optimize the alpha-channel if all values are 255. BUG=577262 ==========
Message was sent while issue was closed.
Committed patchset #8 (id:140001)
Message was sent while issue was closed.
Description was changed from ========== Add support for encoding/decoding WebP images. This CL adds support for always encoding all images within SkPicture to WebP. On the decoding side it also assumes that the input will be WebP. The pixels from Skia are premultiplied, but the import functions available from WebP only supports un-premultiplied data, so the code unpremultiples the values during the encoding step. Also, the quality and method configuration is hard coded since any change in it would change the hash of the data. Also, the alpha-channel is always used, since the WebP encoder will optimize the alpha-channel if all values are 255. BUG=577262 ========== to ========== Add support for encoding/decoding WebP images. This CL adds support for always encoding all images within SkPicture to WebP. On the decoding side it also assumes that the input will be WebP. The pixels from Skia are premultiplied, but the import functions available from WebP only supports un-premultiplied data, so the code unpremultiples the values during the encoding step. Also, the quality and method configuration is hard coded since any change in it would change the hash of the data. Also, the alpha-channel is always used, since the WebP encoder will optimize the alpha-channel if all values are 255. BUG=577262 Committed: https://crrev.com/6c3ec5f996e1d405bec3bf7dd46eaba4ae5f2a80 Cr-Commit-Position: refs/heads/master@{#376034} ==========
Message was sent while issue was closed.
Patchset 8 (id:??) landed as https://crrev.com/6c3ec5f996e1d405bec3bf7dd46eaba4ae5f2a80 Cr-Commit-Position: refs/heads/master@{#376034} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
