(*Writer, error) if they take a compression level, and *Writer otherwise.
Rename gzip's Compressor and Decompressor to Writer and Reader, similar to
flate and zlib.
Clarify commentary when writing gzip metadata that is not representable
as Latin-1, and fix io.EOF comment bug.
Also refactor gzip_test to be more straightforward.
Fixes#2839.
R=rsc, r, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/5639057
It complicates the interface unnecessarily.
Document this in go1.html.
Also update the go/doc Makefile.
Fixes#2836.
R=golang-dev, gri, bradfitz
CC=golang-dev
https://golang.org/cl/5642054
The practice encourages people to think this is the way to
create a bytes.Buffer when new(bytes.Buffer) or
just var buf bytes.Buffer work fine.
(html/token.go was missing the point altogether.)
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/5637043
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
instead of the origin.
This makes YCbCr match the other image types (e.g. RGBA, Gray) in
that an image's bounds is not restricted to the positive quadrant.
Also optimize the YCbCr draw code by hoisting some computation
outside of the loop.
benchmark old ns/op new ns/op delta
draw.BenchmarkYCbCr 2544418 2373558 -6.72%
Like https://golang.org/cl/4681044/ I don't think a gofix is
feasible. People will have to make manual changes. On the other hand,
directly manipulating YCbCr images is relatively rare, compared to
RGBA images, and if other code just uses the jpeg and draw packages
instead of messing directly with a YCbCr's []byte representations,
then things should just continue to work.
R=r
CC=golang-dev
https://golang.org/cl/5558048
This matches the other color models. It seems that this was missed
during the review of 5544073.
R=nigeltao, david.crawshaw
CC=golang-dev
https://golang.org/cl/5536057
What package image currently provides is a larger image consisting
of many copies of a smaller image.
More generally, a tiled image could be a quilt consisting of different
smaller images (like Google Maps), or a technique to view a portion of
enormous images without requiring the whole thing in memory.
This richer construct might not ever belong in the standard library (and
is definitely out of scope for Go 1), but I would like the option for
image.Tiled to be its name.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5530062
When I disallowed map + func comparisons, I only did it
in the static case and missed the comparisons via == on
interface values. Fixing that turned these up.
R=nigeltao, r
CC=golang-dev
https://golang.org/cl/5440103
All but 3 cases (in gcimporter.go and hixie.go)
are automatic conversions using gofix.
No attempt is made to use the new Append functions
even though there are definitely opportunities.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5447069
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
writing the idct result directly to the image buffer instead of
storing it in an intermediate d.blocks field.
Writing to d.blocks was necessary when decoding to an image.RGBA image,
but now that we decode to a ycbcr.YCbCr we can write each component
directly to the image buffer.
Crude "time ./6.out" scores to decode a specific 2592x1944 JPEG 20
times show a 16% speed-up:
BEFORE
user 0m10.410s
user 0m10.400s
user 0m10.480s
user 0m10.480s
user 0m10.460s
AFTER
user 0m9.050s
user 0m9.050s
user 0m9.050s
user 0m9.070s
user 0m9.020s
R=r
CC=golang-dev
https://golang.org/cl/4523052
At least, as I understand it. The spec is unclear about what happens
with a local color map.
R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4515045
It's incomplete but sufficient to decode 8-bit GIFs without interlacing
or transparency. More to come.
I'll put in more tests as the feature set grows.
R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4522041
The current iteration can decode 8-bit images in
grayscale, paletted, RGB, RGBA and NRGBA mode. LZW compression
is implemented but does not work on my test images.
Deflate (i.e. zlib) compression with or without a horizontal
predictor is supported.
R=nigeltao, nigeltao_gnome
CC=golang-dev, mpl
https://golang.org/cl/4240051
Encoder now writes tRNS chunk for non-opaque paletted images.
CL includes new test images (basn3a08-trns.[ps]ng).
R=nigeltao, rsc, r
CC=golang-dev
https://golang.org/cl/4432078
Avoids image.At(), color.RGBA(), opposing 8 bit shifts,
and min function calls in a loop. Not as pretty as before,
but the pure version is still there to revert back to
later if/when the compiler gets better.
before (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 64781360 ns/op 18.97 MB/s
after (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 42044300 ns/op 29.23 MB/s
(benchmarked on an HP z600; 16 core Xeon E5520 @ 2.27Ghz)
R=r, r2, nigeltao
CC=golang-dev
https://golang.org/cl/4433088
We replace the current Open with:
OpenFile(name, flag, perm) // same as old Open
Open(name) // same as old Open(name, O_RDONLY, 0)
Create(name) // same as old Open(name, O_RDWR|O_TRUNC|O_CREAT, 0666)
This CL includes a gofix module and full code updates: all.bash passes.
(There may be a few comments I missed.)
The interesting packages are:
gofix
os
Everything else is automatically generated except for hand tweaks to:
src/pkg/io/ioutil/ioutil.go
src/pkg/io/ioutil/tempfile.go
src/pkg/crypto/tls/generate_cert.go
src/cmd/goyacc/goyacc.go
src/cmd/goyacc/units.y
R=golang-dev, bradfitzwork, rsc, r2
CC=golang-dev
https://golang.org/cl/4357052
The test image was converted from doc/video-001.png using the
convert command line tool (ImageMagick 6.5.7-8) at -quality 100.
R=r, nigeltao_gnome
CC=golang-dev
https://golang.org/cl/4259047