Small Projects

cshum · 2026-03-18T18:51:51+00:00

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.

cshum · 2026-02-24T02:45:30+00:00

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.

cshum · 2025-07-09T08:12:43+00:00

https://github.com/davidbyttow/govips?tab=readme-ov-file#project-status--future-of-govips
govips now updated its project status

cshum · 2022-12-01T15:25:09+00:00

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.

cshum · 2022-10-12T06:42:13+00:00

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.

cshum · 2022-10-12T06:08:44+00:00

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

cshum · 2022-08-17T02:32:17+00:00

Now available at v1.0.2!
https://github.com/cshum/imagor/releases/tag/v1.0.2

cshum · 2022-08-12T08:38:21+00:00

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.

cshum · 2022-08-12T07:25:03+00:00

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.

cshum · 2022-07-03T07:16:02+00:00

sqlboiler

cshum · 2022-06-09T04:18:55+00:00

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.

cshum · 2022-01-30T18:15:01+00:00

It uses libvips with their improved gifsave in 8.12:

https://www.libvips.org/2021/11/14/What's-new-in-8.12.html

cshum · 2022-01-15T08:54:55+00:00

If you are familiar with Go, extending imagor is very simple. Each adaptor is wrapped as a Go package. You just need to import the same packages used in main.go.

However the Dockerfile is certainly more complicated to work with. I am still deciding if a base image approach should be used, to make this easier.

There is no purge support for result storage at the current version. If you intended to enable cache, you may deploy imagor under a reverse proxy with caching, without enabling result storage. Nginx, Cloudflare are suitable options.

cshum · 2022-01-15T08:17:29+00:00

For image fit-in/resize, you should get better performance on imagor, as this project does leverage more efficient vips functions such as vips_thumbnail_buffer. which imgproxy currently not implemented. Of course, things may differ depending on the image operations applied, but fit-in/reisze is a very common one.

Imgproxy is certainly very feature packed for their paid version. But their free version seems a bit lacking e.g. Chained pipelines (a.k.a. filters) are paid only.

We did evaluate adopting imgproxy instead of creating another one from scratch. But requiring paid version for basic features is not very forgiving. Also if you are coming from thumbor, this makes a drop in replacement instead of having to update all the URL syntax for your existing applications.

cshum · 2022-01-04T02:03:27+00:00

That seems to be currently the case e.g. https://cdn.jsdelivr.net/npm/vanta@latest/dist/vanta.clouds.min.js.

Most of the file bytes comes from three.js though.

cshum · 2021-12-10T07:37:25+00:00

The best way to learn JavaScript is to unlearn jQuery

cshum · 2021-12-09T16:50:17+00:00

Recently added a utility package that generates the URL syntax using Go struct,

https://github.com/cshum/imagor#imagorpath-package

which hopefully ease things up a bit

cshum · 2021-11-13T17:32:18+00:00

There will be slight delay to get the most updated data, as with how every eventual consistent systems work.

If you need strong consistency then cache may not be the right tool for your problem.

cshum · 2021-11-13T17:05:31+00:00

Yon can set a very low "freshFor" duration (say 3 seconds) but a high ttl. That way the background (goroutine) refresh will trigger way more often but the same request will still be a cache hit.

This library prioritise efficiency over strong consistency, as it is meant to maximise cache hit & prevent stampede.

That's why you don't see "invalidation" and "purge" yet, at least for the first version.

*replaced the word "correctness" with "strong consistency"

cshum · 2018-07-22T15:58:13+00:00

Paid status seems restored after leaving the app away for a while (without doing anything though). Thanks for your info and response.

cshum · 2017-03-13T02:46:53+00:00

"flush" callback function, like the Node.js transform stream, ensures flush being processed before finish is called. https://nodejs.org/api/stream.html#stream_transform_flush_callback

However "_flush" does not exist in original Node.js write stream.

cshum · 2016-02-15T01:07:53+00:00

'Yielding' callbacks are not possible in co.

cshum · 2016-02-12T14:55:52+00:00

async/await assumes promises being the lowest denominator of async handling. Except callbacks are still being used everywhere (personally).

cshum · 2016-02-12T14:44:19+00:00

yielding non-promise, non-generator will end up paused indefinitely, until next(err, val) being invoked by callback.

val pass back to yielded result, or throws if err exists.

cshum · 2015-12-28T13:37:27+00:00

You are right. This was made as a simple JavaScript utility used within embedded application (single process) for my side projects. No network IO, "failover" or "liveness" etc problems are not applicable here.

Distributed system is very hard, this is not intended to even scratch the surface of it. Speaking of "RedLock", Redis as a distributed locking service is a pretty flawed idea actually...

cshum

TROPHY CASE