This package provides named colors as defined in the SVG 1.1 spec.
Named colors are parsed from the SVG 1.1 spec web page at
http://www.w3.org/TR/SVG/types.html and written using go generate
fixesgolang/go#11734
Change-Id: Ia75a166b3714a36a07be64c7d331231b5b2d0cf2
Reviewed-on: https://go-review.googlesource.com/13181
Reviewed-by: Nigel Tao <nigeltao@golang.org>
These mirror the image.Point methods in the standard library.
Change-Id: I7309af308a8182e325af20b47341f72703cbc95a
Reviewed-on: https://go-review.googlesource.com/13603
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is only for the NearestNeighbor and ApproxBiLinear Interpolators. A
Kernel interpolator will add blur even when the dst and src rectangles
are the same size.
We do not bother recognizing Transforms that are Scales. The performance
difference is minimal, as you still need to do a per-dst-pixel inverse
mapping either way.
benchmark old ns/op new ns/op delta
BenchmarkSimpleScaleCopy-8 4866297 29586 -99.39%
BenchmarkSimpleTransformCopy-8 4875991 29531 -99.39%
BenchmarkSimpleTransformScale-8 1208147 1223206 +1.25%
Change-Id: If649ad27a4e81bcbb24b18315745c02c9186a5b7
Reviewed-on: https://go-review.googlesource.com/13004
Reviewed-by: Rob Pike <r@golang.org>
It's more args (in terms of bytes), but fewer allocations (Transformer
is an interface). Either way, it's not really that big of a deal, but
the value instead of the pointer seems conceptually more correct.
Change-Id: Ibea76da17cbda0d9633110fd56044b4e2c690e81
Reviewed-on: https://go-review.googlesource.com/12669
Reviewed-by: Rob Pike <r@golang.org>
This is the golang.org/x equivalent of the golang.org/cl/12220 change to
the standard library.
Change-Id: I220d1398902dec374472ef5b08db8501607cc971
Reviewed-on: https://go-review.googlesource.com/12222
Reviewed-by: Rob Pike <r@golang.org>
I somehow missed this in the previous change. Not sure how.
Change-Id: Ib9277944418a73cda6acc07fc308d846b4064b9e
Reviewed-on: https://go-review.googlesource.com/11321
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Make all occurrences of "not enough pixel data" refer to the
same one.
Change-Id: Iecff9f22eba7a8852174ba18d1e68226c76f84c6
Reviewed-on: https://go-review.googlesource.com/11030
Reviewed-by: Nigel Tao <nigeltao@golang.org>
There is no code changes in this CL, just a copy/paste and some
wordsmithing.
Change-Id: I418e8aed5ab997fad4214e8049287cac4bce8bf6
Reviewed-on: https://go-review.googlesource.com/11274
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Fuzzing detected that an invalid tile size could cause a
panic. Fix a typo in the range check to solve it.
Fixesgolang/go#10712.
Change-Id: I88a5a7884d98f622cc89ed6e394becebb07c6e60
Reviewed-on: https://go-review.googlesource.com/11020
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Fuzzing detected a divide by zero in images with 0 bits
per sample. Instead of panicing, return an error. Do more
validation of bits per sample so that the package only
supports what we've actually tested.
Fixesgolang/go#10711.
Change-Id: Ib41b5cd798c32b06429164c9bc471f5f321d88c5
Reviewed-on: https://go-review.googlesource.com/10943
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
them.
Also check for int32 overflow in the webp package.
Fixes#10790.
Change-Id: Id1162fad8a467a72a5379c7f4432d64ef25bc37a
Reviewed-on: https://go-review.googlesource.com/10072
Reviewed-by: Rob Pike <r@golang.org>
At the time of decoding webp file, if chunkID is not one of
{'ALPH', 'VP8', 'VP8L', 'VP8X'} return errInvalidFormat
Fixesgolang/go#10384
Change-Id: I167909b5ddef174d161f806297a08fac6aabcf19
Reviewed-on: https://go-review.googlesource.com/9839
Reviewed-by: Nigel Tao <nigeltao@golang.org>
It should be quick regardless of how large H is.
Fixesgolang/go#10746
Change-Id: Icde36047e88d9786e64f44724b7ba8b38db2a33f
Reviewed-on: https://go-review.googlesource.com/9836
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Return a zero width or zero height image of the appropriate type.
Fixesgolang/go#10393.
Change-Id: I3aa7b6125447726600fb072ce1e8682373ce2a57
Reviewed-on: https://go-review.googlesource.com/9182
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This will make the upcoming "implement masks" change easier.
Change-Id: I2b316a0b25f98779d9cd076e64266c617464a08e
Reviewed-on: https://go-review.googlesource.com/8999
Reviewed-by: Rob Pike <r@golang.org>
It'll only be used by the fallback code paths, but it's easiest if all
code paths take the extra argument.
Change-Id: I09c4067df6af7c4cd270e8ffcad96d1d8af29057
Reviewed-on: https://go-review.googlesource.com/8909
Reviewed-by: Rob Pike <r@golang.org>
This change only adds the fields, more or less. Follow-up changes will
actually honor the masks.
Change-Id: I81411dc1aac4b3c846dcdf13e2cb0b5cd60fb2b4
Reviewed-on: https://go-review.googlesource.com/8902
Reviewed-by: Rob Pike <r@golang.org>
The raw computation can produce red > alpha when some weights are
negative.
Change-Id: Ic6701354770f012d3ef21a390a8400e14e9d1e25
Reviewed-on: https://go-review.googlesource.com/8740
Reviewed-by: Rob Pike <r@golang.org>
The two Ops are equivalent, but Src is faster.
Change-Id: I2c73a13755047c224c71fb5af786875f02681de9
Reviewed-on: https://go-review.googlesource.com/8640
Reviewed-by: Rob Pike <r@golang.org>
This change just does the mechanical codegen for the op == Over cases.
The actual compositing operator is still effectively Src. Fixing that,
which is less mechanical, will be a follow-up change.
Change-Id: I87805114d49e7ce7087066187a2f4c722a883c01
Reviewed-on: https://go-review.googlesource.com/8524
Reviewed-by: Rob Pike <r@golang.org>
This change only *prepares* the codegen to handle multiple Ops. The
actual generated code still only supports one Op (Src) and not the other
(Over). A follow-up change will add Over.
This Op switch (an eventual x2 multiplier in the amount of code
generated) should be the last of the codegen LoC multipliers. The dst
and src mask options will be implemented in the slow path fallback.
Change-Id: Iecbcc6fad063e2aac36d78d5380c0a0947c709df
Reviewed-on: https://go-review.googlesource.com/8488
Reviewed-by: Rob Pike <r@golang.org>
benchmark old ns/op new ns/op delta
BenchmarkScaleBLLargeDown 257715146 260286012 +1.00%
BenchmarkScaleCRLargeDown 426797448 430078734 +0.77%
BenchmarkScaleBLDown 4449939 4222542 -5.11%
BenchmarkScaleCRDown 8160446 8010056 -1.84%
BenchmarkScaleBLUp 22290312 21044122 -5.59%
BenchmarkScaleCRUp 33010722 32021468 -3.00%
BenchmarkScaleCRSrcGray 13307961 13020192 -2.16%
BenchmarkScaleCRSrcNRGBA 40567431 40801939 +0.58%
BenchmarkScaleCRSrcRGBA 39892971 40240558 +0.87%
BenchmarkScaleCRSrcYCbCr 59020222 59686699 +1.13%
benchmark old allocs new allocs delta
BenchmarkScaleBLLargeDown 1 1 +0.00%
BenchmarkScaleCRLargeDown 1 2 +100.00%
BenchmarkScaleBLDown 1 0 -100.00%
BenchmarkScaleCRDown 1 0 -100.00%
BenchmarkScaleBLUp 1 0 -100.00%
BenchmarkScaleCRUp 1 0 -100.00%
BenchmarkScaleCRSrcGray 1 0 -100.00%
BenchmarkScaleCRSrcNRGBA 1 0 -100.00%
BenchmarkScaleCRSrcRGBA 1 0 -100.00%
BenchmarkScaleCRSrcYCbCr 1 0 -100.00%
benchmark old bytes new bytes delta
BenchmarkScaleBLLargeDown 14745600 2949200 -80.00%
BenchmarkScaleCRLargeDown 14745600 4915333 -66.67%
BenchmarkScaleBLDown 1523712 5079 -99.67%
BenchmarkScaleCRDown 1523712 7619 -99.50%
BenchmarkScaleBLUp 10117120 101175 -99.00%
BenchmarkScaleCRUp 10117120 202350 -98.00%
BenchmarkScaleCRSrcGray 4915200 49156 -99.00%
BenchmarkScaleCRSrcNRGBA 4915200 163853 -96.67%
BenchmarkScaleCRSrcRGBA 4915200 163853 -96.67%
BenchmarkScaleCRSrcYCbCr 4915200 245780 -95.00%
The increase in BenchmarkScale??LargeDown number of allocs I think is an
accounting error due to the low number of iterations: a low denominator.
I suspect that there are one or two extra allocs up front for using the
sync.Pool, but one fewer alloc per iteration. The number of iterations
is only 5 for BL and 3 for CR, for the default timeout. If I increase
the -test.benchtime value to 5s, then the reported average (allocs/op)
drop from 2 to 0, so the delta should actually be -100% instead of +0 or
+100%.
Change-Id: I21d9bb0086bdb25517b6a430e8a21bdf3db026f6
Reviewed-on: https://go-review.googlesource.com/8150
Reviewed-by: Rob Pike <r@golang.org>
Only the YCbCr benchmarks show significant changes. The other benchmark
changes look noisy. The PixOffset and YOffset calls were previously
already inlined by the gc compiler. COffset was different because it's
more complicated than YOffset, and the switch inside the COffset body is
redundant when you already know the src image sratio.
http://golang.org/src/image/ycbcr.go?s=2377:2414#L77
benchmark old ns/op new ns/op delta
BenchmarkScaleLargeDownNN 1037504 908236 -12.46%
BenchmarkScaleLargeDownAB 3196568 2735776 -14.42%
BenchmarkScaleLargeDownBL 357165552 311463393 -12.80%
BenchmarkScaleLargeDownCR 649403305 544985134 -16.08%
BenchmarkScaleSrcYCbCr 3204063 2699147 -15.76%
BenchmarkTformABSrcYCbCr 2155142 1968540 -8.66%
BenchmarkTformCRSrcYCbCr 11672625 9865358 -15.48%
Change-Id: Ifa109363a1282ab114b2fdb0b577dcafef927333
Reviewed-on: https://go-review.googlesource.com/7880
Reviewed-by: Rob Pike <r@golang.org>
