-
Notifications
You must be signed in to change notification settings - Fork 61
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
CAM16 implementation #199
Comments
It's definitely interesting! Thanks for bringing it up. Porting the Python implementation seems fine to me, but it will of course have a few more bells and whistles to be in line with the rest of the library. Feel free to give it a try if you want to. A lot of these things are mechanical copies of implementations or specifications, so it wouldn't be the first. Don't hesitate to ask if you decide to try it and run into trouble. |
The link has moved to https://github.com/nschloe/colorio/blob/main/colorio/cs/_cam16.py. The "bells and whistles" can be at least initially reduced by always using the CAM16-UCS viewing conditions. Implementing CAM16 would also contribute to the CAM02 issue, since a lot of code is shared between them. |
Thanks for the heads up! And yeah, it would be nice if code can be shared there. |
I implemented a color crate, without knowing about "palette" and implemented different color spaces rgb, linear rgb, XYZ... and also color appearance model: Lab, Cam16 and Android HTC for a project of my business. I did it in one week so it has the quality of a crate written in one week. Palette is really superior. I would prefer to switch to palette but I need Cam16 and HTC. Are you still interested in the implementation of Cam16 in Palette? |
I have seen your code, there are cryptic macros "palette_internal". If you explain me I can try to implement Cam16 otherwise, here is an implementation:
|
Hi! I'm happy to see that you are finding Palette useful. I still think CAM16 could be a nice addition, so it would be amazing if you are up for adapting this implementation. Keep in mind, though, that I haven't gotten around to read up on all the details yet. It's not my main field, so it will be more of a contributor driven feature. I will do my best to look into it along the way, but you'll be the expert and I'll probably have questions. Another alternative is of course to keep CAM16 separate and depend on Palette, if you prefer that. The funny |
Ok, I'll try to implement it. How do we do? I have never worked with GitHub collaboratively. I have forked your repo. Should I push changes to the forked repo and inform you here about the changes here? |
No worries! You will be able to open a pull request here once you have pushed something to your fork. Don't hesitate to push and open a PR for a work in progress if you want feedback or help along the way. |
What about caching the rgb_to_xyz matrix and its inverse in the trait Primaries? This will dramatically increase conversion performance. It would be implemented as trait methods whose default implementation call functions of the module |
That would be a very nice way of doing it! I have wanted something like this for a while but not decided on how. I think this is a good starting point. |
308: Allow RGB/XYZ conversion matrices to be pre-defined r=Ogeon a=Ogeon As suggested by `@Kannen` in #199 (comment), make it possible to have RGB to XYZ and XYZ to RGB matrices pre-defined for an RGB space. This results in significantly faster conversions. Co-authored-by: Erik Hedvall <erikwhedvall@gmail.com>
It seems that the state-of-the-art currently in colour spaces is the CAM16 colour space. @nschloe wrote a paper concerning improvements to the colour space, which they then implemented in Python as part of a larger colour space library. I know very little about colour spaces or mathematics, so I don’t know how much I could do apart from mechanically porting the Python implementation to Rust. Is this something that would be helpful?
The text was updated successfully, but these errors were encountered: