Since this is for the mac you really should be using apple's vision framework for OCR. It smokes tesseract in both speed and accuracy.
Edit: I'm curious which LLM was used to generate the code. I fed the title of your post to claude/deepseek/qwen/codex asking to recommend a stack for this project, expecting to frown thinking that they still recommend tesseract. However, I found that they all recommend apple's vision framework. In fact the latest model to recommend Tesseract is gpt-4.1.
I recently tried to recover text from 8 frames of an office-shot YouTube video, where only a small, blurry portion of a computer screen was visible. After spending half a day with Astra on it, the conclusion was that it’s not possible to read.
Later that evening, I just paused the YouTube video on my phone, circled the part of the display with Google Lens, and it read the whole thing with pretty good accuracy. It was mindblowing :)
Mostly unrelated but fun thing I discovered earlier this year with Apple's vision - if you have text both correctly oriented and upside down in the same image, it likes to interpret the upside down text as a Cyrillic alphabet. I was trying to use it to read the text on camera lenses and it came up with all sorts of bizarre interpretations. If anyone's interested, I got around it by splitting the text at a point and unrolling it into a straight line before running OCR on it.
My own experiments with tesseract were very mixed. I did use just a locally runnable version from a public repository. Text from webpages. Sometimes it would do great but small variations could make it fail completely. Paddleocr on single line text for me has accuracy in the range of 95%
nullsanity got downvoted into oblivion, but they are correct. This is one of the many reasons why vibe coding produces worse software. The code that is generated and the best practice recommendations are completely separate. They both come from a distribution of "most common", and best practice is rarely common. Especially when a practice is first established, or in a specific niche.
Unless you are referencing some existing non vibe coded app, complaints the project being vibe coded may be just too generic at this point.
A hand coded electron project would have a discussion about electron vs native. Relevant in general but off topic in the context of this particular app.
idk about that. The big labs and their data providers are spending millions of dollars building up expert datasets. I was offered $120/hr to critique outputs and provide my own designs. Thats clean and high quality data, not the average internet word distribution
And manager types in software still haven't figured out that prototypes should not be the final product. In engineering it's common knowledge and only rarely do you take a proof of concept directly to production.
You're totally right. Apple Vision is generally way faster and more accurate on Apple Silicon. Pure Mac-only, I'd use it. (also smaller)
Main reason I went Tesseract: I want SCM to stay portable easily. It's ARM Mac for now, but the inference layer is all JS end-to-end — Transformers.js + ONNX for CLIP/SigLIP + Whisper, Tesseract.js WASM for OCR, all in plain Node workers.
A bit of background: I'm actually an iOS/macOS dev and I really love SwiftUI and AppKit — I just wanted v1 to stay portable by construction. Exploring a native Swift + MLX v2 track separately for speed.
Can you copyright things like this now that LLMs exist? I mean, up until now if a small startup has a great idea they will get bought out by big tech which will integrate (or kill) their tech. But now with LLMs can the likes of OpenAI just tell their model to make something that works similar to X (such as this project) and then get round copying laws and negate being behind the curve?
EDIT: switched to the correct spelling of copyright.
Copyrights protect the literal text of your program and binaries. Not the design and functionality. Getting Sherlocked is having your functionality duplicated, independent of the code itself.
No one thinks Apple violated Sherlock copyright. They just made it (nearly) functionally redundant.
I don't see why LLMs should make the legal part different. It's like saying if you can copyright a book considering LLMs now can copy / write a new one in just one hour. Making it faster doesn't change the legal aspect / ownership of something.
ianal but copyright law has nothing to say about being sherlocked. it's happening - virtually any software you can think of has some shit slop clone out there already
I understand why it did what it did, but I didn't want to spend the time digging in and changing its behavior.
The view options are what killed it in the end.
The thumbnails issue was just me looking at the sausage and like "ugh, I wouldn't have done that."
It's always a tradeoff between time and work. I would have done a sliding window around the current screen, but then you might have placeholders. Maybe it should do low-res first and generated hi-res thumbnails 3 pages out while scrolling. But that's a lot of work for the 10% case.
What I want is aperture back, with all the fun AI stuff and using Affinity for photo editing (which I have anyway). I'll add that to my queue of projects I guess.
How well do you think this would work on stock photography on m1 mac with 32GB ram? For example I'd like to be able to search a folder of ~2k photos for houses with palm trees. Or find photos of kitchens, or find photos of desert southwest landscapes.
Not OP, but probably because they have no idea what they are doing or what CLIP even is. And the whole thing is likely just from one llm prompt, and then they dumped the whole thing onto GitHub, undoubtedly without even looking at any of the code or architecture.
Having built something similar with CLIP on an M1, frame sampling rate is the whole ballgame. One frame a second on 12k videos is days, keyframes only got me to an overnight run.
Such a tool is very helpful for editors who manage video footage, and since 12K cameras are affordable now, I'd guess 12K actually refers to the resolution here.
I like the entire premise, the one thing stopping me from trying this is not knowing the time scales that I will need to set my computer aside for the processing of large folders of video frames, or my photos library's videos, some 12,000 videos
Because you haven't rereleased your own fork in rust yet! The "LLMs can do it" cuts both ways. If that doesn't sound worth your time then it's silly to rudely suggest it is worth someone else's.
I totally agree and I'm guilty of producing some electron crap. I think the ai explosion can be greatly improved by a new easy-for-ai but high performance and consistent ui paradigm. Would love to see a "what would html look like if it was designed for apps instead of documents from the first day" become really popular with the ai models without becoming too hard to read.
Would require you to be locked in to the one embedding model in the camera though and cameras would need to use the same or be incompatible. Would be fine with a standard model like CLIP but would leave a lot of potential on the table compared to a good way to do your own embedding for everything.
jumping straight to the right moment in a video is the useful bit here. how often does the balanced sampling miss something that only appears for a second or two?
its a cool project, but I dont want to consume someones ai slop to discern whats true. if the human wrote the page in their own words, I would have considered using it.
otherwise, I can just make my own with my own ai. why consume someones slop when I can eat my own.
Since this is for the mac you really should be using apple's vision framework for OCR. It smokes tesseract in both speed and accuracy.
Edit: I'm curious which LLM was used to generate the code. I fed the title of your post to claude/deepseek/qwen/codex asking to recommend a stack for this project, expecting to frown thinking that they still recommend tesseract. However, I found that they all recommend apple's vision framework. In fact the latest model to recommend Tesseract is gpt-4.1.
I recently tried to recover text from 8 frames of an office-shot YouTube video, where only a small, blurry portion of a computer screen was visible. After spending half a day with Astra on it, the conclusion was that it’s not possible to read.
Later that evening, I just paused the YouTube video on my phone, circled the part of the display with Google Lens, and it read the whole thing with pretty good accuracy. It was mindblowing :)
All those years of captchas must've made Google's model bulletproof
Mostly unrelated but fun thing I discovered earlier this year with Apple's vision - if you have text both correctly oriented and upside down in the same image, it likes to interpret the upside down text as a Cyrillic alphabet. I was trying to use it to read the text on camera lenses and it came up with all sorts of bizarre interpretations. If anyone's interested, I got around it by splitting the text at a point and unrolling it into a straight line before running OCR on it.
My own experiments with tesseract were very mixed. I did use just a locally runnable version from a public repository. Text from webpages. Sometimes it would do great but small variations could make it fail completely. Paddleocr on single line text for me has accuracy in the range of 95%
This. Learn all the knobs and dials, too. Useful performance gains to be made by tuning the right settings.
So the prompt was probably something like: build me x using Tesseract.
nullsanity got downvoted into oblivion, but they are correct. This is one of the many reasons why vibe coding produces worse software. The code that is generated and the best practice recommendations are completely separate. They both come from a distribution of "most common", and best practice is rarely common. Especially when a practice is first established, or in a specific niche.
Unless you are referencing some existing non vibe coded app, complaints the project being vibe coded may be just too generic at this point.
A hand coded electron project would have a discussion about electron vs native. Relevant in general but off topic in the context of this particular app.
idk about that. The big labs and their data providers are spending millions of dollars building up expert datasets. I was offered $120/hr to critique outputs and provide my own designs. Thats clean and high quality data, not the average internet word distribution
Kind of like "history is written by the victors"
Maybe the real question is: who cares?
What’s the downside risk of having "worse software" when you’re just ideating and putting things out there to see how people like it.
Your idea can be great, but if the implementing is bad, people still may not like it, and you’ll never know that’s the cause.
Worst case:
- release vibe coded tool
- on HN, someone says, d'oh, you should be using Y, not X
- give that comment to your LLM
- LLM: "The commenter on Hacker News is absolutely right, my mistake. I can easily replace X with Y if you want"
- release a new, better version of vibe coded tool
Iteration, in one afternoon.
And manager types in software still haven't figured out that prototypes should not be the final product. In engineering it's common knowledge and only rarely do you take a proof of concept directly to production.
Isn’t that why you use a plan mode? Or better, use a plan mode, revise and critique the plan, and then let it proceed to build?
On the flipside, it also leads to better software.
Hey author here! :) Great point.
You're totally right. Apple Vision is generally way faster and more accurate on Apple Silicon. Pure Mac-only, I'd use it. (also smaller)
Main reason I went Tesseract: I want SCM to stay portable easily. It's ARM Mac for now, but the inference layer is all JS end-to-end — Transformers.js + ONNX for CLIP/SigLIP + Whisper, Tesseract.js WASM for OCR, all in plain Node workers.
A bit of background: I'm actually an iOS/macOS dev and I really love SwiftUI and AppKit — I just wanted v1 to stay portable by construction. Exploring a native Swift + MLX v2 track separately for speed.
If you look at the apple photos db you'll see that there is a bunch of cached pre-analysis you can leverage for items in apple photos.
And this is why vibe coders always make inferior software.
Compared to who? Every professional developer? Someone learning to code? Fabrice Bellard?
Turns out it's possible to build something without a glorified next-character search engine afterall
Slightly offtopic, but made me wonder.
Can you copyright things like this now that LLMs exist? I mean, up until now if a small startup has a great idea they will get bought out by big tech which will integrate (or kill) their tech. But now with LLMs can the likes of OpenAI just tell their model to make something that works similar to X (such as this project) and then get round copying laws and negate being behind the curve?
EDIT: switched to the correct spelling of copyright.
copywriting is the art of writing copy for products/marketing maybe you were thinking of sherlocking [1]
1. https://news.ycombinator.com/item?id=34080326
I sure the intended word was copyright[0], as in to protect against getting sherlocked.
[0]https://en.wikipedia.org/wiki/Copyright
Copyrights protect the literal text of your program and binaries. Not the design and functionality. Getting Sherlocked is having your functionality duplicated, independent of the code itself.
No one thinks Apple violated Sherlock copyright. They just made it (nearly) functionally redundant.
I don't see why LLMs should make the legal part different. It's like saying if you can copyright a book considering LLMs now can copy / write a new one in just one hour. Making it faster doesn't change the legal aspect / ownership of something.
ianal but copyright law has nothing to say about being sherlocked. it's happening - virtually any software you can think of has some shit slop clone out there already
possibly off-topic, but for anyone interested in this on a more cross-platform / holistic basis, Immich does this
(& by "this" I mean an approximate AI search for photos & videos - I can't account for the "every frame", nor for the comparative search quality)
Tried immich and there was a lot not to like. It behooves everyone to try each one and see if it fits.
Just for product aesthetics, i believe it created a thumbnail folder with every resolution, which is annoying since i have a multi-decade 8tb library.
There were other actual issues with organization and display. But with this I realized I can just get gemini to write a DAM for me in a weekend.
Caching & overall library directory structures are configurable fwiw. I find the mobile integrations to be the biggest differentiators.
I understand why it did what it did, but I didn't want to spend the time digging in and changing its behavior.
The view options are what killed it in the end.
The thumbnails issue was just me looking at the sausage and like "ugh, I wouldn't have done that."
It's always a tradeoff between time and work. I would have done a sliding window around the current screen, but then you might have placeholders. Maybe it should do low-res first and generated hi-res thumbnails 3 pages out while scrolling. But that's a lot of work for the 10% case.
What I want is aperture back, with all the fun AI stuff and using Affinity for photo editing (which I have anyway). I'll add that to my queue of projects I guess.
How well do you think this would work on stock photography on m1 mac with 32GB ram? For example I'd like to be able to search a folder of ~2k photos for houses with palm trees. Or find photos of kitchens, or find photos of desert southwest landscapes.
YES! I can confirm it works perfectly on M1/M2/M3 machines (16g/64g).
Apple Photos can already search photos with natural language using on-device AI. Is it not working well for you?
Thanks for suggesting this. I have not tried it because the photos are on an external SMB network drive.
Why chose CLIP to do this. Have you tried small VLMs like Qwen-VL? I believe those models have video encoders can better perform at this scenario.
Not OP, but probably because they have no idea what they are doing or what CLIP even is. And the whole thing is likely just from one llm prompt, and then they dumped the whole thing onto GitHub, undoubtedly without even looking at any of the code or architecture.
And then you end up with image metadata processing code like this, which just by a cursory glance I’m sure has edge case bugs : https://github.com/allenv0/SCM/blob/main/screenshot-probe.js
Having built something similar with CLIP on an M1, frame sampling rate is the whole ballgame. One frame a second on 12k videos is days, keyframes only got me to an overnight run.
Maybe you need a minimal downscale version as well, I heard is very common technique in the video editing world.
Based on my experience, sampling rate can be tricky if what you are looking for lasted less than interval period.
Proxies. You transcode proxies from the original media, edit off those, then you use OM for the final render. NLE’s usually let you flip between them.
Have you tried scene detection? I would guess camera cuts are even less frequent than keyframes.
> 12k videos ?
you are pirating first-release movies for commercial purposes?
I think 12K is quantity not resolution.
Such a tool is very helpful for editors who manage video footage, and since 12K cameras are affordable now, I'd guess 12K actually refers to the resolution here.
I like the entire premise, the one thing stopping me from trying this is not knowing the time scales that I will need to set my computer aside for the processing of large folders of video frames, or my photos library's videos, some 12,000 videos
This would really help in video editing. Thanks!
Glad you like it :)!
This is so cool! it could be really beneficial for editors
isnt it expensive tho?
Thank you :) It's 100% free and open source!
Why is this a JS bloatware instead of native or Rust which is easier than ever now with LLM coding tools.
Because you haven't rereleased your own fork in rust yet! The "LLMs can do it" cuts both ways. If that doesn't sound worth your time then it's silly to rudely suggest it is worth someone else's.
Fair enough, but seriously, my machine has taken a beating by all these JavaScript and electron thingies.
I totally agree and I'm guilty of producing some electron crap. I think the ai explosion can be greatly improved by a new easy-for-ai but high performance and consistent ui paradigm. Would love to see a "what would html look like if it was designed for apps instead of documents from the first day" become really popular with the ai models without becoming too hard to read.
Tall order but would love to get my cpu back!
This is cool. Any way to search for People / faces / pets? Like on iOS?
How do you do that? What's the architecture? Can you guide on that?
would be lovely if picture embeddings were attached to the file by the camera but one can only dream of such futures
Would require you to be locked in to the one embedding model in the camera though and cameras would need to use the same or be incompatible. Would be fine with a standard model like CLIP but would leave a lot of potential on the table compared to a good way to do your own embedding for everything.
jumping straight to the right moment in a video is the useful bit here. how often does the balanced sampling miss something that only appears for a second or two?
how long does it takes for a FHD 90 minutes asset?
its a cool project, but I dont want to consume someones ai slop to discern whats true. if the human wrote the page in their own words, I would have considered using it.
otherwise, I can just make my own with my own ai. why consume someones slop when I can eat my own.