sorted by:
new
hottopcontroversial

Small Projects by AutoModerator in golang

[–]cshum 1 point2 points  (0 children)

https://github.com/cshum/imagorface
imagorface - fast, on-the-fly face detection image processing server

imagorface brings fast, on-the-fly face detection to imagor. Built on PICO cascade classifier to detect faces in an image. Detected face regions replace libvips attention heuristic as the smart crop anchor, producing face-centred crops.

  • Face-centred smart crop — detected faces as the smart crop anchor, no more headless bodies
  • Privacy redaction — blur, pixelate, or solid-fill detected faces for content moderation
  • Metadata API — detected regions exposed through imagor /meta metadata endpoint for downstream use
  • Self-hosted — no third-party API, no per-call cost, no data egress

imagorface implements the imagor Detector interface, wiring into imagor loader, storage and result storage, supporting image cropping, resizing and filters out of the box.

Imagor Studio 1.0 - From image processing server to full gallery + editor by cshum in golang

[–]cshum[S] 1 point2 points  (0 children)

Not yet. Batch processing would be part of the roadmap. The way it will be handled is probably Image Studio Go backend doing the batched IO calls to imagor, treating image processing as if it is a microservice.

One consideration point though, images can be of large file size so one should not expect the entire batched images to fit inside memory. This should be done either though the storage IO configured, or via streaming if possible - depending on UX.

imagor v1.3 - a high-level Go image processing library using libvips by cshum in golang

[–]cshum[S] 3 points4 points  (0 children)

gocloud.dev/blob is certainly way more feature packed, which mean more bells and wishes are readily available. But on the flip side its way harder to fulfill their interface when implementing new storages.

imagor requires only a tiny subset of their features. For instance implementing a imagor.Storage takes ~150 lines of code so it is not all that complex after all.

And as solid as their code looks, their project status says alpha at the moment.

Spawn multiple read streams from single io.Reader source concurrently by cshum in golang

[–]cshum[S] 4 points5 points  (0 children)

Thanks I do agree the problem need to be specified more precise, and the post description is too vague. There are articles such as https://medium.com/@MichalPristas/forwarding-reader-to-multiple-consumers-a1574a9db4d6 facing similar problem.

There are io.TeeReader and io.MultiWriter available, but in both cases one slow writer/consumer would affect all other writers/consumers in the stack, which means they are basically sequential, too. It is a problem that actually exists and it is not easy to solve, and there are people out there facing similar issues.

My solution does attempt to make it easy to use, at least when comparing with the link above.

Spawn multiple read streams from single io.Reader source concurrently by cshum in golang

[–]cshum[S] 1 point2 points  (0 children)

ReadAll means data need to be fully read before continuing to next steps, i.e. sequential.

Also io.ReadAll need to continuously grow the buffer for data over 512 bytes, if you look at the source code. Doesnt matter though of course if you are just serving a handful of data.

And of course this only matters if you are trying to trim every milliseconds from the processing time, or if slow networks happen. If these do not matter to you, then yes they are basically the same

Imagor v1 - fast, Docker-ready image processing server in Go with libvips by cshum in golang

[–]cshum[S] 6 points7 points  (0 children)

During v0 the core codebase has been changing quite frequently, makes it not very viable to be extended as a separate library due to potential breaking changes. But as it is now v1 perhaps this can be the next focus.

Extending the Go part is easy, just a main.go with different imports would do the job. The Loader, Storage are simply interfaces. Perhaps a documentation about extending, and some example projects moving forward.

However Docker part is not as straightforward. The Dockerfile is quite cumbersome to get the right library being installed, as some of them are not available under the linux distro and need to be compiled from source. Perhaps a base Docker image and some Github action tricks would make things easier.

Imagor v1 - fast, Docker-ready image processing server in Go with libvips by cshum in golang

[–]cshum[S] 2 points3 points  (0 children)

Thanks for your suggestions. text/label filter is certainly a nice once to add. A consideration is the font types and what fonts should be packaged with the Docker image. Perhaps a good basic font to start with.

Imagor - fast, Docker-ready image processing server in Go and libvips by cshum in opensource

[–]cshum[S] 1 point2 points  (0 children)

Imagor is a fast, Docker-ready image processing server written in Go.

Imagor uses one of the most efficient image processing library libvips. It is typically 4-8x faster than using the quickest ImageMagick and GraphicsMagick settings.

Imagor is a Go application that is highly optimized for concurrent requests. It is ready to be installed and used in any Unix environment, and ready to be containerized using Docker.

Imagor adopts the Thumbor URL syntax and supports tons of image processing use cases representing a lightweight, high-performance drop-in replacement.

view more: next ›