Imaging is a simple image processing package for Go



PkgGoDev Build Status Coverage Status Go Report Card

Package imaging provides basic image processing functions (resize, rotate, crop, brightness/contrast adjustments, etc.).

All the image processing functions provided by the package accept any image type that implements image.Image interface as an input, and return a new image of *image.NRGBA type (32bit RGBA colors, non-premultiplied alpha).


go get -u


Usage examples

A few usage examples can be found below. See the documentation for the full list of supported functions.

Image resizing

// Resize srcImage to size = 128x128px using the Lanczos filter.
dstImage128 := imaging.Resize(srcImage, 128, 128, imaging.Lanczos)

// Resize srcImage to width = 800px preserving the aspect ratio.
dstImage800 := imaging.Resize(srcImage, 800, 0, imaging.Lanczos)

// Scale down srcImage to fit the 800x600px bounding box.
dstImageFit := imaging.Fit(srcImage, 800, 600, imaging.Lanczos)

// Resize and crop the srcImage to fill the 100x100px area.
dstImageFill := imaging.Fill(srcImage, 100, 100, imaging.Center, imaging.Lanczos)

Imaging supports image resizing using various resampling filters. The most notable ones:

  • Lanczos - A high-quality resampling filter for photographic images yielding sharp results.
  • CatmullRom - A sharp cubic filter that is faster than Lanczos filter while providing similar results.
  • MitchellNetravali - A cubic filter that produces smoother results with less ringing artifacts than CatmullRom.
  • Linear - Bilinear resampling filter, produces smooth output. Faster than cubic filters.
  • Box - Simple and fast averaging filter appropriate for downscaling. When upscaling it's similar to NearestNeighbor.
  • NearestNeighbor - Fastest resampling filter, no antialiasing.

The full list of supported filters: NearestNeighbor, Box, Linear, Hermite, MitchellNetravali, CatmullRom, BSpline, Gaussian, Lanczos, Hann, Hamming, Blackman, Bartlett, Welch, Cosine. Custom filters can be created using ResampleFilter struct.

Resampling filters comparison

Original image:


The same image resized from 600x400px to 150x100px using different resampling filters. From faster (lower quality) to slower (higher quality):

Filter Resize result
imaging.NearestNeighbor dstImage
imaging.Linear dstImage
imaging.CatmullRom dstImage
imaging.Lanczos dstImage

Gaussian Blur

dstImage := imaging.Blur(srcImage, 0.5)

Sigma parameter allows to control the strength of the blurring effect.

Original image Sigma = 0.5 Sigma = 1.5
srcImage dstImage dstImage


dstImage := imaging.Sharpen(srcImage, 0.5)

Sharpen uses gaussian function internally. Sigma parameter allows to control the strength of the sharpening effect.

Original image Sigma = 0.5 Sigma = 1.5
srcImage dstImage dstImage

Gamma correction

dstImage := imaging.AdjustGamma(srcImage, 0.75)
Original image Gamma = 0.75 Gamma = 1.25
srcImage dstImage dstImage

Contrast adjustment

dstImage := imaging.AdjustContrast(srcImage, 20)
Original image Contrast = 15 Contrast = -15
srcImage dstImage dstImage

Brightness adjustment

dstImage := imaging.AdjustBrightness(srcImage, 20)
Original image Brightness = 10 Brightness = -10
srcImage dstImage dstImage

Saturation adjustment

dstImage := imaging.AdjustSaturation(srcImage, 20)
Original image Saturation = 30 Saturation = -30
srcImage dstImage dstImage

Hue adjustment

dstImage := imaging.AdjustHue(srcImage, 20)
Original image Hue = 60 Hue = -60
srcImage dstImage dstImage


Incorrect image orientation after processing (e.g. an image appears rotated after resizing)

Most probably, the given image contains the EXIF orientation tag. The standard image/* packages do not support loading and saving this kind of information. To fix the issue, try opening images with the AutoOrientation decode option. If this option is set to true, the image orientation is changed after decoding, according to the orientation tag (if present). Here's the example:

img, err := imaging.Open("test.jpg", imaging.AutoOrientation(true))

What's the difference between imaging and gift packages?

imaging is designed to be a lightweight and simple image manipulation package. It provides basic image processing functions and a few helper functions such as Open and Save. It consistently returns *image.NRGBA image type (8 bits per channel, RGBA).

gift supports more advanced image processing, for example, sRGB/Linear color space conversions. It also supports different output image types (e.g. 16 bits per channel) and provides easy-to-use API for chaining multiple processing steps together.

Example code

package main

import (


func main() {
	// Open a test image.
	src, err := imaging.Open("testdata/flowers.png")
	if err != nil {
		log.Fatalf("failed to open image: %v", err)

	// Crop the original image to 300x300px size using the center anchor.
	src = imaging.CropAnchor(src, 300, 300, imaging.Center)

	// Resize the cropped image to width = 200px preserving the aspect ratio.
	src = imaging.Resize(src, 200, 0, imaging.Lanczos)

	// Create a blurred version of the image.
	img1 := imaging.Blur(src, 5)

	// Create a grayscale version of the image with higher contrast and sharpness.
	img2 := imaging.Grayscale(src)
	img2 = imaging.AdjustContrast(img2, 20)
	img2 = imaging.Sharpen(img2, 2)

	// Create an inverted version of the image.
	img3 := imaging.Invert(src)

	// Create an embossed version of the image using a convolution filter.
	img4 := imaging.Convolve3x3(
			-1, -1, 0,
			-1, 1, 1,
			0, 1, 1,

	// Create a new image and paste the four produced images into it.
	dst := imaging.New(400, 400, color.NRGBA{0, 0, 0, 0})
	dst = imaging.Paste(dst, img1, image.Pt(0, 0))
	dst = imaging.Paste(dst, img2, image.Pt(0, 200))
	dst = imaging.Paste(dst, img3, image.Pt(200, 0))
	dst = imaging.Paste(dst, img4, image.Pt(200, 200))

	// Save the resulting image as JPEG.
	err = imaging.Save(dst, "testdata/out_example.jpg")
	if err != nil {
		log.Fatalf("failed to save image: %v", err)



  • Image orientation issue with latest iOS 13.1.2

    Image orientation issue with latest iOS 13.1.2 "Choose Image Size" feature

    In iOS 13 when uploading an image you are prompted with the option to "Choose Image Size" on the selected image, to reduce the size of the original file for upload. This is optional, and you can upload the original large file if you wish.

    When uploading the original image file, without using this feature, the image ends up being rotated properly by use of:

    i, err := imaging.Decode(file, imaging.AutoOrientation(true))
    if err != nil {
    	return err

    But, if you choose to resize the image to "Large", "Medium", or "Small" (using the "Choose Image Size" iOS feature), the uploaded image does not correct the orientation and remains rotated.

    I believe iOS is doing something to the image uploaded with "Choose Image Size", that Disintegration is not taking account of. Perhaps there are additional computations and checks that need to be ran to properly adjust the orientation data of these images.

    EDIT: test image below.

    • without AutoOrientation set to true, if you upload the original it should display rotated in an HTML img tag.
    • with AutoOrientation set to true, it will correct the rotation to confirm it works.
    • but, if you resize the image with the new iOS feature and upload it, it will not correct the rotation. Display it in an HTML img tag to test.
    • the image says "Orientation: 6 (Rotated 90° CCW)" on the TIFF tab of the inspector of the Preview app on macOS. IMG_3543 - no location
    opened by Alexn117 11
  • Causing a memory leak (and crash) on Google App Engine

    Causing a memory leak (and crash) on Google App Engine

    I'm trying to use imaging in an App Engine app, and after resizing about 6 images the application shuts down because of excessive memory usage. This usually happens because of goroutines that don't exit, so that might be the case. Is there a way to turn off parallel computation via a flag or option for environments like this? Or we can just make sure that all spawned goroutines always exit cleanly.

    opened by sudhirj 11
  • TestResizeGolden,TestAdjustSaturationGolden fail on arm64,ppc64el,s390x

    TestResizeGolden,TestAdjustSaturationGolden fail on arm64,ppc64el,s390x

    Like this:

    === RUN   TestAdjustSaturationGolden
    --- FAIL: TestAdjustSaturationGolden (0.02s)
        adjust_test.go:238: resulting image differs from golden: out_saturation_m30.png
        adjust_test.go:238: resulting image differs from golden: out_saturation_p30.png
    --- FAIL: TestResizeGolden (0.08s)
        resize_test.go:259: resulting image differs from golden: out_resize_linear.png
    FAIL	0.173s

    I hacked up TestResizeGolden to write the image to disk (on arm64 fwiw) and here it is: foo (I checked github hasn't recompressed it). Poking around I can see that 6 pixels around the edge of the image indeed differ (for example 8, 0 is 324a26 in one image and 324b26 in another).

    This seems a bit bizarre to me, I don't see why this would differ between architectures. Some kind of difference in rounding, I assume.

    opened by mwhudson 9
  • tiff decode result is wrong!

    tiff decode result is wrong!

    When my picture is GeoTiff(128x128 BlockSize LZW compress), the Resize result is wrong.


                    src, err = imaging.Open("D:/Document/data/qdcaichu3.tif")
    		dst := imaging.Resize(src, 512, 512, imaging.NearestNeighbor)
    		log.Println(dst.Bounds(), dst.ColorModel())
    		err = imaging.Encode(w, dst, imaging.JPEG)

    Output Result: 图片 Origin Picture: 图片

    As long as you convert this image to another format or save another copy, there is no error. But software such as GlobalMap can be read correctly.

    Origin file: Number: 322420

    opened by sotex 9
  • Added DecodeWithFormat

    Added DecodeWithFormat

    In systems that ignore the file name / extension (either use UUIDs or just don't trust users) it makes sense to read the format straight from the image bytes themselves. imaging currently ignores the format while decoding.

    I believe this should be in the library instead of outside because:

    1. passing in a reader to imaging effectively destroys it, so doing another decode requires a re-read.
    2. imaging already has a Format enum and conversion maps.
    3. imaging already imports the TIFF and BMP packages, as well as GIF, PNG, JPEG. it doesn't make sense to ask clients to side-effect import all those packages again to get the proper registrations.
    4. Both Encode already takes a Format as an argument, it increases both symmetry and likeness to the stdlib for Decode to return it.
    opened by sudhirj 9
  • Crop before resize in Fill

    Crop before resize in Fill

    #83 Crop before resizing in the Fill function for the sake of efficiency.

    This breaks one test, TestFill/Fill_4x4_2x8_Top_Nearest and I'm afraid I'm not sure why, I'm pretty sure the code is correct as all other tests pass, but maybe there's a strange edge case I'm not thinking of.

    I've also added some benchmarks for the Fill function, on my machine I get speedups of around 8x:


    goos: windows
    goarch: amd64
    BenchmarkFill/Vertical_NearestNeighbor_JPEG-8         	     500	   3501987 ns/op	 7393248 B/op	      17 allocs/op
    BenchmarkFill/Vertical_NearestNeighbor_PNG-8          	     500	   3370063 ns/op	 7393200 B/op	      17 allocs/op
    BenchmarkFill/Vertical_Linear_JPEG-8                  	     100	  10374025 ns/op	 9178134 B/op	      38 allocs/op
    BenchmarkFill/Vertical_Linear_PNG-8                   	     100	  10154148 ns/op	 9178224 B/op	      38 allocs/op
    BenchmarkFill/Vertical_CatmullRom_JPEG-8              	     100	  13472248 ns/op	 9260050 B/op	      38 allocs/op
    BenchmarkFill/Vertical_CatmullRom_PNG-8               	     100	  13222394 ns/op	 9260042 B/op	      38 allocs/op
    BenchmarkFill/Vertical_Lanczos_JPEG-8                 	     100	  17240083 ns/op	 9341974 B/op	      38 allocs/op
    BenchmarkFill/Vertical_Lanczos_PNG-8                  	     100	  17819746 ns/op	 9341968 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_NearestNeighbor_JPEG-8       	    1000	   1852933 ns/op	 4049702 B/op	      17 allocs/op
    BenchmarkFill/Horizontal_NearestNeighbor_PNG-8        	    1000	   1690025 ns/op	 4049702 B/op	      17 allocs/op
    BenchmarkFill/Horizontal_Linear_JPEG-8                	     300	   5520155 ns/op	 4931467 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_Linear_PNG-8                 	     300	   5296951 ns/op	 4931474 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_CatmullRom_JPEG-8            	     200	   6946002 ns/op	 4988816 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_CatmullRom_PNG-8             	     200	   6746117 ns/op	 4988812 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_Lanczos_JPEG-8               	     200	   9024805 ns/op	 5046154 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_Lanczos_PNG-8                	     200	   8829919 ns/op	 5046162 B/op	      38 allocs/op
    ok	30.481s


    goos: windows
    goarch: amd64
    BenchmarkFill/Vertical_NearestNeighbor_JPEG-8         	    3000	    404434 ns/op	  479008 B/op	      12 allocs/op
    BenchmarkFill/Vertical_NearestNeighbor_PNG-8          	    3000	    411429 ns/op	  479006 B/op	      12 allocs/op
    BenchmarkFill/Vertical_Linear_JPEG-8                  	    2000	    877495 ns/op	  790118 B/op	      38 allocs/op
    BenchmarkFill/Vertical_Linear_PNG-8                   	    2000	    878994 ns/op	  790120 B/op	      38 allocs/op
    BenchmarkFill/Vertical_CatmullRom_JPEG-8              	    2000	   1154835 ns/op	  826726 B/op	      38 allocs/op
    BenchmarkFill/Vertical_CatmullRom_PNG-8               	    2000	   1149338 ns/op	  826732 B/op	      38 allocs/op
    BenchmarkFill/Vertical_Lanczos_JPEG-8                 	    1000	   1681033 ns/op	  862314 B/op	      38 allocs/op
    BenchmarkFill/Vertical_Lanczos_PNG-8                  	    1000	   1723007 ns/op	  862314 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_NearestNeighbor_JPEG-8       	    5000	    285236 ns/op	  550748 B/op	      12 allocs/op
    BenchmarkFill/Horizontal_NearestNeighbor_PNG-8        	   10000	    240661 ns/op	  550747 B/op	      12 allocs/op
    BenchmarkFill/Horizontal_Linear_JPEG-8                	    2000	    969941 ns/op	  963304 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_Linear_PNG-8                 	    2000	    925467 ns/op	  963306 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_CatmullRom_JPEG-8            	    1000	   1210303 ns/op	  999915 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_CatmullRom_PNG-8             	    2000	   1172325 ns/op	  999916 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_Lanczos_JPEG-8               	    1000	   1801962 ns/op	 1035500 B/op	      38 allocs/op
    BenchmarkFill/Horizontal_Lanczos_PNG-8                	    1000	   1838941 ns/op	 1035501 B/op	      38 allocs/op
    ok	30.730s
    opened by bspammer 9
  • Support limiting the number of parallel processing goroutines

    Support limiting the number of parallel processing goroutines


    thanks a lot for your work and this great library!

    I have a suggestion for limiting the number of parallel processing goroutines.

    The reason for the proposal is my use case, where I'm using the Resize function in an image processing server. The server is accessed simultaneously by multiple clients. Beside resizing images, the server also has to perform other tasks. Therefore, it's problematic that a single Resize runs runtime.GOMAXPROCS goroutines via the parallel function.

    This pull request proposes to add an exported global variable that can be used to limit the number of goroutines.

    Best regards, Marian

    opened by marianrh 7
  • Rotate90() makes image to loose quality

    Rotate90() makes image to loose quality

    I'm working with JPEG file. I've noticed that every time I rotate the image, there's an incremental loss in the image quality.

    Original: image

    20 times rotated: image

    Is there a way to avoid this?

    opened by crosslogic 7
  • AdjustSaturation


    For Adds an AdjustSaturation function.

    For converting between RGB and HSL I just used the functions in (which is MIT licensed and also by the creator of this repo as well so I don't imagine that will be a problem). I copied&pasted rather than including as an import because gift uses a different format for colors and would require a major refactor of this repo.

    Example imagingbranchescomparison

    Points of Discussion

    1. The step function is a percentage function where the percentage p that the caller supplies what percent of the way to min/max saturation the function should bring the pixel. For example, if a pixel has a saturation of 0.25 and the user supplies p=50 then the new saturation will be 0.625 because that is 50% of the way between 0.25 and 1. Is this an acceptable approach? Alternatives would be a delta (e.g. new_saturation = old_saturation + delta) or factor (e.g. new_saturation = old_saturation * factor)
    2. The saturation approach I'm using suffers from RGB clipping issues when the source image has a lot of things with high saturation already. For example: saturationclippingcmp

    I've found some articles[0][1] with proposals on how to fix this sort of issue. Think it's worth solving? I'm happy to take a shot at it, but I didn't know if you feel this library should be that opinionated or not

    [0] [1]

    opened by j-delaney 7
  • Blur performance optimization

    Blur performance optimization

    Hey just digging around for a faster blur and managed to trade a bit of memory for some speed. Offering upstream in case you want the changes.

    benchmark           old ns/op     new ns/op     delta
    BenchmarkBlur-4     23625266      20647452      -12.60%
    benchmark           old allocs     new allocs     delta
    BenchmarkBlur-4     22             30             +36.36%
    benchmark           old bytes     new bytes     delta
    BenchmarkBlur-4     1961043       2097189       +6.94%
    opened by jasonmoo 7
  • Huge image size after resize it

    Huge image size after resize it

    Can you describe please, why image files very huge?

    package main
    import (
    func main() {
    	// initial image size 688x768 ~120K
    	img, _ := imaging.Open("a1e7f78b268953dd2ddec8389ceddc49.jpg")
    	// first thumbnail 615x615 ~256K
    	th1 := imaging.Thumbnail(img, 615, 615, imaging.Lanczos)
    	_ = imaging.Save(th1, "1.jpg", imaging.JPEGQuality(95))
    	// second thumbnail 1280x960 ~448K
    	th2 := imaging.Thumbnail(img, 1280, 960, imaging.Lanczos)
    	_ = imaging.Save(th2, "2.jpg", imaging.JPEGQuality(95))

    Imagick: convert -define jpeg:size=688x768 a1e7f78b268953dd2ddec8389ceddc49.jpg -thumbnail '615x615>' 1.jpg = ~128K


    opened by max107 6
  • resize image become bigger

    resize image become bigger

    I want to resize the image to make the size smaller. But I'm suprised to find that the image becomes bigger after resizing. My code:

    import (
    func TestResizeImage(t *testing.T) {
    	srcFile := "./logo-PHOENIX.png"
    	outExt := ".png"
    	imgData, err := ioutil.ReadFile(srcFile)
    	if err != nil {
    	src, err := imaging.Decode(bytes.NewReader(imgData), imaging.AutoOrientation(true))
    	if err != nil {
    	srcFi, err := os.Stat(srcFile)
    	if err != nil {
    	logrus.Infof("srcFile: %v, size: %v", srcFile, srcFi.Size())
    	width := []int{120, 360, 480, 720, 850, 1280}
    	for _, w := range width {
    		dst := ResizeImage(src, w, w)
    		outFile := fmt.Sprintf("testdata/larger_%vx%v%v", w, w, outExt)
    		err = imaging.Save(dst, outFile, imaging.JPEGQuality(70))
    		if err != nil {
    		fi, err := os.Stat(outFile)
    		if err != nil {
    		logrus.Infof("outFile: %v, size: %v", outFile, fi.Size())
    func ResizeImage(srcImg image.Image, width, height int) image.Image {
    	isResize, height, width := calcSize(srcImg.Bounds().Dx(), srcImg.Bounds().Dy(), width, height)
    	if isResize {
    		srcImg = resizeImageCore(srcImg, height, width)
    	return srcImg
    func calcSize(originalWidth int, originalHeight int, targetWidth int, targetHeight int) (bool, int, int) {
    	if originalWidth <= targetWidth && originalHeight <= targetWidth {
    		return false, originalHeight, originalWidth
    	var temWidth = float32(originalWidth)
    	var temHeight = float32(originalHeight)
    	if originalWidth > targetWidth {
    		temWidth = float32(targetWidth)
    		temHeight = (float32(targetWidth) / float32(originalWidth)) * float32(originalHeight)
    	if int(temHeight) > targetHeight {
    		temWidth = (float32(targetHeight) / float32(temHeight)) * float32(temWidth)
    		temHeight = float32(targetHeight)
    	return true, int(temHeight), int(temWidth)
    func resizeImageCore(img image.Image, thumbnailHeight int, thumbnailWeight int) image.Image {
    	return imaging.Resize(img, thumbnailWeight, 0, imaging.Lanczos)


    === RUN   TestResizeImage
    time="2021-12-15T15:13:28+08:00" level=info msg="srcFile: ./logo-PHOENIX.png, size: 13555"
    time="2021-12-15T15:13:28+08:00" level=info msg="outFile: testdata/larger_120x120.png, size: 12946"
    time="2021-12-15T15:13:28+08:00" level=info msg="outFile: testdata/larger_360x360.png, size: 43802"
    time="2021-12-15T15:13:28+08:00" level=info msg="outFile: testdata/larger_480x480.png, size: 59066"
    time="2021-12-15T15:13:28+08:00" level=info msg="outFile: testdata/larger_720x720.png, size: 93738"
    time="2021-12-15T15:13:28+08:00" level=info msg="outFile: testdata/larger_850x850.png, size: 117574"
    time="2021-12-15T15:13:28+08:00" level=info msg="outFile: testdata/larger_1280x1280.png, size: 14634"
    --- PASS: TestResizeImage (0.11s)

    I found that resized image is 8-bit RGBA, but the original image is 8-bit colormap.


    Is there any way to keep the original bit mode?

    The image: larger_1280x1280

    opened by hyzgh 0
  • Images not get fully processed even if background is filled with base color?

    Images not get fully processed even if background is filled with base color?


    im not sure if it s a problem with the lib but im experience some issues where images not get fully „rendered“?

    Looks like this: Image

    If anyone has a tip why this happens it would be great.

    opened by Atomzwieback 1
  • how can we resize  image

    how can we resize image

    Hi buddy , My Code is :

    src2,_:=imaging.Open("./screen.png") //screen.png is px is 160*60 imaging.Resize(src2,320,120,imaging.Lanczos)

    err = imaging.Save(src2,"./example02.png")

    it can`t work , example02.png also is 160*60

    how can i resize the bigger image ?

    opened by lilei10101010 2
  • WebP support

    WebP support

    Hey @disintegration,

    I have read your comments posted a years ago saying that WebP is not widely used. However, nowadays it seems that adoption is on it's way in the web and since it's superior to JPEG, PNG or GIF in many aspects, the demand will grow. What about adding this functionality even at cost of introducing some extra dependency? Maybe implement it with some kind of an add-on mechanism?

    opened by inliquid 1
  • v1.6.2(Nov 16, 2019)

  • v1.6.1(Aug 24, 2019)

  • v1.6.0(Feb 2, 2019)

  • v1.5.0(Aug 19, 2018)

    • New decode option AutoOrientation, that sets the auto-orientation mode. If auto-orientation is enabled, the image will be transformed after decoding according to the EXIF orientation tag (if present). By default it's disabled.
    • Blur performance optimizations.
    • New FormatFromExtension helper function.
    Source code(tar.gz)
    Source code(zip)
  • v1.4.2(May 8, 2018)

  • v1.4.1(Mar 14, 2018)

  • v1.4.0(Mar 12, 2018)

    • Image processing refactoring: most functions are now faster and allocate less memory.
    • More tests and benchmarks added.
    • More encode options added: in addition to JPEGQuality there are now three GIF encode options (GIFNumColors, GIFQuantizer, GIFDrawer).
    Source code(tar.gz)
    Source code(zip)
Grigory Dryapak
Grigory Dryapak
Image - This repository holds supplementary Go image librariesThis repository holds supplementary Go image libraries

Go Images This repository holds supplementary Go image libraries. Download/Insta

null 0 Jan 5, 2022
Go package for fast high-level image processing powered by libvips C library

bimg Small Go package for fast high-level image processing using libvips via C bindings, providing a simple programmatic API. bimg was designed to be

Tom 1.9k Jun 22, 2022
Fast, simple, scalable, Docker-ready HTTP microservice for high-level image processing

imaginary Fast HTTP microservice written in Go for high-level image processing backed by bimg and libvips. imaginary can be used as private or public

Tom 4.4k Jun 23, 2022
Image processing algorithms in pure Go

bild A collection of parallel image processing algorithms in pure Go. The aim of this project is simplicity in use and development over absolute high

Anthony N. Simon 3.6k Jun 26, 2022
Image processing library and rendering toolkit for Go.

blend Image processing library and rendering toolkit for Go. (WIP) Installation: This library is compatible with Go1. go get

Guillermo Estrada 59 Dec 24, 2021
A lightning fast image processing and resizing library for Go

govips A lightning fast image processing and resizing library for Go This package wraps the core functionality of libvips image processing library by

David Byttow 697 Jun 28, 2022
Storage and image processing server written in Go

Mort An S3-compatible image processing server written in Go. Still in active development. Features HTTP server Resize, Rotate, SmartCrop Convert (JPEG

Marcin Kaciuba 458 Jun 9, 2022
A library for basic image processing in Go.

Imaging Package imaging provides basic image processing functions (resize, rotate, crop, brightness/contrast adjustments, etc.). All the image process

null 0 Nov 26, 2021
A library for basic image processing in Go.

Imaging Package imaging provides basic image processing functions (resize, rotate, crop, brightness/contrast adjustments, etc.). All the image process

null 0 Nov 26, 2021
Easily customizable Social image (or Open graph image) generator

fancycard Easily customizable Social image (or Open graph image) generator Built with Go, Gin, GoQuery and Chromedp Build & Run Simply, Clone this rep

Youngbin Han 4 Jan 14, 2022
An API which allows you to upload an image and responds with the same image, stripped of EXIF data

strip-metadata This is an API which allows you to upload an image and responds with the same image, stripped of EXIF data. How to run You need to have

Cristina Simionescu 0 Nov 25, 2021
Imgpreview - Tiny image previews for HTML while the original image is loading

imgpreview This is a Go program that generates tiny blurry previews for images t

Dmitry Chestnykh 8 May 22, 2022
magicimage is a simple image validation & save with rich feature package for net/http

Installation go get Usage examples A few usage examples can be found below. See the documentation for the full lis

Nyoman Pradipta Dewantara 2 Feb 5, 2022
Go package for decoding and encoding TARGA image format

tga tga is a Go package for decoding and encoding TARGA image format. It supports RLE and raw TARGA images with 8/15/16/24/32 bits per pixel, monochro

Sigrid Solveig Haflínudóttir 30 Mar 5, 2022
Go Perceptual image hashing package

goimagehash Inspired by imagehash A image hashing library written in Go. ImageHash supports: Average hashing Difference hashing Perception hashing Wav

Dong-hee Na 508 Jun 23, 2022
golang package to find the K most dominant/prominent colors in an image

prominentcolor Find the K most dominant colors in an image The Kmeans function returns the K most dominant colors in the image, ordered in the order o

Carl 132 Jun 28, 2022
Go package captcha implements generation and verification of image and audio CAPTCHAs.

Package captcha ⚠️ Warning: this captcha can be broken by advanced OCR captcha breaking algorithms. import "" Package captch

Dmitry Chestnykh 1.6k Jun 28, 2022
package for convert DataURLs to image

convert base64 DataURLs to image

Muhammad Al Farizzi 1 Oct 18, 2021
A Go package converting a monochrome 1-bit bitmap image into a set of vector paths.

go-bmppath Overview Package bmppath converts a monochrome 1-bit bitmap image into a set of vector paths. Note that this package is by no means a sophi

tunabay 2 Mar 22, 2022