An error occurred fetching the project authors.
  1. 15 Oct, 2012 1 commit
    • Nigel Tao's avatar
      image/jpeg: decode progressive JPEGs. · 8b624f60
      Nigel Tao authored
      To be clear, this supports decoding the bytes on the wire into an
      in-memory image. There is no API change: jpeg.Decode will still not
      return until the entire image is decoded.
      
      The code is obviously more complicated, and costs around 10% in
      performance on baseline JPEGs. The processSOS code could be cleaned up a
      bit, and maybe some of that loss can be reclaimed, but I'll leave that
      for follow-up CLs, to keep the diff for this one as small as possible.
      
      Before:
      BenchmarkDecode	    1000	   2855637 ns/op	  21.64 MB/s
      After:
      BenchmarkDecodeBaseline	     500	   3178960 ns/op	  19.44 MB/s
      BenchmarkDecodeProgressive	     500	   4082640 ns/op	  15.14 MB/s
      
      Fixes #3976.
      
      The test data was generated by:
      # Create intermediate files; cjpeg on Ubuntu 10.04 can't read PNG.
      convert video-001.png video-001.bmp
      convert video-005.gray.png video-005.gray.pgm
      # Create new test files.
      cjpeg -quality 100 -sample 1x1,1x1,1x1 -progressive video-001.bmp > video-001.progressive.jpeg
      cjpeg -quality 50 -sample 2x2,1x1,1x1 video-001.bmp > video-001.q50.420.jpeg
      cjpeg -quality 50 -sample 2x1,1x1,1x1 video-001.bmp > video-001.q50.422.jpeg
      cjpeg -quality 50 -sample 1x1,1x1,1x1 video-001.bmp > video-001.q50.444.jpeg
      cjpeg -quality 50 -sample 2x2,1x1,1x1 -progressive video-001.bmp > video-001.q50.420.progressive.jpeg
      cjpeg -quality 50 -sample 2x1,1x1,1x1 -progressive video-001.bmp > video-001.q50.422.progressive.jpeg
      cjpeg -quality 50 -sample 1x1,1x1,1x1 -progressive video-001.bmp > video-001.q50.444.progressive.jpeg
      cjpeg -quality 50 video-005.gray.pgm > video-005.gray.q50.jpeg
      cjpeg -quality 50 -progressive video-005.gray.pgm > video-005.gray.q50.progressive.jpeg
      # Delete intermediate files.
      rm video-001.bmp video-005.gray.pgm
      
      R=r
      CC=golang-dev
      https://golang.org/cl/6684046
      8b624f60
  2. 07 Oct, 2012 1 commit
  3. 06 Oct, 2012 1 commit
  4. 06 Sep, 2012 1 commit
  5. 06 Feb, 2012 1 commit
    • Rob Pike's avatar
      all: avoid bytes.NewBuffer(nil) · 5be24046
      Rob Pike authored
      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
      5be24046
  6. 20 Dec, 2011 1 commit
  7. 08 Nov, 2011 1 commit
  8. 02 Nov, 2011 2 commits
  9. 04 Oct, 2011 1 commit
    • Nigel Tao's avatar
      image: spin off a new color package out of the image package. · a2846e65
      Nigel Tao authored
      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
      a2846e65
  10. 14 Sep, 2011 1 commit
  11. 29 Apr, 2011 1 commit
  12. 19 Apr, 2011 1 commit