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

YIQ colorspace and YIQ distance #55

Open
makew0rld opened this issue Mar 8, 2021 · 3 comments
Open

YIQ colorspace and YIQ distance #55

makew0rld opened this issue Mar 8, 2021 · 3 comments

Comments

@makew0rld
Copy link
Collaborator

makew0rld commented Mar 8, 2021

The YIQ colorspace can be useful for quickly measuring the perceived difference between two colors. This is what odiff uses to measure the difference between images. The README references this paper.

The YIQ conversion and special YIQ distance algorithm have already been implemented in Go here, but should be compared with the paper just in case.

@lukasschwab
Copy link

@makew0rld thanks for noting this! It might make my work in mccutchen/palettor#8 (replacing RGB euclidean distance with a better perceptual distance measure) faster.

That code does $k$-means clustering by repeatedly iterating over the pixels in the same image. Each time it visits a pixel, it measures the distance between that pixel and a number of "centroids" being optimized.

As I understand it, there are two frequent arithmetic operations:

  1. Translating RGB-internal colorful.Colors into HCL.
  2. Finding the squared euclidean HCL distance between colors.

Implementing a (colorful.Color).Yiq() function may speed up the first process, since converting the RGBA colorful.Color into $(Y, I, Q)$ is faster than the conversion into $(H, C, L)$.

The second operation remains essentially the same speed: whether in HCL or YIQ, I'm taking a euclidean distance in 3D space.

It seems to me the bigger performance improvement would come from actually storing HCL and YIQ values. colorful.Color may become an interface – a translation-rich superset of color.Color – that exports different struct implementations, like the color package itself does.

That might all seem out-of-scope for this package, but I figured I'd write it up in case that's of interest!

Also, for future readers: see dmtrKovalenko/odiff#81 for an updated link to the YIQ paper referenced here.

@lukasschwab
Copy link

It seems to me the bigger performance improvement would come from actually storing HCL and YIQ values.

Storing HCL representations made a significant impact. My benchmark results are here – compare 'Main branch' (using colorful.Color) to 'Feaure branch' (using colorful.Color to build internal hcl structs): lukasschwab/palettor#2

dmtrKovalenko pushed a commit to dmtrKovalenko/odiff that referenced this issue Mar 17, 2023
## Changes

Link in README.md appears to point to an old address for "Measuring perceived color difference using YIQ NTSC transmission color space in mobile applications" (Kotsarenko & Ramos 2010).

This change substitutes a link to the current journal site.

## Motivation

Here from lucasb-eyer/go-colorful#55.
@makew0rld
Copy link
Collaborator Author

Thanks for the updated paper link. I do think colorful.Color becoming an interface is out of scope and too big a change, but thanks for the suggestion.

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