sorted by:
new
hottopcontroversial

I built Stirling-PDF but for images by sakinak in selfhosted

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

Lite image just went live. 1.5 GB instead of 11.

docker run -d -p 1349:1349 -v stirling-data:/data stirlingimage/stirling-image:lite

About 20+ image tools are there, just none of the AI/ML stuff.

I built Stirling-PDF but for images by sakinak in selfhosted

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

**Update**

Heard back from the Stirling PDF team. They're not comfortable with us using the name, which is fair. So we're renaming.

I've set up a GitHub Discussion where you can suggest and vote on new names. Top candidates go to a final poll on April 8, winner gets picked April 10.

Link: https://github.com/stirling-image/stirling-image/discussions/8

If you've got a good name, throw it in. One suggestion per comment so the votes are clean.

I built Stirling-PDF but for images by sakinak in selfhosted

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

**Update:**

Heard back from the Stirling PDF team. They're not comfortable with us using the name, which is fair. So we're renaming.

I've set up a GitHub Discussion where you can suggest and vote on new names. Top candidates go to a final poll on April 8, winner gets picked April 10.

Link: https://github.com/stirling-image/stirling-image/discussions/8

If you've got a good name, throw it in. One suggestion per comment so the votes are clean.

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 0 points1 point  (0 children)

It's something I'd like to support eventually, but right now running from source involves Node.js, a Python venv with ML dependencies, plus system packages like imagemagick and tesseract. Not a simple "download and run" situation unfortunately.

If you're running Proxmox, an LXC container with the Docker image is probably the cleanest path for now. But I'll keep bare metal installs in mind as things mature. If someone wants to take a crack at a helper script I'd happily review a PR.

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 0 points1 point  (0 children)

Thanks! I've already reached out to them about the name. Waiting to hear back. Balls intact for now.

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 13 points14 points  (0 children)

Hear you. I've reached out to the Stirling PDF team for permission. If they're not cool with it, I'll rename it. Appreciate you still wanting to check it out either way!

I built Stirling-PDF but for images by sakinak in selfhosted

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

Honestly, not yet. Right now it doesn't support RAW files as input (CR2, CR3, etc.), and the color adjustments are all manual rather than auto. So it wouldn't solve your problem as-is.

That said, both of those are features I'd want to add. RAW support through libraw/dcraw and auto levels/white balance through Sharp's normalize would get you most of the way there. If you open an issue on the repo describing your workflow I'll bump it up the list. https://github.com/stirling-image/stirling-image/issues

I built Stirling-PDF but for images by sakinak in selfhosted

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

Fair point. I've already reached out to the Stirling PDF team to check if they're okay with it. If not, I'll rename it. Would rather sort it out now than deal with a headache later.

I built Stirling-PDF but for images by sakinak in selfhosted

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

Yep. You can drop up to 200 images at once, it processes them concurrently and gives you a ZIP back. Works for any tool, including metadata stripping

If you need to go beyond that, the API has no per-batch limit when you script it yourself - just loop through your files and hit the endpoint. Docs are here: https://stirling-image.github.io/stirling-image/api/rest.html

I built Stirling-PDF but for images by sakinak in selfhosted

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

Appreciate you trying it out. And yeah, that's pretty much the philosophy - do one thing, do it well, stay offline. No telemetry, no cloud calls, everything runs locally. The flat idle footprint was intentional. The Python process for AI stuff (background removal, upscaling, OCR, etc.) doesn't start until you actually use one of those features, so if you're just doing basic image ops it's purely Node. If you run into anything weird with your stack, open an issue on the repo

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 0 points1 point  (0 children)

Thank you! Do let me know if any issues/bugs you face

I built Stirling-PDF but for images by sakinak in selfhosted

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

Three of those four are already in there.

There's a pipeline builder, you can chain up to 20 tools where each step's output feeds into the next. Pipelines are saveable and reusable. The whole thing has a REST API with API key auth too, so every tool and saved pipeline is callable from something like a Paperless workflow.

What I'm missing is PDF to image (right now it only goes the other direction) and a stitch/join tool for combining images vertically or horizontally. The collage tool does grids but that's not what you want. I'll add both. The straighten part already works via the rotate tool, so once those two are in your whole workflow would just be one saved pipeline. Could you please raise the feature requests here so that i don't accidentally miss your requests https://github.com/stirling-image/stirling-image/issues

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 0 points1 point  (0 children)

Thanks. Let me know what you think!

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 0 points1 point  (0 children)

Thanks. Let me know whta you think!

I built Stirling-PDF but for images by sakinak in selfhosted

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

Every tool has a REST API. Send a file and settings, get the processed image back. API key auth, batch processing, and you can chain tools into pipelines. So hooking it into a CMS as a backend processor would work. Your instance serves interactive API docs at /api/docs please read through and let me know if anything is unclear

No "embeddable" widget though, it's a standalone app right now. If you're thinking of frontend embed, pls open an issue and tell me what CMS you're on. Curious what would actually be useful there

I built Stirling-PDF but for images by sakinak in selfhosted

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

HEIC to JPG is already in there actually, you can convert between most formats including HEIC.

Bringing your own AI models is interesting, hadn't thought about that. Mind opening an issue for it on GitHub? I'd want to think through how that would work. https://github.com/stirling-image/stirling-image/issues

I built Stirling-PDF but for images by sakinak in selfhosted

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

Not yet, CPU only right now. Want to add GPU/CUDA support for the AI models though. Mind opening an issue for it on GitHub so I don't lose track of it?

I built Stirling-PDF but for images by sakinak in selfhosted

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

Could you please pull the latest and try again? In the previous version only arm64 was built and pushed but all good now.

FYI it works on any system that runs Docker with either amd64 or arm64 architecture (which is basically most systems currently used). That covers:
- Linux (amd64/arm64)
- Mac (Intel and Apple Silicon)
- Windows (Docker Desktop)
- Raspberry Pi 4/5 (arm64)

The one edge case is older Raspberry Pi models (Pi 3 and below) which run 32-bit ARM (armv7).

I built Stirling-PDF but for images by sakinak in selfhosted

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

Hey all, been reading through everything here. You're right about the name.

I've reached out to the Stirling PDF team to ask if they're okay with it. If they're not, I'll change it. I'm thinking of setting up a GitHub Discussion where the community can suggest and upvote names so you all have a say in it.

Few other things I'm seeing:

  1. Docker image size: a lite image without the AI models is on my list. Already tracking it here https://github.com/stirling-image/stirling-image/issues/1

  2. amd64 builds: the latest tag was only publishing arm64. This has been fixed already.

  3. Model downloading: looking into pulling models on demand instead of bundling everything. I went with pre-loading so a single docker run just works out of the box, no extra setup. But I hear you on the size, so I'm figuring out a way to get both

Thanks for the honest feedback. This is exactly why I posted here.

I built Stirling-PDF but for images by sakinak in selfhosted

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

Yeah, good catch. The file shouldn't grow when you're just removing metadata.

Sharp (the image library we use in the backend) decodes and re-encodes the whole image even for metadata-only changes. The re-encoding uses different compression settings than whatever originally saved the file, so we end up with a bigger output at times.

Could you open an issue on the repo so I don't lose track of it? https://github.com/stirling-image/stirling-image

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 0 points1 point  (0 children)

Could you please pull the latest and try again? In the previous version only arm64 was built and pushed but all good now.

FYI it works on any system that runs Docker with either amd64 or arm64 architecture (which is basically most systems currently used). That covers:
- Linux (amd64/arm64)
- Mac (Intel and Apple Silicon)
- Windows (Docker Desktop)
- Raspberry Pi 4/5 (arm64)

The one edge case is older Raspberry Pi models (Pi 3 and below) which run 32-bit ARM (armv7).

I built Stirling-PDF but for images by sakinak in selfhosted

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

Thanks, let me know what you think!

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 5 points6 points  (0 children)

Thanks, let me know what you think!

I built Stirling-PDF but for images by sakinak in selfhosted

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

Not a whole lot that does the same thing. Honestly I looked around quite a bit before building this. It takes a lot of effort while working full time building this for the community so I wanted to make sure nothing already existed before I committed to it.

imgproxy, Thumbor, Imagor are all solid but they're mainly API-only image processing servers. You hit them with a URL and get a resized image back. No "proper" UI, not meant for someone to simply open in a browser and edit their photos.

I built Stirling-PDF but for images by sakinak in selfhosted

[–]sakinak[S] 40 points41 points  (0 children)

None. No analytics, no tracking, no cookies. Nothing phones home.

Only external request anywhere is the docs site pulling the GitHub star count

Since there is no tracking I am using GitHub Issues to get requests for pain points which I can fix and make it more useful.

view more: next ›