The decompression routine is in its own file because
G3 encoding (which is more complicated) will be put
there.
R=nigeltao
CC=golang-dev
https://golang.org/cl/5177047
The spin-off renames some types. The new names are simply better:
image.Color -> color.Color
image.ColorModel -> color.Model
image.ColorModelFunc -> color.ModelFunc
image.PalettedColorModel -> color.Palette
image.RGBAColor -> color.RGBA
image.RGBAColorModel -> color.RGBAModel
image.RGBA64Color -> color.RGBA64
image.RGBA64ColorModel -> color.RGBA64Model
(similarly for NRGBAColor, GrayColorModel, etc)
The image.ColorImage type stays in the image package, but is renamed:
image.ColorImage -> image.Uniform
The image.Image implementations (image.RGBA, image.RGBA64, image.NRGBA,
image.Alpha, etc) do not change their name, and gain a nice symmetry:
an image.RGBA is an image of color.RGBA, etc.
The image.Black, image.Opaque uniform images remain unchanged (although
their type is renamed from image.ColorImage to image.Uniform). The
corresponding color types (color.Black, color.Opaque, etc) are new.
Nothing in the image/ycbcr is renamed yet. The ycbcr.YCbCrColor and
ycbcr.YCbCrImage types will eventually migrate to color.YCbCr and
image.YCbCr, but that will be a separate CL.
R=r, bsiegert
CC=golang-dev
https://golang.org/cl/5132048
Write to image.*.Pix directly in the case of RGB, RGBA and NRGBA
images. For the latter two, the file format matches the memory layout
so a simple copy can be used.
RGB image before/after:
tiff.BenchmarkDecoder 748137 ns/op (62.39 MB/s) 251256 ns/op (185.76 MB/s) x3.0
NRGBA image before/after:
tiff.BenchmarkDecoder 775540 ns/op (80.12 MB/s) 116721 ns/op (532.34 MB/s) x6.6
R=nigeltao
CC=golang-dev
https://golang.org/cl/4929046
The RowsPerStrip tag is mandatory according to the spec. However,
Mac OS sometimes (?) omits it. I managed to create such an image
by applying "tiffutil -none" on a compressed image.
If RowsPerStrip is 0, there was a division by zero in the decoder.
Assume that the image is a single strip in this case.
R=nigeltao, bradfitz
CC=golang-dev
https://golang.org/cl/4815061
There are no behavioral changes, only some copy-and-pastes.
Before, drawFillOver was next to drawCopyOver.
After, drawFillOver is next to drawFillSrc, which is more similar to
drawFillOver than drawCopyOver is.
Similarly, drawCopyOver is now next to drawCopySrc, etc.
R=r
CC=golang-dev
https://golang.org/cl/4695045
of the origin.
image/png and image/jpeg benchmarks show no significant changes.
The image/draw changes suggest to me that making a gofix for this is not
feasible. People are just going to have to make manual fixes.
R=r
CC=golang-dev
https://golang.org/cl/4681044
at (0, 0).
Also refactor the test to use the SubImage method rather than monkeying
with an image's Pix and Rect fields.
R=r
CC=golang-dev
https://golang.org/cl/4678045
This is a core API change.
1) gofix misc src
2) Manual adjustments to the following files under src/pkg:
gob/decode.go
rpc/client.go
os/error.go
io/io.go
bufio/bufio.go
http/request.go
websocket/client.go
as well as:
src/cmd/gofix/testdata/*.go.in (reverted)
test/fixedbugs/bug243.go
3) Implemented gofix patch (oserrorstring.go) and test case (oserrorstring_test.go)
Compiles and runs all tests.
R=r, rsc, gri
CC=golang-dev
https://golang.org/cl/4607052
The TIFF spec says that a baseline TIFF reader must gracefully terminate
when the image has a SampleFormat tag which it does not support.
For baseline compatibility, only SampleFormat=1 (the default) is needed.
Images with other sample formats (e.g. floating-point color values)
are very rare in practice.
R=nigeltao
CC=golang-dev
https://golang.org/cl/4515073
