A Project Blog by
Yohann Ian
AI / ML Engineer
Master’s Project (2026)
Spiking Neutral Networks
If you would rather dive into a technical reading of this, check out my arXiv style paper. Otherwise, stay on this page to have the quick and sexy version.
LINK: https://drive.google.com/file/d/16n5x_bShTXwNpNMHjMrbj3vzYMf3U7Ip/view?usp=sharing
Spiking Neural Network Object Detector
For my Master’s thesis, I use an SNN-modified YOLO detector to see in the dark. Neuromorphic cameras meet spiking neural network for low light object detection.
- PyTorch
- SNNs
- Neuromorphic Vision & Data Processing
- Object Detection
- Model Fine-Tuning & Training
- Ablation Research
- Visual Studio
- Python
Obstacles.
If the Cameras Don’t See Them, Your Autonomous Car Can’t Avoid a Collision.
But Light is Scarce at Night.
Detecting Cars and Pedestrians Is Difficult…
How Do We Improve Detection?
Project
I combine Spiking Neural Networks (SNNs) with Event Cameras to Benchmark in Low Light
It’s a world-first contribution. I could not find anyone else in the global research community who has applied SNNs to neuromorphic night time data.
Event cameras offer a native advantage by interfacing with SNNs. Why?
The concept of Sparsity is native to both SNNs and Event Cameras.
Object detection is event driven, saving computational power vs. Convolution Neural Networks.
Some Basics
Spiking Neural Networks are capable of rate encoding… encoding information based on signal frequency.
Spiking Neural Networks?
Let’s start here.
Spiking Neural Networks (SNNs) are artificial neural networks that closely mimic biological brains by transmitting information through discrete, time-dependent electrical pulses or "spikes" rather than continuous numerical values. Because they only process data when spikes occur, SNNs are highly event-driven and significantly more energy-efficient than traditional deep learning models.
That “event-driven-ness” is what we mean by “Sparsity” moving forward.
Look at the middle. Viewing an event camera image is like looking at the underside of a nail bed.
Event Cameras?
Event cameras are bio-inspired visual sensors that measure pixel-level changes in brightness asynchronously, rather than capturing full images at a fixed frame rate. Because they only output data when movement or lighting changes occur, they offer extremely high temporal resolution, low latency, and low power consumption without motion blur.
It’s an incredibly rich field of research on its own. But I won’t direct you away from my page right now. I’ll leave an event camera research link at the bottom in case you are interested.
SpikeYOLO?
The innovation for SpikeYOLO is the use of a Meta SNN Block which strengthens signals against spike degradation and weak transmission to the deeper layers.
SpikeYOLO is SNN-modified YOLO object detection model. I use it to process neuromorphic event video frames for my low-light detection research.
Sources:
I Can’t Skip This Part
A page from Leonardo Da Vinci’s actual notebook. He asked a lot of questions.
Research Questions
If you’re in academia, not having this is a cardinal sin. If you’re not a researcher, all this might be a little dense. Bear with me. Without these, we cannot have a research direction. These are:
How does SpikeYOLO's object detection performance vary across bright, moderate, dim, and pitch night lighting conditions on the DSEC-Detection neuromorphic dataset?
Do car and pedestrian classes respond differently to decreasing illumination, and what physical mechanisms account for these differences?
Does increasing the number of temporal timesteps T improve detection performance, and does the benefit interact with lighting condition?
How critical is re-parameterisation convolution to SpikeYOLO's performance on sparse low-light event streams compared to its reported effect on dense COCO data?
Let’s Begin
Thoughts:
Here is the shape of the entire study.I take the DSEC event streams, sort every test sequence into one of four lighting buckets by inspecting how dense the events are.Then, I run each sample through my preprocessing pipeline, fine-tune SpikeYOLO on the result, and finally evaluate each lighting bucket on its own. Keeping the buckets separate at evaluation is the whole point: it is the only way to see how performance moves as the light changes.Step 1: Experiment Paradigm
The whole experiment, at a glance
From raw event streams to a lighting-stratified test
Five stages, run in order. The same model comes out the far end and is graded identically in every lighting condition.
-
01
Acquire & sort by light
DSEC event-camera streams are split into four buckets by how bright the scene is: bright, moderate, dim, and pitch night.
-
02
Preprocess the events
Raw, uneven event data is turned into fixed-size image-like tensors the model can read, encoding brightening and darkening across time.
-
03
Fine-tune SpikeYOLO
The detector starts from a pretrained Gen1 checkpoint and is fine-tuned on this data, keeping only its best-performing snapshot.
-
04
Attempted extension: LearnedThresholdLIF Documented, not adopted
A learnable firing threshold was built and tested. It collapsed during training, and the cause was traced and reported as a negative result.
-
05
Evaluate, lighting by lighting
The one locked model is scored separately in each condition, with an identical bar for a correct detection throughout.
BrightFull lightModerateReducedDimLow lightPitch nightPeak▲ Detection is strongest in the darkest condition.
All event data has to be preprocessed from original capture format for ingestion into SpikeYOLO data pipeline. My code below is one such example of preprocessing the low light sequence.
All data had to be preprocessed.
Step 2: Data Prep
Turning raw events into something the model can actually see
Raw event data is awkward. It arrives as a list of asynchronous tuples, each one an (x, y, time, polarity) spike, and a single sample can hold anywhere from zero to five hundred thousand of them. SpikeYOLO cannot read that. It needs a fixed, dense, rectangular tensor it can batch on a GPU.So I built a preprocessing step (see below) that discretises space and time into a polarity histogram. Background pixels become neutral gray (127), brightening events become white (255), darkening events become black (0).The sparse, variable, asynchronous stream becomes a clean fixed-size grid the model expects. I vectorised the whole thing in NumPy, so half a million events are processed in a fraction of a second instead of crawling through a Python loop.This part isn't sexy. It's a lot of housekeeping, wrangling, and structuring. As you can see, I split data into different batches, each containing specific event camera sequences from the DSEC data library. Note: These screenshots are from my personal computer.Just so you have a sense of what these scenes look like to the naked eye: event camera was supplemented with RGB camera (below). Image frames taken across multiple lighting conditions, resulting in different sequence names e.g., interlaken, zurich etc.
Different lighting conditions.
DSEC Dataset
https://dsec.ifi.uzh.ch/dsec-detection/
60 sequences, 70379 frames, 390118 bounding boxes
Selected:
33 Training Sequences (Mixed Lighting Conditions)
8 Test Sequences (Control Variable: Lighting Condition)
Data
Compute
Image on the right shows the bounding boxes used during training, along with the annotations: 1 for cars, 0 for pedestrians. This is what the model uses for supervision.Step 3: Fine Tuning the Model
Training. Training, training, training.
Once the data was prepped, I began training.I did not train from scratch. I started from SpikeYOLO's BICLab's Gen1 pretrained checkpoint (23.1 million parameters) and fine-tuned it onto DSEC, because both are event-camera driving data and the learned features transfer well. All 755 weight tensors loaded cleanly, which confirmed the two architectures lined up.Fine-tuning runs on three tightly coupled algorithms I set up: a forward pass that generates predictions and measures error, a training loop that corrects the model using backpropagation-through-time across every temporal step, and a checkpoint selector that keeps only the weights that score best on unseen validation data and stops early when they stop improving. Fifty epochs on an RTX 3090, roughly thirty-four hours. Validation performance peaked at epoch 10, and that is the checkpoint every result in this study uses.
Step 4: Failure
Mathematically, the suspicion was that meddling with the firing threshold was equivalent to getting a stronger signal.
I tried something novel. It didn’t work. Worth a try.
Alongside the main model I built a second variant called LearnedThresholdLIF, giving every layer a learnable firing threshold so the network could tune its own sensitivity as event density changed with the light.Signal strength in the network diminishes as the scene is less illuminated.Here’s the big idea: scaling a neuron's input is mathematically equivalent to adjusting its threshold, so I made the scaling factor a learnable parameter.Unfortunately, it collapsed after fifteen epochs. The classification head found the trivial solution of predicting nothing, and the box-regression branch never fired at all. I’m still trying to figure it out. I documented it honestly as a negative result. One idea might be to apply the learnable threshold only to the backbone and leave the detection head alone.As you can see for Ablation One, the higher the T value, the better the performance… but it plateaus… diminishing returns, as they say.Step 5: Ablations
Aside from lighting conditions, what did I vary?
We run ablations to figure out the mechanisms that drive model performance improvements.● Ablation one: Temporal resolution (T=1 vs T=2 vs T=3): more timesteps means better detection, the gains are largest at pitch night, and they taper off after T=2. This proves the advantage comes from temporal integration, the network accumulating evidence over time, and not merely from packing more events into each bin.● Ablation two: Re-parameterisation (RepConv removed): stripping out the multi-branch training barely dents performance in bright light, but costs 7.7% of accuracy at pitch night. That is 4.5 times larger than the same change costs on dense everyday image data. The sparser the input, the more the model leans on that richer feature learning.Step 6: Finding the Best Checkpoint
Which snapshot of the weights yields the best results? Well, we test it with F1, Recall, Precision curves….across the epochs…and pick the best.
I saved a snapshot of the model weights each time it reached a new best (a checkpoint). I selected the best one among them and I evaluated that checkpoint separately across the four lighting conditions, applying identical scoring to each.
The model was never exposed to a dedicated dark-scene test set during selection. It was never tuned to favour low light.
What does this mean?
Later on, you get to say the strongest model performance in the dark is not just because we trained it in the dark. What you see is a generalized training/performance. Detection strength, then, is a property of the model itself.
PS: When someone downloads ‘model weights’ on GitHub or HuggingFace, this is what they’re downloading.
The best Checkpoint.
What the model sees in Pitch Night Scenes
mAP50 = 0.339
Sparse, clean event stream
Car reads as a moving void ringed by boundary events
Consistent, confident detection
Results · both classes
Detection rises as the scene darkens
Me: Well, that’s counterintuitive! You would think the greater the brightness of the scene, the better the model performance at detecting the object. But it’s actually stronger in the dark.
Results · per class
Car vs Pedestrian
+83% AP50. Monotonic across all conditions. Strong boundary event signatures.
0.007 → 0.224 (dim) → 0.097 (pitch). Small objects: event signatures too sparse in extreme darkness.
Me: But this only applies to cars. It doesn’t apply to pedestrians.
Mechanism
Why Does Darkness Help Car Detection?
Bright conditions
- Dense, noisy event streams
- Genuine object events mixed with background texture, flicker, and luminance variation
- High activation → unstable membrane potential trajectories → poor spike discrimination
Pitch night conditions, better separation
- Sparse, high-SNR event streams
- Only genuine contrast changes cross the DVS threshold
- Clean, consistent spikes → stable membrane potential accumulation → reliable threshold crossing
Let’s wrap it up. Here are the findings up in a nutshell…
Conclusion
Signal sparsity is well-suited for low-light detection, via SNN
- SNN-based neuromorphic detectors perform best precisely where conventional cameras fail most: in low light.
- Physical mechanism: sparse low-light event streams produce stable LIF membrane potential trajectories.
- Car detection is highly robust in darkness. Pedestrian detection requires further development.
- T=2 outperforms T=1, and T=3 outperforms T=2, but the gains diminish.
- Re-parameterisation is a strong component in this use case.
What the model sees in Bright Scenes
Bright mAP50 = 0.162
Dense, noisy event stream
Target lost in background clutter
Small, low-confidence detections
Step 7: Final Results
Run on Test sets. How well does an SNN do in low light?
Dataset
DSEC-Detection Overview
DAVIS346 event camera · 304×240 resolution · 2 classes: pedestrian and car
Numbers in the bounding box indicate the model’s confidence of predicting a car or a pedestrian.
There’s more to it…
I streamlined this whole page for a quick easy read. If you want, you can read the full technical paper behind my SNN project.
Return to my homepage to view my other AI/ML project: a Retrieval Augmented Graph Agent for Literary Analysis. That one is more left brained.
As promised, a video on Event Cameras, if you’re interested. It’s a very fascinating watch. Event Cameras have the potential to solve a very large number of problems in robotics. It promises ultra fast and robust computer vision.
In the realm of academia, I like doing ML & computer vision-related research.
In corporate, I enjoy building automated systems that involve business logic and processes.
My name is Yohann. Drop me a mail.
Fear not, first-world person, I speak the Queen's English and eat hamburgers. Ford Coppola is one of my favorite film directors.
I’ve worked in multiple fields, technical and non-technical, across different nationalities and styles. That’s human experience. Something you don’t get, even for $100/month on Claude Max:
Navigating difficult stakeholders
Taking a joke
Scaling up my intelligence for the same salary
Succeeding in domains I wasn’t trained by a GPU for
Handling problems that’ll attack you on Monday
Joining the meeting when the product is on fire
Also, if you're gonna call me, best drop me a message on WhatsApp first introducing yourself. Scam calls have been rampant since 2020.