Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where to handle gamma correction? #7

Open
longears opened this issue Jun 11, 2013 · 2 comments
Open

Where to handle gamma correction? #7

longears opened this issue Jun 11, 2013 · 2 comments

Comments

@longears
Copy link
Collaborator

The LEDs we're using need a gamma correction of about 2.2 to match the simulator.

This should probably happen in the TCL driver since it's unique to our hardware. Because we're working with ints, the downside is a loss of color depth -- the brighter values will have 7 effective bits of color instead of 8. Might not be noticeable.

This could be avoided by doing the gamma correction in the client where we might have access to floating point colors, but then the client will need to act differently depending on whether it's talking to the simulator or the real LEDs.

@devries
Copy link

devries commented Aug 9, 2013

I put in a pull request on the TCL server side, which may be a good place to put this. There possible downside would be if the manufacturing changed in such a way that LEDs from the same chipset require a different gamma correction. It might be something to set on a per-server basis? Anyway, I left the gamma factor as something you can set in the code (though not in the client). Maybe we can make a command to adjust the gamma factor?

@longears
Copy link
Collaborator Author

longears commented Aug 9, 2013

Thanks Chris!

Seems like drivers should assume they're getting un-corrected data by default and they should do the appropriate correction for whatever they're driving.

I can think of two ways to have system messages about this:

  • Simple: A message which tells the driver to disable gamma correction and just use the raw values you send it
  • Comprehensive: A pair of messages, gamma-from and gamma-to: one tells the driver the gamma that's already baked into the values, defaulting to 2.2. The second tells the driver what gamma to convert to, and that defaults to a good value for whatever hardware the driver is connected to. The driver then applies a correction of, I think, gamma-to / gamma-from

Some background info on gamma. Correct me if I'm wrong:

Data tagged as gamma 1.0 means that the pixel value is in "linear space", corresponding to photon intensity. Note that 50% photon intensity looks darker than middle gray to our eyes.

Data tagged as gamma 2.2 means that the pixel values are perceptually uniform, meaning that a gradient from black to white looks balanced to our eyes and a middle gray value actually looks like middle gray.

When we deal with color or pixel values they're almost always in perceptual space, meaning the gamma 2.2 is already baked in. To convert to linear space, e.g. photon intensity, you can apply a gamma of 1/2.2 = 0.4545. Any image operations which are photon-related (e.g. raytracing, simulating camera blur) should happen while the data is in linear space. Image operations which are human-related (e.g. displaying numerical color values, drawing pretty gradients) should happen in perceptual space.

Your computer screen accepts data in perceptual space (gamma of 2.2) and does an internal gamma correction which converts the data to linear space so it knows how many photons it should emit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants