|
CIE XYZ is a separate color model than RGB in my code. RGB indicates a 3 coordinate space, mapping R, G, and B to a color space. When I say pure RGB red, i do not mean visually pure. I mean a pixel with red coordinate set to max, and the others set to min. I hope that clarifies what I mean.
To err is human. Fortune favors the monsters.
|
|
|
|
|
CIE XYZ is one of the rgb spaces. I'm very shure about it, it is my daily work
|
|
|
|
|
That might be the case. I'm simply talking about my code. In my code, what's primary is the *binary footprint*
In my RGB color model it goes like this in terms of bits - say for 16 bit:
RRRRRGGGGGGBBBBB
Like that.
CIE XYZ would have a different binary layout, ergo it's a different color model in my code.
Now, it is possible to represent that in my code, but it would require conversion from the RGB model to the CIE XYZ model.
My code frankly, does not care about your daily work. My code cares about interfacing with devices that expect pixels in a particular format.
And in terms of usability, the user is not going to care that CIE XYZ is part of the RGB umbrella of color spaces, since there is no concept of an umbrella or family of color spaces in my code. My code identifies a color model by, and only by the names of the individual channels that make up a pixel.
When a user declares a cie_xyz_pixel<24> the only thing that effectively matters where the rubber meets the road is can it be converted to RRRRRGGGGGGBBBBB? That's it.
To err is human. Fortune favors the monsters.
modified 15-Apr-22 12:32pm.
|
|
|
|
|
You mention a lot of times RGB. Which spaces please? There is no one only RGB space...
Here some of them:
Adobe RGB (1998)
AppleRGB
Best RGB
Beta RGB
CIE RGB
ColorMatch RGB
Don RGB 4
ECI RGB
Ekta Space PS5
NTSC RGB
PAL/SECAM RGB
ProPhoto RGB
SMPTE-C RGB
sRGB
Wide Gamut RGB
All these spaces are well defined by the light source and the respective primaries
|
|
|
|
|
Look, I get, but we're talking apples and oranges.
I AM TALKING ABOUT THE BINARY FOOTPRINT OF THE COORDINATE SPACE BEING USED.
I don't know how I can be more clear.
Maybe this will help. Color model != Color space.
I deal in color models. Just replace space with model wherever I used it and maybe that will end this. But it's not productive.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Ok. But the binary footprint leeds to wrong solutions. Enough for now
|
|
|
|
|
No it doesn't.
It leads to exactly the expected solution when the target is an LCD monitor whose controller chip deals in that very same pixel format.
So "wrong solutions" is not correct. It depends on what you're doing. I support other color models like CMYK, and HSL so you can map those, but they get mapped in the end, to an LCD controller chip, or to an e-paper controller chip.
At the end of the day, that's what my code cares about.
This is not photoshop. This is not a print shop. This is not full fledged graphic design package coded to run on a machine with 80kB of RAM.
It's about perspective.
Now I'm done for real.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I can't resist to answer again... E.g. sRgb to CMYK is nothing defined. Don't believe too much to the trash you find on www, these scenarios do not end in any successful results for praxis.
Now I try to definitively be silent
|
|
|
|
|
let's continue this most excellent thread until the internet blows up.
|
|
|
|
|
I just open a cmd and entered 'format www', let's see
|
|
|
|
|
Reading that again: To be honest, I think you have no idea about color spaces. Sorry.
|
|
|
|
|
I don't. I deal in color *models*.
If I had your job, I'd know about color spaces. I don't need to.
I simply need to know enough to
A) Match colors
B) convert between the different models.
I have that.
For me endeavoring to understand color spaces would be purely an academic exercise, as I have no use case for it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Very sorry. I didn't mean to be rude. My only thought was that knowing how to profile it might lead to a solution.
Sorry again.
|
|
|
|
|
I didn't think you were rude. I can appreciate a discussion that gets heated, especially about technical stuff - when I was coding with friends or even just professional peers, it used to happen all the time. It made me a better coder. Whether or not this will is not what matters though. I don't want us to part ways upset.
For my part, I'm sorry if I was rude, or otherwise rubbed you the wrong way. You're alright in my book.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Thank you very much, relieved. For me you are a very great architect/programmer and I enjoy reading your articles. Even I don't understand them (especially the parser stuff when it goes deep).
|
|
|
|
|
It's possible that for the e-ink display in question a 'pure' RGB red isn't realizable. One approach that might be 'good enough' would be to get color samples from your paint store, scan them, and then convert the scanned result to the color-space used by the display. This plus some manual tweaking might be a more systematic approach than the Mark I CodeWitch eyeball .
Software Zen: delete this;
|
|
|
|
|
That's actually what I'm planning on doing, per my edit of the OP. Someone suggested a paint store to me to get a pantone, but I suppose I could scan as you say - however, in my experience different scanners produce things with a different overall tint to it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Quote: however, in my experience different scanners produce things with a different overall tint to it.
*lol*, exactly what I tried to mention in other thread leave.
As long the units are not profiled you can't expect 'true' color results. And even they are profiled, you still need to fight with huge differences!
Let us assume a color given in CIE Lab*/D65/10° is the goal. To reproduce that on a specific device you will sooner or later hit the borders of the device...
|
|
|
|
|
I get that. I understand that.
I never didn't understand that. That's why I wrote what I did about scanners.
I'll match to the e-paper to get a pantone I can turn into a good enough color and that's good enough
I don't care about profiling every goddamned LCD display panel that is manufactured for IoT today.
And I don't need to. Now if there's something about that you don't understand, well I can't help you.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Can you even get close to RGB “red” with an E-ink display?
If your library prefers RGB, then it seems that you would have a per device mapping that gets “close enough” or even “as good as it gets” when trying to map 24+ bit color to 5 bit(?) color in a different model.
Does source material like ebooks code in RGB?
|
|
|
|
|
You can get close enough to my eye. I've loaded some color JPGs onto a 7 color e-ink with color matching and dithering and it comes out reasonable.
I can do better with the color matching though. I'm noticing primarily that my lightness or saturation is off some, I think between the RGB and the actual e-ink.
Basically what I need to do is correct my palettes for each color e-ink display I have, so the colors they report are closer to the physical mark.
It won't be perfect as light based color is always going to look different than pigment based color, but I'm not looking for perfection, just improvement.
e-books technically, if they have JPGs (which is the only image format my code supports) do not use RGB. Rather they use 24-bit Y'CbCr.
To err is human. Fortune favors the monsters.
|
|
|
|
|
If I remember correctly you are working in (ink jet?) printing industries.
You mentioned:
Quote: You're venturing into color handling areas that can be quite involved mathematically.
Is it not more praxis, that one does profile in printing with a lot of lookup tables?
Thanks in advance.
|
|
|
|
|
0x01AA wrote: working in (ink jet?) printing industries That's true; you have a great memory!
Most of the color handling we do is handled during data preparation, in advance of the printing process, using ICC profiles. That will match the data to the paper or print medium. Real-time adjustment according to the properties of the ink and the particular characteristics of the inkjet hardware happens based on a couple of calibration processes we have.
Software Zen: delete this;
|
|
|
|
|
Thanks for your answer.
I'm working in colorimetric field (textile dyeing, paint coatings, food, ...)
I think I'm very familar with all these stuff, but I never spend a thought on e-ink. Do you have an idea how e-ink can be profiled?
|
|
|
|
|
0x01AA wrote: Do you have an idea how e-ink can be profiled? I don't know. Our measurements are reflective. LCD and LED displays are generally emissive, which I assume requires a different measurement technology. E-ink is different still, so...
Software Zen: delete this;
|
|
|
|