Note: The polarity of the staging flag is inverted from usual because
a G3 dependency with no SkUserConfig.h relies on the legacy API.
Once this lands, we will migrate them and others, then remove the
staging API. The inverted staging flag is kind of nice, actually - I may
use that pattern in the future. It means less total CLs and it's just as
easy to flip the bit on or off during debugging.
Bug: skia:104662
Change-Id: I48cba1eeae3e2e6f79918c6d243e0666e68ec71b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/310656
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
Bug: skia:10178
These functions can be performed generically using SkRasterPipeline
or skcms. Further, the reason we used a function pointer anyway was
so that we could call the same function on each row separately. But
libwebp's API doesn't let us do a single row at a time anyway.
Simplify this method by using readPixels when necessary and
skipping conversion entirely when possible.
Add support for encoding from unpremul 4444. It is simpler to support
it, and it's not obvious why we didn't support it before.
Keep the behavior of not supporting A8, and apply the same to the
other alpha-only formats. Note that we could support encoding such an
image to alpha, r=0, g=0, b=0, but I'd rather leave adding that
feature to a separate change, which enables it for all encoders (and
accounts for the internal use of PNGs as a round-trip for
kAlpha_8_SkColorType).
Add GMs to test the newly supported SkColorTypes.
Change-Id: I4d86c5621792fb6dc3cb68b736a1eb35d577e3a6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292962
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
It was too easy to get into circular include chains. Added static
asserts to ensure we keep our quad AA flags in sync. Also, IWYU.
Change-Id: I01aefa264aa56420ab5a46a8ecd9e63c021c79ab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280405
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Bug: chromium:951893
This will help determine which piece of code left memory uninitialized.
Add a test that exercises all the different ways we might pass memory
to jpeg_write_scanlines.
Change-Id: I6392a414795da9b0471e8cd6b373a7fff8f0a1b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225098
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
This reverts commit 22170b3178.
It was reverted due to the test breaking Google3. This includes a
workaround.
Original change's description:
> Treat kWEBP encode with quality=100 as lossless
>
> In SkEncodeImage and friends, treat quality of 100 as a lossless encode
> when using kWEBP. This seems a good fit for the intent - which is
> presumably to save the highest quality image. This also matches
> Chromium's blink::ImageEncoder::ComputeWebpOptions, which treats a
> quality of 1 (on a float scale from 0 to 1) as a lossless encode.
>
> FWIW, Chromium has had this behavior since
> https://codereview.chromium.org/1937433002, in response to
> crbug.com/523098. The goal is to "maintain sharpness to
> match the JPEG encoder behavior (use WEBP lossless encoding)".
>
> Add a test to verify the new behavior. This requires making tests
> depend on libwebp to use WebPGetFeatures, since the Skia API does not
> provide a way to determine whether an encoded webp file was encoded
> lossless-ly or lossily.
>
> Bug: skia:8586
> Change-Id: Ie9e09c2f7414ab701d696c4ad9edf405868a716f
> Reviewed-on: https://skia-review.googlesource.com/c/175823
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Derek Sollenberger <djsollen@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=reed@google.com, based on prior approval
Bug: skia:8586
Change-Id: I09c73f71996422f797fd9456fef5dfad9af36839
Reviewed-on: https://skia-review.googlesource.com/c/194194
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Auto-Submit: Leon Scroggins <scroggo@google.com>
This reverts commit e7f165be2e.
Reason for revert: doesn't compile in google3
Original change's description:
> Treat kWEBP encode with quality=100 as lossless
>
> In SkEncodeImage and friends, treat quality of 100 as a lossless encode
> when using kWEBP. This seems a good fit for the intent - which is
> presumably to save the highest quality image. This also matches
> Chromium's blink::ImageEncoder::ComputeWebpOptions, which treats a
> quality of 1 (on a float scale from 0 to 1) as a lossless encode.
>
> FWIW, Chromium has had this behavior since
> https://codereview.chromium.org/1937433002, in response to
> crbug.com/523098. The goal is to "maintain sharpness to
> match the JPEG encoder behavior (use WEBP lossless encoding)".
>
> Add a test to verify the new behavior. This requires making tests
> depend on libwebp to use WebPGetFeatures, since the Skia API does not
> provide a way to determine whether an encoded webp file was encoded
> lossless-ly or lossily.
>
> Bug: skia:8586
> Change-Id: Ie9e09c2f7414ab701d696c4ad9edf405868a716f
> Reviewed-on: https://skia-review.googlesource.com/c/175823
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Derek Sollenberger <djsollen@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=djsollen@google.com,scroggo@google.com,reed@google.com
Change-Id: I91680f65a2a5e6f0a13b84e97c9541ebe0606b33
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:8586
Reviewed-on: https://skia-review.googlesource.com/c/176584
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
In SkEncodeImage and friends, treat quality of 100 as a lossless encode
when using kWEBP. This seems a good fit for the intent - which is
presumably to save the highest quality image. This also matches
Chromium's blink::ImageEncoder::ComputeWebpOptions, which treats a
quality of 1 (on a float scale from 0 to 1) as a lossless encode.
FWIW, Chromium has had this behavior since
https://codereview.chromium.org/1937433002, in response to
crbug.com/523098. The goal is to "maintain sharpness to
match the JPEG encoder behavior (use WEBP lossless encoding)".
Add a test to verify the new behavior. This requires making tests
depend on libwebp to use WebPGetFeatures, since the Skia API does not
provide a way to determine whether an encoded webp file was encoded
lossless-ly or lossily.
Bug: skia:8586
Change-Id: Ie9e09c2f7414ab701d696c4ad9edf405868a716f
Reviewed-on: https://skia-review.googlesource.com/c/175823
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Mike Reed <reed@google.com>
- Encoders and decoders always assume kIgnore.
- They are less opinionated about F16 and color space,
we just trust the color space that's passed in, and
put that directly in the image (no sRGB encoding).
- SkBitmap and SkPixmap read/write pixels functions were
defaulting to kResepct, those are now always kIgnore.
- Many other bits of plumbing are simplified, and I
added a default of kIgnore to SkImage::makeColorSpace,
so we can phase out that argument entirely.
- Still need to add defaults to other public APIs that
take SkTransferFunctionBehavior.
- This makes gold think that we've dramatically changed
the contents of all F16 images, but that's because
it doesn't understand the (now linear) color space
that's embedded. Once we triage them all once, they
will work fine (and they'll look perfect in the browser).
Bug: skia:
Change-Id: I62fa090f96cae1b67d181ce14bd91f34ff2ed747
Reviewed-on: https://skia-review.googlesource.com/140570
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
experiment to see if there are any unknown dependencies
on kRW_LegacyBitmapMode
R=reed@google.com,fmalita@chromium.org,bungeman@google.com
Bug: skia:5615
Change-Id: I2cc578570ac18cd31c3520e1bd801f4a7a669347
Reviewed-on: https://skia-review.googlesource.com/105283
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
Should make it easier to ask just for images.
Change-Id: If821743dc924c4bfbc6b2b2d29b14affde7b3afd
Reviewed-on: https://skia-review.googlesource.com/82684
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Previosuly, we would (accidentally) always use just yuv.
Bug: 713862
Change-Id: I00acc6ca2841ba0636494119b7b4f46a9deee401
Reviewed-on: https://skia-review.googlesource.com/17406
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Bug: skia:6409
Bug: 713862
Change-Id: If287e2bcad5af990fac11e9091305f45ec903dbf
Reviewed-on: https://skia-review.googlesource.com/15647
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Also adds a SkEncoder base class.
Bug: 713862
Change-Id: Ia3f009cd9f376514f6c19396245fab3a43ae6536
Reviewed-on: https://skia-review.googlesource.com/15152
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
