How a camera sensor captures colour

Create a visual explanation of how a camera sensor captures colour: an animated lesson that makes the idea click for someone who has never met it.

What makes it great:
- It shows the mechanism, not just words: concrete pieces (values, nodes, packets, bars…) that move, change colour and rearrange, so the viewer sees each step happen.
- It is accurate: the steps, numbers and terms are correct, and the animation follows the real process (run the real algorithm on the data shown wherever possible).
- It builds up in order: the problem in one short scene, then the steps one at a time, then the key insight in one short summary. Four to ten steps, about 30 to 90 seconds for the whole story.
- Each step has a caption of one or two short sentences in plain language, and the element that matters right now is highlighted so the eye knows where to look.

How it is used:
- It starts playing by itself as soon as the page opens, and loops back to the start after the summary. The first frame already shows the subject (no blank intro or long title card), and the first real step happens within 3 seconds.
- Controls: play/pause, previous step, next step and restart, as real buttons with clear labels (icon buttons get an aria-label). Space plays and pauses; the left and right arrow keys step. A progress indicator shows which step you are on.
- Optional: one control that changes the example, such as new random data or the speed.
- The visual is the main focus. Captions and controls sit in a compact bar that fits a portrait phone and a landscape desktop. Text is at least 14 CSS pixels.

Make it astonishing. Both builds are shown side by side in a 30-second video on social media, where people decide in one second whether to stop scrolling:
- The very first frame is already striking: bold colour, light and motion, never an empty, plain or loading screen.
- Build to a signature moment within the first 10 seconds that makes people say "wow": a reveal, a transformation, an explosion of particles, a chain reaction.
- Go beyond the obvious version of the idea: choose a surprising, inventive take with its own world, mood and personality, not a generic template.
- Layer it: depth, glow and light, particles and trails, smooth easing, and detail that rewards both a glance and a closer look.
- It is watched at about half size on a phone: keep the important shapes big and high in contrast, and any key text large (at least 28 CSS pixels).
- Make the mechanism cinematic: big, bold animated objects, camera moves (zoom in on the key moment, pull back to show the whole), colour that carries meaning and only a few large words on screen at once; the picture tells the story, the captions only label it.

Fixed rules (so every model is compared on the same terms):
- Exactly one file, index.html, in the current directory. Create no other files.
- Plain HTML, CSS and JavaScript. You may use three.js 0.170.0 from https://cdn.jsdelivr.net/npm/three@0.170.0/ (via an import map) if it helps. No other libraries, images, 3D models, fonts or network requests: build everything yourself in code (canvas, SVG, CSS or WebGL).
- It fills the browser window and works on a phone and on a desktop, with no page scrollbars.
- Animate with requestAnimationFrame and its timestamp so speed does not depend on the frame rate.

It must work in an ordinary browser on any graphics card. You cannot open a browser to look at it, so build it carefully:
- Every frame is fully drawn: no black, blank or flickering frames or patches. Keep any shader maths free of NaN and infinity (no division by a value that can reach zero, no pow() of a negative number, no normalize() of a zero-length vector), and clamp colours to a safe range before bloom or other post-processing.
- No errors in the browser console: if you use three.js, map "three" and "three/addons/" in the import map, and import everything you use.
- It runs smoothly on an ordinary laptop or phone: keep the pixel ratio at 2 or below, and avoid creating new objects every frame.
- It adapts when the window is resized or the phone is rotated.
- Do not hide errors: never wrap the main loop or whole functions in a try/catch that silently swallows them; fix the cause instead (a try/catch around storage or audio is fine).
- Stepping forward or back, pausing and restarting at any moment always leave the picture and the caption in sync, and never break the animation.

Before you finish, read your file once from top to bottom and make sure that:
- It starts playing on its own and is still playing a minute later.
- Pause, previous, next and restart all work, by button and by keyboard.
- Every caption is correct, and matches what is drawn at that step.
- It fits a 390×844 phone window and a 1280×720 desktop window.
- Nothing can throw an error in the browser console.

The battle video records about 30 seconds right after the page opens, with no input.

Everything else is your choice: the example, the visual metaphor, the style and colour. Make it as clear and as visually stunning as you can, so someone new to the idea understands it and wants to share it. Do not ask questions; make reasonable choices.