Forem: Rami Kronbi

We Built Sign Language AI for a Language With Almost No Dataset. Here's What That Actually Looks Like.

Rami Kronbi — Tue, 05 May 2026 16:29:25 +0000

The problem starts here: a hand, in motion, carrying meaning. Teaching a machine to read it is harder than it looks.

I was standing in a cafe in Beirut when I saw it happen.

A deaf man was trying to explain something to the barista. He signed. She stared. He tried again, slower, more deliberate, like that would help. She shook her head apologetically and reached for a notepad. He took it, wrote something down, she read it, nodded. The whole exchange took maybe four minutes for something that should have taken thirty seconds.

I stood there watching and thought: we have real-time translation for dozens of spoken languages in our pockets. Why not this?

That question became OmniSign, a real-time Lebanese Sign Language (LSL) translator. And building it taught me things about machine learning that no paper had prepared me for, because the hardest problems weren't technical. They were human.

The Dataset Problem Nobody Talks About

When you want to train a computer vision model, the standard advice is: get more data. ImageNet has over 14 million images. Common Voice has thousands of hours of speech. Even niche spoken languages have crowdsourced datasets you can start from.

Lebanese Sign Language has almost none of that.

LSL is a distinct language, not a transliteration of Arabic, not a derivative of French Sign Language, though it shares some roots. It has its own grammar, its own spatial logic, its own regional quirks. And it is used by a community that has been largely invisible to the tech world.

So before I could write a single line of model code, I had to figure out how to build a dataset from scratch.

This is what the unglamorous middle of an ML project looks like. Every frame, reviewed. Every label, decided by a human.

Finding People Who Would Actually Help

The first challenge was access. I needed signers willing to be filmed, and not just willing, but patient enough to repeat the same sign dozens of times under different conditions, at different speeds, with different lighting. And they had to trust that this wasn't going to end up as some project that got submitted, got a grade, and disappeared.

The deaf community has seen a lot of that. Technology built about them, not with them.

Getting past that took time and relationship, not code. It meant showing up, explaining what the goal actually was, being honest about what the system could and couldn't do. It meant involving people in decisions, not just data collection.

Once we had that trust, the filming itself was its own challenge. We recorded in different environments: different backgrounds, different light sources, indoors and outdoors, because a model trained only in a clean lab setting will fail spectacularly in a pharmacy with fluorescent lights and motion blur.

The Variation Problem

Here's something I didn't fully appreciate until I was knee-deep in footage: sign languages have dialects.

Not in the same loose way people use that word. I mean real, meaningful variation. A sign that means one thing to someone from one part of Lebanon might look subtly different to someone from another region. Age matters. Individual signers develop personal style. Some people sign large and expansive; others keep everything close to the body.

This is actually true of spoken languages too, but for speech recognition, you have decades of research and millions of data points to smooth out that variation. For LSL, every variation we encountered was a new challenge to solve with whatever data we had.

Our solution was imperfect but pragmatic: we over-indexed on signer diversity rather than sign volume. Fewer total signs, more variation per sign. The model had to learn that a sign is a category, not a specific hand shape at a specific moment.

MediaPipe hand landmarks: 21 points per hand, tracked in real time. The model doesn't see a hand. It sees a skeleton, moving through space.

What "Good Enough" Means When There's No Benchmark

This is the question that kept me up at night: how do you know your model is good?

For most ML tasks, you have benchmarks. You can compare your accuracy to the state of the art, see where you land, iterate. For LSL, there was no benchmark. No prior model to compare against. No established test set.

So I had to define what success looked like from first principles, and that forced an uncomfortable honesty: the only real measure of success was whether the people who use LSL found the tool useful.

We demoed the system to members of the deaf community. We watched how they used it. Where it hesitated, where it failed, where it surprised us by working. That feedback loop, messy and qualitative as it was, became more valuable than any metric I could compute.

The system isn't perfect. It's probably not close to perfect. But it translated in real time, in front of real people, and some of them smiled when it worked. That felt like a more honest measure of success than an accuracy number on a test set I built myself.

What I'd Tell Someone Starting This Problem

Don't start with the model. Start with the community.

Not because it's the ethical thing to do (though it is), but because you will build the wrong thing if you don't. The assumptions you make in isolation, about what signs to include, what variation looks like, what "correct" even means, will be wrong in ways that matter.

The dataset is not a preprocessing step you get through before the real work starts. The dataset is the work. In low-resource settings, every annotation decision, every filming session, every signer you include or exclude, shapes what the model can and cannot do. That deserves the same care and intention as the architecture.

And finally: ship something. An imperfect tool that someone can actually use is worth more than a perfect model that lives in a notebook. The pharmacy moment that started all of this, that man and that pharmacist, they don't need 99% accuracy. They need something that works well enough, right now, in the real world.

That's what we were building toward. And we're not done yet.

If you're working on low-resource sign language AI or have LSL data you'd like to contribute, I'd genuinely love to talk, reach me at ramikronbi.com.*

Seeing in the Dark: Real-Time Thermal Super-Resolution (That Actually Runs on Edge Devices)

Rami Kronbi — Mon, 02 Feb 2026 00:13:53 +0000

Thermal cameras are practically superpowers. But there's a catch: unless you have $20,000 to drop on military-grade hardware, thermal vision looks like a blurry, low-res mess.

A few months ago, I was working on a drone project. The goal was simple: strap a thermal camera to a drone and detect objects in real-time. It sounds like something out of a sci-fi movie, flying at night, spotting heat signatures, perfect situational awareness.

However, the "objects" in question were just glowing blobs. A person looked like a smudge; a car looked like a slightly larger smudge. The resolution on affordable thermal sensors is horribly low. For a computer vision model trying to do object detection, this is a nightmare. You can't classify what you can't see.

I had two options:

Buy a high-resolution thermal camera (and I live off of noodles for the rest of my life).
Fix the hardware limitations with software.

I decided to build a Deep Learning model to upscale these low-res thermal images into crisp, high-definition video in real-time.

The Problem: Why Standard AI Failed Me

If you've messed around in image upscaling, you've probably heard of ESRGAN or similar "Super-Resolution" (SR) models. They are fantastic at taking a tiny JPEG and turning it into a 4K wallpaper.

So, why not just use that?

They are too slow. Most state-of-the-art super-resolution models are heavy. They utilize millions of parameters. On a massive GPU, they might run at 5 or 7 FPS. That's fine for photos, but for a drone flying at 15kph? That latency is fatal. By the time the frame is processed, the drone has already crashed into the tree it didn't see.
Thermal is not RGB. Thermal images don't have "colors" in the traditional sense; they have temperature gradients. Standard models trained on ImageNet (cats, dogs, and cars) hallucinate textures that don't exist in heat maps. They try to add "fur" to a heat blob.

I needed an architecture that was lightweight, incredibly fast, and understood the physics of heat.

The Solution: Enter IMDN (and a lot of coffee)

I settled on an architecture called IMDN (Information Multi-Distillation Network).

Without getting too bogged down in the math (the code is onsuper resolution GitHub if you want the nerdy-details), the brilliance of IMDN is that it doesn't try to reconstruct the entire image at every single layer.

Instead, it uses a "distillation" process. It extracts features, keeps what's useful, and passes the rest down the line. This drastically reduces the computational cost.

What is also interesting about this model is that you can train it to upscale to any scale you want (2x, 3x, 4x, 5x, etc.). You aren't limited to fixed increments, giving you the flexibility to balance resolution and speed exactly how your project needs it.

Implementing the architecture was tricky, specifically adapting the Information Distillation Blocks (IDB) to handle single-channel thermal data effectively without losing the high-frequency details (the sharp edges where hot meets cold).

But the architecture was only half the battle.

The Secret Struggle: The Data Nightmare

In Deep Learning, everyone talks about the model, but the real war is won in the dataset.

There is no "ImageNet for Thermal Super-Resolution" that you can just download and hit train. I had to get creative. I spent weeks pulling data from widely different sources, and manually curating a massive mixed dataset.

This was the hardest part of the project. Thermal data is noisy and the resolutions vary wildly. I had to clean, normalize, and align thousands of images to create a "Ground Truth" that the model could actually learn from.

I also used a transfer learning trick: leveraging weights from RGB domains and "teaching" them to interpret thermal gradients, which gave the model a head start on understanding edges and shapes.

The Results: Breaking the Real-Time Barrier

After weeks of training and tweaking the loss functions to prioritize thermal contrast, the results were… honestly, better than I expected.

The Metrics:

PSNR: 34.2 dB (This is the signal-to-noise ratio. Anything above 30 is considered excellent quality).
SSIM: 0.840 (Structural Similarity - meaning the upscaled image actually looks like the original scene, not a hallucination).

You can see the difference immediately. The "blob" on the left becomes a distinct object with edges and shape on the right.

The Speed Test

This is where the IMDN architecture shines. On my laptop (RTX 3070), the model achieves:

~130 FPS at 2x scale
~60 FPS at 4x scale

That is absurdly fast. That's not just "real-time"; that's "faster than the camera can record."

The "Whoa" Moment: Edge Deployment

Here's the thing, the drone can't carry my laptop :) However, it carried an Nvidia Jetson Orin

Before delving into how it ran on the Jetson, it is important to note that what is considered real-time for thermal images differs from RGB. A thermal camera has at best 20 FPS acquisition rate, so running the model at 20–30 FPS is considered realtime, since you're utilizing all the bandwith of the camera.

To Achieve 20–30 FPS on Jetson, the following tweaks were made:

Pipeline was implemented in C++
Model was converted to TensorRT (~97% conversion accuracy)
Multithreaded Inference with some optimizations

30 FPS on an edge device is the holy grail. It means you can run this super-resolution model inline with your object detection model. The drone sees the low-res thermal frame, upscales it to HD, and detects the object , all in less than 20 milliseconds.

Why This Matters

This isn't just about making cooler-looking images. This is about accessibility.

High-resolution thermal cameras cost a fortune. By using efficient AI, we can take a cheap, low-res sensor and simulate the performance of a sensor that costs 10x as much.

For search and rescue drones, autonomous vehicles driving at night, or industrial monitoring, this is a game changer. We can finally have high-fidelity thermal vision without the high-fidelity price tag.

Attribution

I have open-sourced the code for this, however a bit of attribution would be nice :)

Portfolio: Rami Kronbi
LinkedIn: Rami Kronbi
GitHub: Kronbii
SRC: Thermal Super Resolution

AI Should Serve Society - Not Just Industry and Billionaires

Rami Kronbi — Fri, 09 Jan 2026 22:16:28 +0000

Build with purpose. Others will follow.

AI is moving fast. It is moving faster than our laws, faster than our ethics, and often, faster than our collective sense of responsibility.

The real question isn’t how powerful AI can become.

The question that keeps me up at night is who does it actually serve?

Right now, the vast majority of AI innovation is optimized for three things: scale, profit, and market dominance.

And look — that’s not inherently wrong. Businesses need to grow.

But it is incomplete.

When AI serves only industry titans and billionaires, we miss out on its most profound potential: the ability to uplift society at large.

Technology Is Never Neutral

We have to stop pretending that algorithms are objective.

Every model we train, every dataset we curate, and every deployment strategy we choose reflects a human choice.

We are constantly answering silent questions:

What problem are we solving?
Who actually benefits from this solution?
And who gets left behind?

When we design purely for efficiency or revenue, technology naturally gravitates toward the people who already have money and power. It follows the path of least resistance.

But society’s hardest problems — accessibility, safety, healthcare gaps, educational inequality, and the climate crisis — rarely sit at the top of a revenue roadmap.

That is exactly why leadership matters.

Using AI for Society Is a Choice

Building AI for social good doesn’t mean abandoning technical excellence or innovation. It means redirecting that brilliance with intention.

True leadership in this space — whether you are an engineer, a researcher, or a founder — isn’t about who builds the biggest model.

It’s about choosing problems that matter, even if they don’t scale immediately.

It’s about designing systems people can understand and trust, rather than black boxes that alienate them.

It’s about measuring success by the impact you leave on a community, not just the valuation you raise in a seed round.

How We Actually Do This

So how do we move this from an abstract ideal to reality?

It starts by getting out of the bubble — building from real human pain points, not tech-first ideas looking for a problem.

It means collaborating outside the tech echo chamber: sitting down with educators, doctors, and community leaders who understand the nuance of the problems we’re trying to solve.

It means designing for constraints and accessibility, not just for the ideal user with the fastest internet connection.

Sometimes, the most revolutionary thing you can do is ship a smaller, focused solution that solves one real problem incredibly well.

Building Where Nothing Existed: A Personal Example

My team and I experienced this firsthand when we built OmniSign.

We saw a massive gap in accessibility for the Deaf community in Lebanon — there was no real-time tool to bridge the communication barrier.

But when we started, we hit a wall. There wasn’t even a dataset for Lebanese Sign Language.

The resources didn’t exist because the market hadn’t deemed it “profitable enough” to build them.

We could have stopped there.

Instead, we realized that if we wanted AI to serve this community, we had to do the heavy lifting ourselves.

We built the dataset from scratch and developed the model to translate Lebanese Sign Language in real time.

We didn’t wait for permission. We didn’t wait for big tech.

We built it because it was necessary.

For more insight, visit the official project website.

The Kind of AI We Should Be Proud Of

The AI worth building isn’t just faster — it’s safer.

It doesn’t blindly replace people. It empowers them.

It reaches those usually written off as “not the target market.”

This isn’t about rejecting industry. It’s about expanding our definition of responsibility.

Final Thought

AI is going to shape society whether we intend it to or not.

The difference between a future of exploitation and one of empowerment is who leads the conversation.

If you are building AI today, you are already shaping that future.

The real power move isn’t optimizing for the top 1%.

It’s choosing to build for the rest of us.

Build with purpose. Others will follow.