Skip to content

Conversation

@Womifa
Copy link

@Womifa Womifa commented Sep 19, 2020

Color blending should be done after gamma correction so I used the "Device Gamma" value to gamma correct the screen color values before they are averaged the LEDs. As I have no idea how SSE4.1 and AVX2 work, the averaging function is pretty basic. The averaged color values are then reencoded with the device gamma to maintain compatibility. I also increased the resolution of all color calculations to 16 bit per channel to have more data to work with when performing dithering calculations. This might also be useful for LEDs that have more than 8 bit of resolution.

@psieg-jenkins
Copy link
Collaborator

Can one of the admins verify this patch?

1 similar comment
@psieg-jenkins
Copy link
Collaborator

Can one of the admins verify this patch?

@psieg
Copy link
Owner

psieg commented Sep 27, 2020

I'd prefer to do the two things in separate steps. Increasing internal resolution to 16 bits for the computations sounds fine.

As for the Gamma, I'm not convinced. The value is the "device gamma" value because it's applied to the colors sent to/displayed by the device. It's not gamma correction for the captured image, though the main use case is using it for that. I understand that order matters in theory but I doubt it matters in practice. Do you see a noticeable difference in the results with this?

Also we just introduced the averaging using AVX to reduce Prismatik CPU load. AFAIK AVX wouldn't work with simultaneously applying gamma, because it's not the same operation on all values. One would have to apply gamma to all pixels and then accumulate using AVX, which is slower and uses more CPU.

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

Successfully merging this pull request may close these issues.

3 participants