aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/codec/SkWebpCodec.cpp
Commit message (Collapse)AuthorAge
* Revert "Revert "SkTypes: extract SkTo""Gravatar Hal Canary2018-06-14
| | | | | | | | | | | | | | | | This reverts commit fdcfb8b7c23fbf18f872d2c31d27978235033876. > Original change's description: > > SkTypes: extract SkTo > > > > Change-Id: I8de790d5013db2105ad885fa2683303d7c250b09 > > Reviewed-on: https://skia-review.googlesource.com/133620 > > Reviewed-by: Mike Klein <mtklein@google.com> Change-Id: Ida74fbc5c21248a724a5edbf9fae18a33bcb23aa Reviewed-on: https://skia-review.googlesource.com/134506 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Hal Canary <halcanary@google.com>
* Revert "SkTypes: extract SkTo"Gravatar Hal Canary2018-06-13
| | | | | | | | | | | | | | | | | | | | | | | This reverts commit 2a2f67592602b18527bc3fd449132d420cd5b62e. Reason for revert: this appears to be what is holding up the Chrome roll. Original change's description: > SkTypes: extract SkTo > > Change-Id: I8de790d5013db2105ad885fa2683303d7c250b09 > Reviewed-on: https://skia-review.googlesource.com/133620 > Reviewed-by: Mike Klein <mtklein@google.com> TBR=mtklein@google.com,halcanary@google.com No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Iafd738aedfb679a23c061a51afe4b98a8d4cdfae Reviewed-on: https://skia-review.googlesource.com/134504 Reviewed-by: Hal Canary <halcanary@google.com> Commit-Queue: Hal Canary <halcanary@google.com>
* SkTypes: extract SkToGravatar Hal Canary2018-06-12
| | | | | | Change-Id: I8de790d5013db2105ad885fa2683303d7c250b09 Reviewed-on: https://skia-review.googlesource.com/133620 Reviewed-by: Mike Klein <mtklein@google.com>
* remove linear blending from SkWebpCodecGravatar Mike Klein2018-06-08
| | | | | | | | | | Change-Id: Ia4cf10ba999b48437491416b0fb21d7726d73b4f Reviewed-on: https://skia-review.googlesource.com/133444 Commit-Queue: Mike Klein <mtklein@chromium.org> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@chromium.org> Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
* Remove sk_64_isS32 and sk_64_asS32Gravatar Herb Derby2018-05-21
| | | | | | | | | This is an API change. I assume that only Skia uses these routines. Change-Id: Iefc98fa5c0b83eb4f52c478e345fd99121ecb254 Reviewed-on: https://skia-review.googlesource.com/129440 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Ben Wagner <bungeman@google.com>
* move a bunch of helpers from SkImageInfo.h into privGravatar Mike Reed2018-02-09
| | | | | | | | | Bug: skia: Change-Id: I8c91cfdb89e4f22448d1201d391556fe43d86dca Reviewed-on: https://skia-review.googlesource.com/105289 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org> Reviewed-by: Cary Clark <caryclark@google.com>
* 1010102, 101010x, 888x in swGravatar Mike Klein2018-01-30
| | | | | | | | | | | | | | | | | | | Same sort of deal as before, now with all three new formats. While I was at it, I made sure RGBA 8888 and BGRA 8888 both work too. We don't want the 101010's in lowp, but 888x should be fine. After looking at the DM images on monitors at work, I decided to re-enable dither even on 10-bit images. Looking at the GMs in 888x or 101010x is interesting... I think we must not be clearing the memory allocated for layers? Seems like we want to allocate layers as 8888? Change-Id: I3a85b4f00877792a6425a7e7eb31eacb04ae9218 Reviewed-on: https://skia-review.googlesource.com/101640 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Add kRGBX_8888, kRGBA_1010102, and kRGBX_1010102 color types. Unused for now.Gravatar Brian Salomon2018-01-30
| | | | | | | | | BUG= skia:7533 Change-Id: I4b3f6b827fd833ba2d07895884d2abc9a3132366 Reviewed-on: https://skia-review.googlesource.com/99781 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Brian Salomon <bsalomon@google.com>
* Make SkAndroidCodec (optionally) respect originGravatar Leon Scroggins III2018-01-26
| | | | | | | | | | | | | | | | | Bug: b/63909536 ImageDecoder will respect the origin, but BitmapFactory will maintain its current behavior of not respecting it. Add an option to respect it. In addition, add support for reading the EXIF data from a WEBP. This seems to be an uncommon use case, but is occasionally used when converting from a JPEG. Add 8 WEBPs, all converted (with cwebp) from their analogous JPEG files already checked in. Change-Id: I38afca58c86fa99ee9ab7d1dc83aaa4f23132c11 Reviewed-on: https://skia-review.googlesource.com/95300 Reviewed-by: Derek Sollenberger <djsollen@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Use SkAndroidCodec in SkAnimatedImageGravatar Leon Scroggins III2018-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | Bug: b/63909536 Bug: b/63908092 SkAnimatedImage is designed around a specific Android use case, so move it into the android folders. Make SkAnimatedImage hold an SkAndroidCodec (instead of an SkCodec). Expose fCodec so that SkAnimatedImage can animate by using the internal SkCodec. Update the sample to use SkAndroidCodec. Allow webp to decode a scaled down animation. For RestoreBG frames, adjust the frameRect (which is erased) to account for the scaling. Add a test to verify that we decode a webp with a RestoreBG frame successfully. Disable scaling for later frames in other formats (GIF, for now), since the code for erasing a RestoreBG frame is currently unaware of the sampling. Change-Id: I5dd2b86138f2c7f6adcd08dce1bd49040f7dc224 Reviewed-on: https://skia-review.googlesource.com/94621 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: Derek Sollenberger <djsollen@google.com>
* remove append_from_srgb()Gravatar Mike Klein2017-12-18
| | | | | | | | | | | It's now no different than append(from_srgb). Bug: skia:7419 Change-Id: I97c59b6987f033ec2f1859db40ca3056b87b370a Reviewed-on: https://skia-review.googlesource.com/86741 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Reland "Hide SkEncodedInfo"Gravatar Leon Scroggins III2017-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This partially reverts commit 1793e7bb46c1f9d430c1a699a1c3d3168159b659. Hide SkEncodedInfo Bug: skia:7353 Bug: skia:6839 This contains information that is not necessary for clients to know. The Color enum tells the number of components in the input, but this is only interesting internally (to the SkSwizzler). Similarly, the Alpha enum differs from SkAlphaType in that it has kBinary instead of kPremul. This is useful information only internally for determining whether the SkColorSpaceXform needs to premultiply. The bitsPerComponent is potentially useful for a client; Android (in SkAndroidCodec) uses it to determine the SkColorType. Rather than exposing bitsPerComponent, make SkAndroidCodec a friend so it can access the SkEncodedInfo. A future change will change SkCodec to recommend F16 for bitsPerComponent > 8, but that will be more involved; it was the reason for the revert of this CL. Switch conversionSupported to use an SkColorType, which is enough info. Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an SkAlphaType. SkCodec still needs an SkEncodedInfo, so move its header (which is already not SK_API) to include/private. TBR=mtklein@chromium.org,reed@google.com Change-Id: I928b1f55317602cb37d29da63b53026c8d139cee Reviewed-on: https://skia-review.googlesource.com/80860 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Revert "Hide SkEncodedInfo"Gravatar Leon Scroggins2017-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit c6f7a4ffa9522159efc42f7c948bba5e66bb8844. Reason for revert: Causing differences in Gold, stemming from the fact that this changes the recommended SkImageInfo for 16 bits-per-component PNG from N32 to F16. - an F16 bitmap already png-encodes to a 16 bits-per-component PNG, but it does not encode a linear colorspace (possibly a bug?). when we decode this PNG using getInfo(), it fails because it has an F16 color type and non-linear colorspace. (In the encode-srgb-png gm, this results in blank results for F16.) We could correct this on the encoder side, but it seems possible that a 16 bits-per-component PNG could be encoded with a different color space. In that case, we'd want SkCodec to recommend F16/SRGBLinear, but I think we'd want the SkCodec to store the encoded SkColorSpace so that we can Xform between the two. Currently SkCodec only stores one color space, so that will require a refactor. - When decoding 16-bits-per-component PNGs, we are now decoding them to F16. This shows differences in Gold. The srgb/gpu results now look more like F16. I think this is fine. Original change's description: > Hide SkEncodedInfo > > Bug: skia:7353 > Bug: skia:6839 > > This contains information that is not necessary for clients to know. The > Color enum tells the number of components in the input, but this is only > interesting internally (to the SkSwizzler). > > Similarly, the Alpha enum differs from SkAlphaType in that it has > kBinary instead of kPremul. This is useful information only internally > for determining whether the SkColorSpaceXform needs to premultiply. > > The bitsPerComponent is potentially useful for a client; Android (in > SkAndroidCodec) uses it to determine the SkColorType. Rather than > exposing bitsPerComponent, use it to make the same decision that Android > would have made - 16 bits per component means to set the info to F16. Add > a test that computeOutputColorType behaves as expected. > > Switch conversionSupported to use an SkColorType, which is enough info. > > Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an > SkAlphaType. > > SkCodec still needs an SkEncodedInfo, so move its header (which is > already not SK_API) to include/private. > > Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda > Reviewed-on: https://skia-review.googlesource.com/79260 > Reviewed-by: Mike Reed <reed@google.com> > Reviewed-by: Mike Klein <mtklein@chromium.org> > Commit-Queue: Leon Scroggins <scroggo@google.com> TBR=mtklein@chromium.org,scroggo@google.com,reed@google.com Change-Id: I0c5dd1461e1b70d1e55349a8e7ee6b029c3f556e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:7353, skia:6839 Reviewed-on: https://skia-review.googlesource.com/80660 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Hide SkEncodedInfoGravatar Leon Scroggins III2017-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: skia:7353 Bug: skia:6839 This contains information that is not necessary for clients to know. The Color enum tells the number of components in the input, but this is only interesting internally (to the SkSwizzler). Similarly, the Alpha enum differs from SkAlphaType in that it has kBinary instead of kPremul. This is useful information only internally for determining whether the SkColorSpaceXform needs to premultiply. The bitsPerComponent is potentially useful for a client; Android (in SkAndroidCodec) uses it to determine the SkColorType. Rather than exposing bitsPerComponent, use it to make the same decision that Android would have made - 16 bits per component means to set the info to F16. Add a test that computeOutputColorType behaves as expected. Switch conversionSupported to use an SkColorType, which is enough info. Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an SkAlphaType. SkCodec still needs an SkEncodedInfo, so move its header (which is already not SK_API) to include/private. Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda Reviewed-on: https://skia-review.googlesource.com/79260 Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Fix webp bug compositing alpha frames on opaque (better fix)Gravatar Leon Scroggins III2017-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code made the wrong assumptions about premultiplication. There are three relevant steps here for decoding a webp frame: 1 tell libwebp to decode 2 colorXform the result (sometimes) 3 blend with the prior frame (sometimes) Rearrange the code to premultiply at the blend step, in a linear space. If the client wants unpremul, the blend step will unpremul after. If there is no blending, the colorXform (if any) will premultiply. If only step 1 is necessary, let libwebp premultiply. This fixes an animated image that has an opaque frame 0 followed by a frame with alpha that blends with it. Add the test image that failed (https://mathiasbynens.be/demo/animated-webp) The prior fix is in 42bae8faa4b9b6a3341b15c6ac7c6b466e95625c. It did not properly handle the colorXform when there was no blending step. Change-Id: I2b9d265ba162eaf7e55a106c8f79341826cee0d3 Reviewed-on: https://skia-review.googlesource.com/72281 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* Revert "Fix webp bug compositing alpha frames on opaque"Gravatar Leon Scroggins2017-11-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 42bae8faa4b9b6a3341b15c6ac7c6b466e95625c. Reason for revert: Breaking GMs. A more extensive fix is needed. Original change's description: > Fix webp bug compositing alpha frames on opaque > > select_xform_alpha is used to determine how the color transform should > handle alpha values. In a similar way, we're using it here to determine > whether to premultiply pixels before blending them. In this case, the > source is unpremul, so we should be premultiplying them, but since we > are compositing on an opaque frame, the dst must be opaque and > select_xform_alpha returns kOpaque. As a result, we do not premultiply > (and even hint to the transform that the pixels are opaque). Since this > all applies to the pre-blended pixels, we should not care that the dst > is opaque. So drop the call to select_xform_alpha and just use the alpha > type of the source. This matches the comment on the lines above. > > Add the test image that failed (https://mathiasbynens.be/demo/animated-webp) > > Change-Id: Ibd13c1f067bdf369ce1c882d4f6057aadccfa313 > Reviewed-on: https://skia-review.googlesource.com/71560 > Commit-Queue: Leon Scroggins <scroggo@google.com> > Reviewed-by: Mike Klein <mtklein@chromium.org> TBR=mtklein@chromium.org,scroggo@google.com Change-Id: I6f535ff9b773a93e02a0358b830291594a6e738c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/71720 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Fix webp bug compositing alpha frames on opaqueGravatar Leon Scroggins III2017-11-14
| | | | | | | | | | | | | | | | | | | | select_xform_alpha is used to determine how the color transform should handle alpha values. In a similar way, we're using it here to determine whether to premultiply pixels before blending them. In this case, the source is unpremul, so we should be premultiplying them, but since we are compositing on an opaque frame, the dst must be opaque and select_xform_alpha returns kOpaque. As a result, we do not premultiply (and even hint to the transform that the pixels are opaque). Since this all applies to the pre-blended pixels, we should not care that the dst is opaque. So drop the call to select_xform_alpha and just use the alpha type of the source. This matches the comment on the lines above. Add the test image that failed (https://mathiasbynens.be/demo/animated-webp) Change-Id: Ibd13c1f067bdf369ce1c882d4f6057aadccfa313 Reviewed-on: https://skia-review.googlesource.com/71560 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* Simplify SkColorSpace::MakeICCGravatar Leon Scroggins III2017-10-31
| | | | | | | | | | | | | | | | | | | Rather than restricting the supported ICC types in MakeICC, create any ICC type that we support, and make the client reject them as necessary by querying the SkColorSpace::Type. Remove ICCTypeFlag and replace uses of it with SkColorSpace::Type. This depends on a change in Chromium (https://chromium-review.googlesource.com/c/chromium/src/+/741843). Without that, this change will start allowing non-CMYK images to use CMYK profiles. Bug: 727128 Change-Id: I085b4665e49bc80083264496d864cc4cd62ae914 Reviewed-on: https://skia-review.googlesource.com/64841 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org>
* Revert[4] "guard old apis for querying byte-size of a bitmap/imageinfo/pixmap"Gravatar Mike Reed2017-10-03
| | | | | | | | | | This reverts commit 5a2e50edc51006ce91366e177a9d21a16775d7fd. Bug: skia: Change-Id: I8d28b5c07d90130e5a1653923740eaf189ecb954 Reviewed-on: https://skia-review.googlesource.com/53900 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Reed <reed@google.com>
* Revert "Revert "Revert "guard old apis for querying byte-size of a ↵Gravatar Mike Reed2017-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap/imageinfo/pixmap""" This reverts commit cd284c532376d16fcc4ed75baf3da65c3e4a2e95. Reason for revert: assert fired in SkMallocPixelRef.cpp:61: fatal error: "assert(info.computeByteSize(rowBytes) == info.getSafeSize(rowBytes))" google3 thinks it was from surface_rowbytes Original change's description: > Revert "Revert "guard old apis for querying byte-size of a bitmap/imageinfo/pixmap"" > > This reverts commit 809cbedd4b252be221b2ac3b4269d312fd8f53a0. > > Bug: skia: > Change-Id: I680d8daeeeeb15526b44c1305d8fb0c6bfa38e1d > Reviewed-on: https://skia-review.googlesource.com/52665 > Commit-Queue: Mike Reed <reed@google.com> > Reviewed-by: Florin Malita <fmalita@chromium.org> TBR=fmalita@chromium.org,reed@google.com Change-Id: I41e3f7a3f791cc8183291847e783ed8a53bc91d2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia: Reviewed-on: https://skia-review.googlesource.com/53802 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Reed <reed@google.com>
* Revert "Revert "guard old apis for querying byte-size of a ↵Gravatar Mike Reed2017-10-02
| | | | | | | | | | | | bitmap/imageinfo/pixmap"" This reverts commit 809cbedd4b252be221b2ac3b4269d312fd8f53a0. Bug: skia: Change-Id: I680d8daeeeeb15526b44c1305d8fb0c6bfa38e1d Reviewed-on: https://skia-review.googlesource.com/52665 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org>
* Revert "guard old apis for querying byte-size of a bitmap/imageinfo/pixmap"Gravatar Jim Van Verth2017-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 88757dacd4f532a0f647c02ae0ee596d31ab5c68. Reason for revert: Still seems to be failing Chromium "telemetry_perf_unittests (with patch) on Android" on android_n5x_swarming_rel. Original change's description: > guard old apis for querying byte-size of a bitmap/imageinfo/pixmap > > Now with legacy behavior for allocpixels > > This was reverted, so the current CL is a "fix" on top of ... > https://skia-review.googlesource.com/c/skia/+/50980 > > Related update to Chrome (in preparation for this change) > https://chromium-review.googlesource.com/c/chromium/src/+/685719 > > Bug: skia: > Change-Id: I4b370ee7e95083ab27421f008132219c9c7b86e9 > Reviewed-on: https://skia-review.googlesource.com/51341 > Reviewed-by: Florin Malita <fmalita@chromium.org> > Commit-Queue: Mike Reed <reed@google.com> TBR=fmalita@chromium.org,reed@google.com Change-Id: I827a0ca1d1e3909e648fde3342cdb8601d34da8d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia: Reviewed-on: https://skia-review.googlesource.com/52381 Reviewed-by: Jim Van Verth <jvanverth@google.com> Commit-Queue: Jim Van Verth <jvanverth@google.com>
* Fix truncated webp imagesGravatar Leon Scroggins III2017-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: b/65290323 If a webp file is truncated such that no rows can be decoded, WebPIDecGetRGB does not initialize its "last_y" parameter. We use rowsDecoded (passed as last_y) to determine which remaining rows to fill. Check the return value of WebPIDecGetRGB. If it fails (returns null), or rowsDecoded is <= 0 (matching Chromium's check), return kInvalidInput, since there is nothing to draw. Note that this is a change in behavior for Android. Previously we would decode an empty webp to just a transparent/black rectangle, whereas now we simply fail. I think this is a change for the better. Add a test which truncates a file to have 0 rows available and attempts to decode it. msan verifies that we no longer depend on the uninitialized value. Stop attempting to test decoding subsets from an incomplete webp (in CodecTest.cpp). Unless we have decoded the portion covered by the subset, this will fail. Remove test images inc0.webp (from both dm/ and colorspace/) and inc1.webp. These just decode to transparent rectangles. Replace them with inc2.webp and inc3.webp, which decode part of the image and then have to fill with transparent. Change-Id: I64d40be91c574b45963f9a43d8dd8f4929dd2939 Reviewed-on: https://skia-review.googlesource.com/50303 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: James Zern <jzern@google.com>
* guard old apis for querying byte-size of a bitmap/imageinfo/pixmapGravatar Mike Reed2017-09-27
| | | | | | | | | | | | | | | | Now with legacy behavior for allocpixels This was reverted, so the current CL is a "fix" on top of ... https://skia-review.googlesource.com/c/skia/+/50980 Related update to Chrome (in preparation for this change) https://chromium-review.googlesource.com/c/chromium/src/+/685719 Bug: skia: Change-Id: I4b370ee7e95083ab27421f008132219c9c7b86e9 Reviewed-on: https://skia-review.googlesource.com/51341 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* Revert "guard old apis for querying byte-size of a bitmap/imageinfo/pixmap"Gravatar Greg Daniel2017-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 98a6216b18b57c2f7a0d58f542c60503686aed69. Reason for revert: breaking the chrome roll. Looks like they may be writing data to create an image across all the row bytes and thus writing to unalloced data on the last row. Link to example failing bot: https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/539960 Original change's description: > guard old apis for querying byte-size of a bitmap/imageinfo/pixmap > > Previously we had size_t and uint64_t variations. > > The new (simpler) API always.. > - returns size_t, or 0 if the calculation overflowed > - returns the trimmed size (does not include rowBytes padding for the last row) > > Bug: skia: > Change-Id: I05173e877918327c7b207d2f7f1ab0db36892e2e > Reviewed-on: https://skia-review.googlesource.com/50980 > Commit-Queue: Mike Reed <reed@google.com> > Reviewed-by: Florin Malita <fmalita@chromium.org> > Reviewed-by: Leon Scroggins <scroggo@google.com> TBR=mtklein@google.com,herb@google.com,scroggo@google.com,fmalita@chromium.org,reed@google.com Change-Id: I726f6ab1b36b14979ba6f37105e0a469b3f0dbc0 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia: Reviewed-on: https://skia-review.googlesource.com/51262 Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Greg Daniel <egdaniel@google.com>
* guard old apis for querying byte-size of a bitmap/imageinfo/pixmapGravatar Mike Reed2017-09-26
| | | | | | | | | | | | | | | Previously we had size_t and uint64_t variations. The new (simpler) API always.. - returns size_t, or 0 if the calculation overflowed - returns the trimmed size (does not include rowBytes padding for the last row) Bug: skia: Change-Id: I05173e877918327c7b207d2f7f1ab0db36892e2e Reviewed-on: https://skia-review.googlesource.com/50980 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org> Reviewed-by: Leon Scroggins <scroggo@google.com>
* Remove SK_LEGACY_FRAME_INFO_ALPHA_TYPEGravatar Leon Scroggins III2017-09-01
| | | | | | | | | | | | With https://chromium-review.googlesource.com/c/621815, Chromium no longer references this. Delete it. TBR=reed@google.com Bug: skia:6839 Change-Id: Icd3d394858859e6732b1429394c7c04bb22b9dea Reviewed-on: https://skia-review.googlesource.com/36581 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: Leon Scroggins <scroggo@google.com>
* Call initializeColorXform inside SkCodecGravatar Leon Scroggins III2017-08-18
| | | | | | | | | | | | | | | | | | | | | | | | Make initializeColorXform private, and only call in the base class. Add virtual method to skip initializeColorXform, for classes that do not need one. Change SkCodec::FrameInfo's SkAlphaType to an SkEncodedInfo::Alpha. This allows proper checking internally whether SkCodec needs to do a color correct premultiply. Depends on https://chromium-review.googlesource.com/c/620947, for this API change. (Separated from review.skia.org/25746) Bug: skia:5609 Bug: skia:6839 Change-Id: Icb0d46659c546060c34d32eaf792c86708726c7a Reviewed-on: https://skia-review.googlesource.com/35880 Reviewed-by: Chris Blume <cblume@chromium.org> Reviewed-by: Derek Sollenberger <djsollen@google.com> Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Move calls to conversion_possible to SkCodecGravatar Leon Scroggins III2017-08-17
| | | | | | | | | | | | | | | | | | | | | | | | Move common code into the base class, so subclasses need not call conversion_possible. Use SkEncodedInfo rather than SkImageInfo, and use the proper frame. API Changes: - SkAndroidCodec: - Add getEncodedInfo(), for SkBitmapRegionCodec - SkEncodedInfo: - Add opaque() helper - SkBitmapRegionDecoder: - Remove unused conversionSupported (Split off from skia-review.googlesource.com/c/25746) Bug: skia:5601 Change-Id: If4a40d4b98a3dd0afde2b6058f92315a393a5baf Reviewed-on: https://skia-review.googlesource.com/34361 Reviewed-by: Mike Klein <mtklein@google.com> Reviewed-by: Derek Sollenberger <djsollen@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* use unique_ptr for codec factoriesGravatar Mike Reed2017-07-25
| | | | | | | | | | Will need guards for android (at least) Bug: skia: Change-Id: I2bb8e656997984489ef1f2e41cd3d301c4e7b947 Reviewed-on: https://skia-review.googlesource.com/26040 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* convert over to 2d-modeGravatar Mike Klein2017-07-20
| | | | | | | | | | | | [√] convert all stages to use SkJumper_MemoryCtx / be 2d-compatible [√] convert compile to 2d also, remove 1d run/compile [√] convert all call sites [√] no diffs Change-Id: I3b806eb8fe0c3ec043359616409f7cd1211a1e43 Reviewed-on: https://skia-review.googlesource.com/24263 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org>
* Index8 is dead, remove guarded codeGravatar Mike Reed2017-07-17
| | | | | | | | | | Needs google3 to be updated before this can land. Bug: skia:6828 Change-Id: I2c16be13c6937ffa48768cc24f9f980171c824d6 Reviewed-on: https://skia-review.googlesource.com/23940 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Mike Reed <reed@google.com>
* Report error on failure to create SkCodecGravatar Leon Scroggins III2017-07-14
| | | | | | | | | | | | | | | | | | Update NewFromStream to report an error on failure to create an SkCodec, so that a client can distinguish between - not enough data - invalid data In Chromium, this will allow blink::ImageDecoder to call SetFailed if the stream is invalid early and we never create an SkCodec. Without this, ImageDecoder will keep trying to create an SkCodec when it receives more data. Change-Id: I4f505c56d91c982be36a828fd0f7db17b1596588 Reviewed-on: https://skia-review.googlesource.com/22642 Commit-Queue: Leon Scroggins <scroggo@google.com> Reviewed-by: Derek Sollenberger <djsollen@google.com> Reviewed-by: Chris Blume <cblume@chromium.org>
* Guard to remove kIndex_8_SkColorTypeGravatar Mike Reed2017-07-13
| | | | | | | | | Bug: skia:6828 Change-Id: Ia942a36abb18213184f8d436555a658270d97d47 Reviewed-on: https://skia-review.googlesource.com/22721 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org> Reviewed-by: Herb Derby <herb@google.com>
* Reland "Remove support for decoding to kIndex_8"Gravatar Leon Scroggins2017-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Original change's description: > > Remove support for decoding to kIndex_8 > > > > Fix up callsites, and remove tests that no longer make sense. > > > > Bug: skia:6828 > > Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295 > > Reviewed-on: https://skia-review.googlesource.com/21664 > > Reviewed-by: Derek Sollenberger <djsollen@google.com> > > Commit-Queue: Leon Scroggins <scroggo@google.com> > > TBR=djsollen@google.com,scroggo@google.com > > Change-Id: I1bc669441f250690884e75a9a61427fdf75c6907 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: skia:6828 > Reviewed-on: https://skia-review.googlesource.com/22120 > Reviewed-by: Leon Scroggins <scroggo@google.com> > Commit-Queue: Leon Scroggins <scroggo@google.com> TBR=djsollen@google.com,scroggo@google.com Bug: skia:6828 Change-Id: I36ff5a11c529d29e8adc95f43b8edc6fd1dbf5b8 Reviewed-on: https://skia-review.googlesource.com/22320 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Revert "Remove support for decoding to kIndex_8"Gravatar Leon Scroggins2017-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 742a3e298fda669006147e4a305bab8452369b1f. Reason for revert: Breaking Android roll: frameworks/base/core/jni/android/graphics/BitmapFactory.cpp:453:18: error: no member named 'fColorPtr' in 'SkAndroidCodec::AndroidOptions' codecOptions.fColorPtr = colorPtr; ~~~~~~~~~~~~ ^ frameworks/base/core/jni/android/graphics/BitmapFactory.cpp:454:18: error: no member named 'fColorCount' in 'SkAndroidCodec::AndroidOptions' codecOptions.fColorCount = colorCount; ~~~~~~~~~~~~ ^ Original change's description: > Remove support for decoding to kIndex_8 > > Fix up callsites, and remove tests that no longer make sense. > > Bug: skia:6828 > Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295 > Reviewed-on: https://skia-review.googlesource.com/21664 > Reviewed-by: Derek Sollenberger <djsollen@google.com> > Commit-Queue: Leon Scroggins <scroggo@google.com> TBR=djsollen@google.com,scroggo@google.com Change-Id: I1bc669441f250690884e75a9a61427fdf75c6907 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:6828 Reviewed-on: https://skia-review.googlesource.com/22120 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Remove support for decoding to kIndex_8Gravatar Leon Scroggins III2017-07-10
| | | | | | | | | | Fix up callsites, and remove tests that no longer make sense. Bug: skia:6828 Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295 Reviewed-on: https://skia-review.googlesource.com/21664 Reviewed-by: Derek Sollenberger <djsollen@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* clean up low-hanging swap_rbGravatar Mike Klein2017-06-28
| | | | | | | | | | | | | | | There are two remaining swap_rb uses that both look non-trivial to replace: - sampling out of index8 when the color table is bgra - table transforms on bgra inputs in SkColorSpaceXform I don't think it's a big deal to just leave swap_rb around, just a little sad. Change-Id: I3d30200cf867cbf37d6f86572b1574d3e22e3490 Reviewed-on: https://skia-review.googlesource.com/21040 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Consolidate decoding frames into SkCodecGravatar Leon Scroggins III2017-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new private method to SkCodec that handles Options.fFrameIndex: - Check to ensure the index is valid - Call onGetFrameCount to force parsing the stream - Recursively call getPixels (it should be complete, so no need for incremental decoding) to decode the prior frame if necessary - Zero fill a RestoreBGColor frame Call the method in getPixels and startIncrementalDecode, and remove duplicate code from GIF and WEBP. Remove support for scaling frames beyond the first, which is currently unused. Preserve the feature of SkGifCodec that it will only parse to the end of the first frame if the first frame is asked for. (Also note that when we continue a partial frame, we won't force parsing the full stream.) If the client only wants the first frame, parsing the rest would be unnecessary. But if the client wants the second, we assume they will want any remaining frames, so we parse the remainder of the stream. This simplifies the code (so SkCodec does not have to ask its subclass to parse up to a particular frame). Update tests that relied on the old behavior: - Codec_partialAnim now hardcodes the bytes needed. Previously it relied on the old behavior that GIF only parsed up to the frame being decoded. - Codec_skipFullParse now only tests the first frame, since that is the case where it is important to skip a full parse. TBR=reed@google.com No changes to the public API. Change-Id: Ic2f075452dfeedb4e3e60e6cf4df33ee7bd38495 Reviewed-on: https://skia-review.googlesource.com/19276 Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Remove debug checks for unsupported ICC profilesGravatar Matt Sarett2017-06-09
| | | | | | | | | | | | This was never fully integrated with our automated image testing. I feel it has limited usefulness in terms of catching bugs. Bug: skia: Change-Id: Iecd0a4e9b664ab0b351debde45ada864379de7ec Reviewed-on: https://skia-review.googlesource.com/19267 Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Matt Sarett <msarett@google.com>
* Make SkCodec more flexible about its required frameGravatar Leon Scroggins III2017-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkCodec sets fRequiredFrame to be the earliest possible frame that a given frame can depend on. e.g. - Frame A fills the screen, Keep - Frame B does not cover A, Keep - Frame C covers B but not A, and is opaque Frame C can depend on either A or B. SkCodec already reports that C depends on A. This CL allows a client of SkCodec to use either A or B to create C. Also expose the DisposalMethod. Since any frame between A and C can be used to create C except for DisposePrevious frames, the client needs to be able to know the disposal method so they do not try to use such a frame to create C. Further, the disposal method can be used to give the client a better idea whether they will continue to need a frame. (e.g. if frame i is DisposePrevious and depends on i-1, the client may not want to steal i-1 to create i, since i+1 may also depend on i-1.) TODO: Share code for decoding prior frames between GIF and WEBP Change-Id: I91a5ae22ba3d8dfbe0bde833fa67ae3da0d81ed6 Reviewed-on: https://skia-review.googlesource.com/13722 Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Chris Blume <cblume@chromium.org> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Simplify SkCodecs' call to SkColorSpaceXform::applyGravatar Leon Scroggins III2017-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | Most SkCodec subclasses did the following to apply their SkColorSpaceXform: dstFormat = select_xform_format(dstInfo.colorType()); srcFormat = select_xform_format(<something that doesn't change>); xformAlphaType = select_xform_alpha(dstInfo.alphaType(), this->getInfo().alphaType()); this->colorXform()->apply(dstFormat, dst, srcFormat, src, width, xformAlphaType); Consolidate the computation of these parameters into SkCodec and add a new method to SkCodec that calls apply() with those parameters. Add a SkColorSpaceXform::ColorFormat to SkCodec. This allows the new method SkCodec::applyColorXform to supply the ColorFormat. TBR=reed@google.com (No change to public API.) Change-Id: I8ea7ba4c0024be827a9f9359796c778744330f6e Reviewed-on: https://skia-review.googlesource.com/18523 Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* update SkRasterPipeline::run() to also take yGravatar Mike Klein2017-06-01
| | | | | | | | | y isn't used yet. This is just a warmup that updates the callers. Change-Id: I78f4f44e2b82f72b3a39fa8a8bdadef1d1b8a99e Reviewed-on: https://skia-review.googlesource.com/18381 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Klein <mtklein@chromium.org>
* SkRasterPipeline in SkArenaAllocGravatar Mike Klein2017-05-24
| | | | | | | | | Bug: skia:6673 Change-Id: Ia2bae4f6a9039a007a10b6b45bcf2f0854bf6e5c Reviewed-on: https://skia-review.googlesource.com/17794 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>
* Fix alpha in webp bug introduced with animationGravatar Leon Scroggins III2017-05-23
| | | | | | | | | | | | | | | | | Prior to 557fbbe05ba48bcc20be684d11fe0edfc24c87ba, if there was a colorXform, we told libwebp to decode to unpremul, since premultiplication is handled by the colorXform. In that CL, I handled this in the case where the dst color type was not 8888 or when blending with the prior frame, but not in the 8888/not blending with the prior frame case. Rearrange the code so we always tell libwebp to use BGRA_8888 unpremul if there is a colorXform. Change-Id: Ie1121bc65da6520af895e8eb72d53573426b7bd6 Reviewed-on: https://skia-review.googlesource.com/17781 Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Add animation support to SkWebpCodecGravatar Leon Scroggins III2017-05-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TBR=reed@google.com (No change to the public API, but changed a header file) SkWebpCodec: - Implement onGetFrameCount, onGetFrameInfo, and onGetRepetitionCount - Respect the alpha reported by libwebp. Although the spec states that it is only a hint, the libwebp encoder uses it properly. Respecting allows us to draw opaque images faster and decode them to 565. This also matches other SkCodecs (and Chromium). - onGetPixels: - Decode the frame requested, recursively decoding required frame if necessary - When blending with a prior frame, use SkRasterPipeline SkCodec: - Move check for negative index to getFrameInfo - Reset the colorXform if one is not needed SkCodecAnimation: - Add new blend enum, for WebP's (and APNG's) non-blending option SkFrameHolder: - New base classes for frames and the owner of the frames, allowing code sharing between SkWebpCodec and SkGifCodec (particularly for determining whether a frame has alpha and what frame it depends on) - When moving items from SkGIFFrameContext, use Skia conventions (i.e. int instead of unsigned) - Rename "delay time" to "duration", to match e.g. SkFrameInfo:: fDuration SkGifImageReader: - Move pieces to SkFrameHolder, and adapt to changes made in the process - Make setAlphaAndRequiredFrame (now on the base class SkFrameHolder) more general to support webp, and add support for frames that do not blend - Change SkGIFFrameContext from a struct to a class, to match how we use the distinction elsewhere (i.e. struct is a small object with public fields) - Rework hasTransparentPixel (now hasTransparency, since it returns true in some cases where there is not a transparent pixel) to better fit with the modified setAlphaAndRequiredFrame. Also be more consistent when there is no transparent pixel but no color map. - Simplify an if condition that was previously simplified in 2d61e717 but accidentally got reverted in a4db9be6 CodecAnimTest: - Test new animated webp files - Rearrange the test to more cleanly print alpha type mismatches for the first frame resources: - webp-animated.webp - animated webp from Chromium - blendBG.webp - new webp file using bits of webp-animated-semitransparent4.webp from Chromium - tests required frame and alpha when using the non-blending mode - frames have the following properties: - Frame 0: no alpha, fills screen - Frame 1: alpha, fills screen - Frame 2: no alpha, fills screen - Frame 3: alpha, fills screen, blendBG - Frame 4: no alpha, fills screen, blendBG - Frame 5: alpha, blendBG - Frame 6: covers 4, has alpha, blendBG - also used to test decoding to 565 if the new frame data has alpha but blends onto an opaque frame DM.cpp: - Test animated images to non-native 8888 and unpremul DMSrcSink.cpp: - Do not test non-native 8888 decodes to f16 dst - Test unpremul decodes to f16 - Copy a frame of an animated image prior to drawing, since in unpremul mode, the DM code will premultiply first. Bug: skia: 3315 Change-Id: I4e55ae2ee5bc095b37a743bdcfac644be603b980 Reviewed-on: https://skia-review.googlesource.com/16707 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Matt Sarett <msarett@google.com>
* Fix msan errors in webp decoderGravatar Matt Sarett2017-03-28
| | | | | | | | Bug: skia: Change-Id: I919a24fc61137c4a30160c97ad69fa4a2eadd031 Reviewed-on: https://skia-review.googlesource.com/10325 Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Matt Sarett <msarett@google.com>
* Add codec and color xform support for 565Gravatar Matt Sarett2017-03-28
| | | | | | | | Bug: skia: Change-Id: I23184acc4e17d38861d27ab81172048a24c400d2 Reviewed-on: https://skia-review.googlesource.com/10288 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Matt Sarett <msarett@google.com>
* Add SkTransferFunctionBehavior flag: Use in codec and encoderGravatar Matt Sarett2017-03-24
| | | | | | | | | | | | | | This is a step towards removing the non-linear blending flag from SkColorSpace. The flag on SkColorSpace used to control the premul behavior - now it is controlled by this option. BUG=skia: Change-Id: Ia29bd8c2b0596a93c6aa14332dcd9bd39e388a90 Reviewed-on: https://skia-review.googlesource.com/10008 Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Matt Sarett <msarett@google.com>
* Reland "Respect canvas size and frame offset in webp decoder"Gravatar Matt Sarett2017-02-07
| | | | | | | | | | | | | | Original Change Reviewed At: https://skia-review.googlesource.com/c/7800 CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-MSAN BUG=skia:6185 Change-Id: I1a7732832d37920545c1775d7c7c65b43ed810f9 Reviewed-on: https://skia-review.googlesource.com/8157 Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Matt Sarett <msarett@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 20:48:51 +0000