DEV Community

Ross Kim
Ross Kim

Posted on

It Doesn't Finish in Order

Stepping Back from the Blocks

We've come through four blocks: the seat that decides the amount of light, the seat that flattens light that doesn't land evenly, the seat that decides what color to call that light, and the seat that moves the color beyond white. Each time I applied the same frame. One side holds an algorithm as its asset and protects consistent behavior across many inputs. The other holds a specific module as its asset and protects the same result repeating from unit to unit.

This final installment steps back from the blocks. Taken one at a time, tuning looks like work that flows through a fixed order once and is done. It isn't. Put the blocks back together and a decision made in one shakes what was settled in another.

It Doesn't Only Flow Forward

The pipeline has an order. The amount of light is set, the frame is flattened, white is decided, the remaining color is moved. Data flows in that direction. But tuning does not flow only in that direction.

That the output of an earlier block becomes the input of a later one means that touching something earlier shakes what you had settled later. Retake AE's values so that the split between exposure and gain changes, and the seat estimating white and the seat moving color are no longer receiving the same signal. A change upstream almost always propagates downstream. So you look at the downstream again. And what you find there can prompt a change upstream in turn. Only after this back-and-forth has gone around a few times do the values find a place where they can stand together.

Nor is the direction of propagation always front to back. Lens shading and AWB have hold of each other.

Here's one direction. When the frame hasn't been flattened, the edges carry a color cast. AWB looks at the frame's color statistics to estimate the color of the light, and if the edge cast bleeds into those statistics, it lands on the wrong white. Shading has to be properly flattened for AWB to see statistics it can trust.

Here's the other. The edge color cast changes shape with the color of the light. So shading correction keeps a different surface per illuminant and selects one to apply, and which surface to select can only be decided by knowing what color the light currently is. But estimating the color of that light is precisely AWB's job.

So shading waits for AWB to be settled, and AWB waits for shading to be flattened. Neither can be finished before the other, so the two settle into place by referring to each other. CCM, using different coefficients per illuminant, sits on the same knot.

That the values set in each block don't live only inside that block is why tuning doesn't finish in a single pass through the order. Tuning in practice is not a straight line through the pipeline but something closer to an iteration, moving between blocks and walking values back a little at a time. The final values are not placed by a single decision; they are produced by that iteration. The four earlier installments took the blocks one at a time to see the decisions inside them clearly, not because those decisions are independent of one another.

What Is Allowed to Move

On top of this structure, where blocks push back on each other, the real difficulty of tuning isn't getting each value optimal. It's deciding which one to concede.

When a push-back happens, something has to give. What the four earlier installments each pointed at, block by block, was exactly that giving. Whether to fill the same brightness with time or with gain. Whether to place white at physical neutrality or leave the mood of the light in it. Which colors the unavoidable color error gets laid on. None of it is free. And push-back doesn't let you settle these concessions once and be done. Touch the upstream allocation because you're refitting color downstream, and the concession that allocation carried moves along with it.

So a good part of tuning is not raising and lowering values. It is deciding what is allowed to move and what is not, and holding that line.

That line belongs to neither seat. How bright the image should read, what gets called white, which colors get saved, and what impression the finished image should give: the client decides these. What the two seats do is not to make that decision on the client's behalf but to establish, on top of their own assets, what is possible and how far, hand that over, and then realize the line the client chose from their own seat.

What It Means to Change Seats

Facing the same pipeline and the same values, the two seats protect different things, as I've said. One protects breadth across many inputs; the other, repeatability on a single module. So what actually changes when you move from one seat to the other?

What changes is not the knowledge you hold. The order of the pipeline, what each block decides, all of that stays. What changes is what you grip as a handle and what you accept as a wall. The sensor characteristic that was an untouchable wall in one seat becomes, in the other, a handle you measure directly and use as the starting point for your values. Conversely, the algorithm whose shape you used to define at will becomes, in the other seat, a wall you must accept as given.

So the first thing someone who changes seats relearns is not technique but the arrangement of handles and walls. How far can I move things here, and where does the other side's asset begin? Get that wrong and you spend time gripping a wall, or you defer a handle you could have grasped as though it were someone else's to hold.

And this arrangement misaligns especially often when the two seats sit across from each other. When one says "that's a value for your side to fit" and the other says "that's a range the algorithm should absorb," usually both are right from where they sit. What each protects is different. The misalignment doesn't arise because someone is wrong; it arises because the assets are different. So resolving it is less a matter of adjudicating right and wrong than of recognizing what counts as a wall from the other seat.

Protecting Different Things

What this series set out to do was not to explain ISP blocks. It was to show that two seats, facing the same values, protect different things, and where that difference comes from. In the amount of light, in the evenness of the frame, in white, and in the color beyond it, the divergence arose in the same place every time. The assets held in each hand differ, and so what must be protected differs.

I have watched these decisions up close from both seats. That what looked like a wall from one seat was a handle from the other: that one thing is what I wanted to say across these six installments.

Top comments (0)