if their nominal Min and Max points differ.
This is a behavior change, but arguably a bug fix, as Eq wasn't
previously consistent with In, and the concept of a rectangle being a
set of points. This is demonstrated by the new geom_test.go test.
It does mean that r.Eq(s) no longer implies that Inset'ting both r and s
with a negative inset results in two rectangles that are still Eq, but
that seems acceptable to me.
The previous behavior is still available as "r == s".
Also clarify the image.Rect doc comment when the inputs are
non-canonical.
Also simplify the Point and Rectangle Eq implementations dating from
before Go 1.0, when you couldn't compare structs via the == operator.
Change-Id: Ic39e628db31dc5fe5220f4b444e6d5000eeace5b
Reviewed-on: https://go-review.googlesource.com/5006
Reviewed-by: Rob Pike <r@golang.org>
This just adds test cases. Optimizing CMYK draws will be a follow-up
change.
Change-Id: Ic0d6343d420cd021e21f88623ad7182e93017da9
Reviewed-on: https://go-review.googlesource.com/4941
Reviewed-by: Rob Pike <r@golang.org>
The new testdata was created by:
convert video-001.png -colorspace cmyk video-001.cmyk.jpeg
video-001.cmyk.jpeg was then converted back to video-001.cmyk.png via
the GIMP. ImageMagick (convert) wasn't used for this second conversion
because IM's default color profiles complicates things.
Fixes#4500.
Change-Id: Ibf533f6a6c7e76883acc493ce3a4289d7875df3f
Reviewed-on: https://go-review.googlesource.com/4801
Reviewed-by: Rob Pike <r@golang.org>
PalettedColorModel was renamed to color.Palette
over three years ago by https://golang.org/cl/5132048.
Change-Id: I0204ade10eabff45620fda2990fed428c65d871e
Reviewed-on: https://go-review.googlesource.com/3305
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
https://go-review.googlesource.com/#/c/1876/ introduced a new
TestClipWithNilMP test, along with a code change that fixed a panic,
but the existing TestClip test already contained almost enough machinery
to cover that bug.
There is a small code change in this CL, but it is a no-op: (*x).y is
equivalent to x.y for a pointer-typed x, but the latter is cleaner.
Change-Id: I79cf6952a4999bc4b91f0a8ec500acb108106e56
Reviewed-on: https://go-review.googlesource.com/2304
Reviewed-by: Dave Cheney <dave@cheney.net>
This ensures that changing an image.YCbCr's Y values can't change its
chroma values, even after re-slicing up to capacity.
Change-Id: Icb626561522e336a3220e10f456c95330ae7db9e
Reviewed-on: https://go-review.googlesource.com/2209
Reviewed-by: Rob Pike <r@golang.org>
