AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
October 2006

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2006.10.06 22:03 "Inverting color space values in a TIFF file", by Richard Nolde
2006.10.06 22:05 "Re: Inverting color space values in a TIFF file", by Toby Thain
2006.10.06 22:50 "Re: Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.06 23:37 "Re: Inverting color space values in a TIFF file", by Richard Nolde
2006.10.07 00:44 "Re: Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.07 01:35 "Re: Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.07 02:02 "Re: Inverting color space values in a TIFF file", by Graeme Gill
2006.10.08 21:39 "Re: Inverting color space values in a TIFF file", by Edward Lam

2006.10.07 01:35 "Re: Inverting color space values in a TIFF file", by Joris Van Damme

Richard,

Joris wrote:
> There's two important points to make.

Thinking further on my summary, I see I best ad a 2b) and a 3), for
completeness sake, but I'll keep it short as likely I'm about to rightly
be accused of spinning off-topic.

> 2) The only other thing that matters is how to calculate... For this,
> I think I best refer to Bruce Lindbloom's site
> (http://www.brucelindbloom.com/). There's many places on the web where
> you can find similar formulaes, but some aren't totally correct. I
> must add though, each time I re-implement these formulae, I find
> myself struggling for a little time, and that certainly isn't only
> related to optimisation. It may be that I'm not very bright, or
> otherwise it's not completely trivial.

2b) Lots of mistakes are made by not taking gamut clipping into account,
or at least not properly. If you do operations like the 'Negative' the
way I defined it in the first mail, and you next convert from Lab back
to sRGB, you'll note you get many values that are totally out of range.
If you just clip these in sRGB, or your conversion algorithms are such
that brute clipping is done at an earlier stage, you get not so pleasing
results. (Personally, I think a lot of people that contest the value of
Lab are in fact making this mistake.) You thus need to take gamut
clipping into account while in Lab, or even stage earlier avoid going
out of gamut through your definition of 'negative'. That is not easy,
but it's feasible.

3) One last important thing to note about Lab, is that it separates the
brightness (L) from the chromaticity (a* and b*), which comes in handy
in many algorithms, like the proposed 'Brightness inversion'.


I should like to think that answers your question as to the basics of
Lab. But really the point I tried to make in earlier mail is that
'inversion' is not trivial to define, and if defined in the intuitive
way (numerical inversion of RGB values), is utterly useless. Beyond
that, anything I say should be taken to be the comment of a color
amateur, not a color engineer who would likely disagree with my
ramblings.

I'll shut up now. ;-)


Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html