|
Never heard of one of those. I'll look it up. Thanks!
To err is human. Fortune favors the monsters.
|
|
|
|
|
Do those work with non-emissive displays?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Very good point, thank you!
Some of these units can be used for printer profiling, so I would say yes. But that is more a guess.
Note: OP's question triggered me to search for e-ink 'profiling'. Until now I did not find usefull information. I think because profiling on such 'primitive' devices is not really easy/usefull.
modified 15-Apr-22 9:38am.
|
|
|
|
|
You get yourself involved in tasks that are VERY different from anything I've done professionally. It sounds very interesting (and also very frustrating at times).
|
|
|
|
|
That's a very accurate summation. The frustration is worth it for the victory at the end.
To err is human. Fortune favors the monsters.
|
|
|
|
|
My apologies if any of this comes across as pedantic.
You're venturing into color handling areas that can be quite involved mathematically. There are also a lot of trade-offs and subjective considerations. The most fundamental is the realization that color is perceptual, and an absolute color standard does not exist.
Let's use Code Project orange as an example. Chris uses a certain RGB value (224,137,0) in his HTML/CSS that looks orange to him. That's what's sent to user devices. If you were to sit a dozen of those devices side-by-side and measure the color spectrum for the displayed 'orange' using a spectrophotometer, you'd get different values for each device. You'd probably get different values even you tested a dozen of the same model of iPhone. If you printed the page on a color printer, you'd see the same thing. You would get different measurements depending upon the printing technology, the paper, lighting, etc. You eventually have a gamut[^], a set of colors realizable on a device based on its inputs.
There are any number of schemes for matching a 'reference' color definition to a device, based on a color matching mechanism like Pantone[^] between a reference and the device's gamut. As an implementor you eventually reach a point where you choose a methodology whose results are "good enough" based on your device's capabilities, the color measurement data you have available, and customer requirements.
Software Zen: delete this;
|
|
|
|
|
That's basically what I'm trying to get at - good enough. The issue is e-paper displays. The ink color for "red" isn't necessarily pure RGB red. I just want to get those matched a little closer. If I can get pantone codes for them that should do it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Quote: isn't necessarily pure RGB red There is no pure RGB red, one needs to define first the primaries of the space! RGB is an often missused therm. There are lot of RGB spaces (even CIE XYZ is one of them). Not 100% error free but a good reference with good background information: Welcome to Bruce Lindbloom's Web Site[^]
|
|
|
|
|
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.
|
|
|
|