75133 - Need nsScreenMac::GetGammaValue() implemented

Status: NEW

(Core :: XUL, defect)

Description

[tor]

Once the patch in bug 53597 is checked in, mozilla will query the platform
for the gamma value to correct images and colors appropriately.  Since I
don't know the MacOS APIs the current standin just returns a constant.

Comment 1

[saari (gone)]

returning a constant is just fine for now. Eventually we'll integrate ColorSync
support, and we can query that.

Comment 2

[Henri Sivonen (:hsivonen)]

The gamma correction is not really correction for those of us whose displays
don't happen to use 1.8 gamma.

Could the gamma value, please, be made at least a pref if no-one has time to
figure out how to get the value from the system in the 1.0 timeframe? That way
users could at least set the value manually without recompiling.

(I think making it a pref would be a good thing to do on all platforms that now
use a hard-coded value.)

Comment 3

[Nick Uniatowski]

Attachment: screenshot of mozilla gamma correction vs. Internet Explorer on Mac OS9

Build: 2002041508: The default gamma setting is far to dark. I think the
default Mac OS9 gamma is 2.1.

Comment 4

[Nick Uniatowski]

I must apologize, I had my color sync set to pc gamma(2.1). Proper Mac Gamma is
1.8. So having gamma as a preference would be useful. Even with color sync set
to 1.8 the display is still darker than IE.

Comment 5

[Andrew Thompson]

Perhaps perusing Apple's sample gamma code will help someone:

http://developer.apple.com/samplecode/Sample_Code/Graphics_2D/MacGamma.htm

I don't have time tonight!

Comment 6

[Henri Sivonen (:hsivonen)]

Nominating mozilla1.0 because bug 53597 went in and causes bad results on some
setups if this one isn't fixed also.

Comment 7

[Glenn Randers-Pehrson]

I agree that a user preference for setting gamma would be a good thing.  If
the user expresses a preference it should override all other means of finding
or guessing gamma.    Glenn

Comment 8

[m_mozilla]

I'm wondering if this bug is related to the following difference between
renderings of http://mgc.wustl.edu/

On the mac, the grey background of the image, and of the table are the same (or
at least I don't see a visible difference). On the PC, the mouse's background is
visibly darker.

testing with
    Mac OS X build 2002041505 (1.0 branch)
    Windows  build 2002041603 (from trunk)

The renderings are different. At best, one of them is correct. At worst, neither
is correct. Is the situation related to this bug, or should it be a new bug?

-matt

Comment 9

[tor]

The background of the uncorrected mouse image is #626262, while the html
specifies table cell backgrounds of #666666.  They're never going to match.

Comment 10

[m_mozilla]

So, mozilla on Mac OS X is incorrectly rendering them as the same color. Is that
this bug, or should that be a different bug?

-matt

Comment 11

[Andrew Thompson]

For the record, I'd be against having a preference. If the user wishes to change 
the setting, they already have a means - the Control Panel or System Prefs (on OS 
X).

I'd doubt anyone would want a different setting for Mozilla as opposed to any 
other application. We already duplicate far to many OS features.

Comment 12

[m_mozilla]

as I understand it, the pref is not a duplication in the sense that you might be
thinking.

This bug is "we can't programatically find out from the OS what the actual gamma
value is"

The pref they're talking about is "let the user manually tell mozilla what their
OS'es gamma value is"

So, it's just a workaround which lets users provide the info that mozilla can't
yet obtain for itself. Once mozilla can get the actual value from the OS, the
pref would go away.

Comment 13

[Andrew Thompson]

I looked into this some more, and it seems as if the correct thing to do is to 
look up the ColorSync profile for the current display:

(eg - for the main display, but we have a GDHandle for each display, so we can 
get it for any display we need) 
http://developer.apple.com/techpubs/macosx/Carbon/graphics/ColorSyncManager/
ManagingColorSync/Concepts/ColorSync.3f.html#16712

This gets you a reference to an International Colour Consortium (ICC) profile for 
the display. Said profiles are documented at http://www.color.org.

From my reading of the PDF there, the profile should contain 4 curves, greyscale 
and red, green, and blue, specifying either (i) a simple gamma value or (ii) some 
kind of table of values for each colour (ie, a curve).

If someone who knows more about colour than me could indicate how I might want to 
use said tables (eg, should I just grab the grey value if there's only one?) I 
might be able to implement this...

One assumes the same code would work on Windows, because it also uses ICC 
profiles, but I see that the Windows implementation just hardcodes 2.2 at 
present.

Comment 14

[Henri Sivonen (:hsivonen)]

lordpixel, my point with suggesting making it a pref was that given the choice
between hard-coding and a pref, the pref is better. If someone has time to get
the real value from the system in the 1.0 timeframe, that's even better.

Do all profiles guarantee that you can get a gamma "by formula" as opposed to
getting a lookup table?

Comment 15

[Glenn Randers-Pehrson]

ICC profiles can be lookup tables with no formula.

Comment 16

[Joel Chan]

*** Bug 137975 has been marked as a duplicate of this bug. ***

Comment 17

[Greg Roelofs]

With regard to comments 3 and 4:  how does Mac Moz compare with Mac MSIE on PNG
images?  (There are none on /.)  AFAIK, those are the only web-page components
for which MSIE does gamma correction, so they're the only things that are
guaranteed to match (in the ideal case where both browsers are bugless).  Note
that MSIE also does color correction, however, so there may still be small
differences.

Btw, "proper Mac gamma" is around 1.5, not 1.8.  The 1.8 "gamma" value Mac OS
refers to has some fudge factors in it; you need to multiply by 2.2/2.61 to
account for its weird lookup table (or so claim some folks who should know, and
that's what's quoted in the PNG spec).

Greg

Comment 18

[Eric A. Meyer (dead account)]

Greg: I'm about to attach two TIFF images (using IBM byte order and LZW
compression) that compare the PNG in attachment 79583 [details] in IE5.3.1/MacOS9.1 and
2002041903/MacOS9.1.  The colors are close but visibly different.  The shots
were taken using monitor settings of "thousands of colors" and "millions of
colors," just to show that while there are some shifts between the two modes,
the two browsers do NOT match up in either mode.

Comment 19

[Eric A. Meyer (dead account)]

Attachment: Comparison of IE5.1.3 and 2002041903 at thousands of colors

These were shot under MacOS9.1.

Comment 20

[Eric A. Meyer (dead account)]

Attachment: Comparison of IE5.1.3 and 2002041903 at millions of colors

Comment 21

[Greg Roelofs]

Eric's screen shots verify that there is a difference in gamma handling between
Mac MSIE and Mac Moz, both of which are trying to do some gamma correction.  And
subjectively, as viewed on a PC monitor (where all Mac images tend to look very
dark), the Moz image looks worse--simply because it's the darker of the two.

However, I can't claim for certain that Mac MSIE's gamma-handling is
correct--for example, they may be using the 1.8 value in equations where one
should be using 1.5; or the reverse may be true in Mozilla if it's handing
things off to the ColorSync subsystem (which presumably expects Apple's weird
fudge factor to be included).  In addition, the only mid-range color values in
the screen shots are actual colors, which by definition are also affected by
color correction.  A grayscale version of the image would be better for this
particular test (not that I truly expect the differences to disappear then).

Unfortunately, barring some personal testing on a Macintosh by someone with more
than one gamma-related clue (such as Chris Lilley, for example), the only way I
can see to pinpoint where the actual bug(s) lie is to write some simple, custom
test apps that display various PNGs both with and without gamma correction (but
always without color correction), and compare those results side by side with
both Moz and MSIE's rendering of the same images.  The PNGs should be some
simple grayscale test images with a couple different gAMA chunks, plus one
without any gamma info (=> treated as gamma 1/2.2 == 0.454545).  My rpng/rpng2
demo programs would be ideal for this except that I've never had access to a Mac
and don't have a Mac OS front end for them.  (There are Win32 and X front ends
only.)  Do plain X apps compile and run under OS X?  Or can someone provide a
basic skeleton program for Mac OS that takes RGB pixels and simply displays them
(no menus or scrollbars or anything, just some way to pass in the filename of a
PNG image and to detect a mouse click and/or Q or Esc keys for quitting)?  I
could then try to hack up an rpng-mac.c front end for testing as I've described
above.  (I don't really have time for this right now, but it seems like a fairly
high-priority issue, so I'll try.)

Greg

Comment 22

[Andrew Thompson]

One certainly can run an X11 server on Mac OS X (though none ships out the the 
box). 

This is XFree86 - would using it infact just introduce another variable into the 
system or does it ignore colour management and gama when running in rootless 
mode? (i'd guess the answer is no...)

Comment 23

[Greg Roelofs]

XF86 would just add another variable to the equation, since that's clearly not
how Mozilla and IE are built.  I thought OS X might have an X compatibility
layer, but I guess not.

Greg

Comment 24

[Andrew Thompson]

Well, I have a mac but I lack the necessary clues about gamma.

That said, I think I understand the Colour Sync API well enough from reading it 
that I could implement something to get the correct gamma value for the OS - if I 
knew what it was I was getting.

To put it another way, I know how to get the ICC profile for the current display. 
What I don't know is whether its possible to use the information within said 
profile to get to the sort of number Mozilla wants (1.5 or whatever it happens to 
be).

If someone is reading who gets ICC profiles and can explain in English or psuedo 
code, we should be in business - BTW given Windows also uses ICC profiles, the 
same algorithm would work there (its just as hardcoded as Mac OS at present), 
though obv. the details would differ.

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I've been thinking about this a bit, and also reading
http://www.inforamp.net/~poynton/PDFs/Rehabilitation_of_gamma.pdf .  This leads
me to a question:  The Mac has a UI for configuring gamma.  What is the
rationale for that UI?  Is it:
 (1) to allow users to adjust for the ambient light in the room or perhaps some
strange characteristics of the display so that a certain reference image can be
displayed the same way on any properly configured Macintosh (which hopefully
means that the configuration value of "1.8" is correct for a "typical" display,
or otherwise we'd have to decide whether we care about "typical" users who never
tweak their settings or those who correctly tweak their settings), or
 (2) to allow users to change the lookup table to match some other device (e.g.,
some sort of printing device) so they can do color matching for DTP or similar
purposes?

I think the answer to this question is relevant, because it effects what we
should do in response to different gamma preferences.  The gamma preference
(based on my understanding of the above document) changes the lookup table used
to convert colors in the framebuffer (which is essentially where we're sending
the image data, right?) to voltages to send to the monitor.  In other words, the
system is already correcting images based on the preference.  That suggests to
me that if the rationale for the preference is (1) above, then we should not
change our correction at all in response to the preference, but if it is (2)
above then we should be changing our correction in order to cancel out the
changes to the system's lookup table under the assumption that the overall gamma
we want to apply to the image (from sRGB image data to electron gun voltages) is
2.2.

Also, do ICC profiles differ from this simple gamma preference?  Or am I missing
the point?

I'm going to try to go down to the computer lab tonight or tomorrow and
investigate some of these questions on one of the Macs there.

Comment 26

[R.K.Aa.]

*** Bug 139060 has been marked as a duplicate of this bug. ***

Comment 27

[Greg Roelofs]

David:  I think the answer is closer to (2).  Specifically, I'd guess the
setting is there to allow users to choose between a classical Mac-like setting
and a majority-rules PC-like setting.  Properly written apps that use ColorSync
to do gamma and color correction will look virtually identical either way; the
difference will come when running legacy Mac apps on the latter setting or
viewing sRGB-originated (PC) content with a non-correcting browser on the former
setting.  I suspect most people who choose the PC-like setting are actually
web-design folks who need to match the viewing experience on the overwhelmingly
dominant platform, but that's just a guess.  Anyway, you do need to modify your
pixel data to account for the lookup table in the Mac, which is not present in
most PC display systems.

As for ICC profiles, those contain both gamma and color information.  Gamma is
pretty simple since black is black and white is white; all you have to worry
about is the mid-range values.  But color correction involves gamut-matching,
white points, black points, etc.  Basically, there are some colors that simply
cannot be reproduced on any given device, so you have to do some tricky
transformations to adjust colors appropriately.  And "appropriately" depends on
the creator's intention, which is where "rendering intent" comes in.  A company
may want its corporate logo to have exactly the same colors everywhere
("absolute colorimetric"), so out-of-gamut colors are simply clipped.  But most
people want something a little more visually balanced ("perceptual"), so most or
all colors may be slightly adjusted--possibly more so near the edges of the
range.  You can see why I never bothered to try to add color correction to Moz
and why color management systems (e.g., ColorSync) are Nice Things to Have.

Greg

Comment 28

[Eric A. Meyer (dead account)]

Attachment: Different comparison of IE5.1.3 and 2002041903 at millions of colors

Here's a comparison screenshot that involves plain HTML/CSS and no images of
any kind.  Again, the two browsers show different shades of colors, which is a
real problem since previous Macintosh builds of Mozilla were consistent with
IE5/Mac.  You can find the original file used to generate this comparison at
http://developer.netscape.com/evangelism/sidebar/css2qr/prop-visual.html .  I'd
like to point out that this comparison, and the comparison screenshots I
uploaded before, were all taken under MacOS 9.1 native, not Mac OS X or a
classic-mode window in OS X.  I haven't installed OS X yet, so that's not part
of the equation in my screenshots.

Comment 29

[Greg Roelofs]

Eric (comment 28):  this is expected.  Nobody said MSIE's handling of HTML and
CSS colors was correct, and in fact, I'm pretty certain that it's not--indeed, I
believe Mozilla is the *only* browser in existence that is doing (or attempting
to do) the Right Thing with respect to gamma correction.

If you want a browser that's bug-for-bug consistent with MSIE, that's certainly
your prerogative.  But if you want one that conforms to standards (see the refs
at the top of bug 53597), then expect to see differences in this and a host of
other areas.  MSIE is not a reference implementation of W3C standards and isn't
even particularly close, at least last time I checked.  (It wouldn't surprise me
if the Mac version is noticeably closer than the Windows version, though.)

Again, some basic Mac OS display-the-RGB-bitmap source code (in C) would help
immensely to figure out just what kind of problems we're seeing here.  Doesn't
anyone have some, or know somebody who does, or know of a site that does? 
(Sorry, I'm not going to wade through 100+ MB of Mozilla source to try to figure
out the 2 KB minimal test case...)

Greg

Comment 30

[bruno lapeyre]

Attachment: 2002041903 - wrong gamma under Mac OS X

I will now post 6 screenshots to try to give a good idea of the gamma
correction needed under Mac OS X. Mozilla 1.0rc1 didn't have the gamma problems
found with 2002041903 build. So I will begin to show the difference between
these two versions.
I used GraphicConverter to calculate the difference between the gamma values of
the 4 first screenshots.
GraphicConverter is displaying the same basic gamma value of 2,22 to each open
screenshot begin.
Following my tests, I need to correct The badGamma.png to a gamma of 1,85 
to have the equivalent of gamma_rc1.png. 
The same gamma value change need to be done to GUI_BadGamma.png (or the
bookmarks will be looking almost black on my screen). Then that screenshot will
look like GUI_rc1_OK.png.
The 5th screenshot is showing how I.E is rendering the first visited page.
The last one is showing the page inside Chimera 022 (even if Chimera developers
said that a gamma correction was done inside 023, I don't see any change
comparing with 022) is giving the same bad result than the 2002041903 build.
I hope this could help.

Comment 31

[bruno lapeyre]

Attachment: 1.0rc1 - good gamma

Comment 32

[bruno lapeyre]

Attachment: 2002041903 - wrong gamma again - GUI appearance

Comment 33

[bruno lapeyre]

Attachment: 1.0rc1 - good gamma - GUI appearance

Comment 34

[bruno lapeyre]

Attachment: Internet Explorer 5.1.4 - good gamma

Comment 35

[bruno lapeyre]

Attachment: Chimera 0.2.2 (and 0.2.3) - wrong gamma

An iMac DV 400 - thousands of colors - was used to take the 6 screenshots

Comment 36

[Andrew Thompson]

Bruno - have you hand calibrated your display? ie, are you using the default 
gamma setting or a custom setting?

Comment 37

[Andrew Thompson]

I think I agree with the assessment - the idea is more like (2).
If you look at the coloursync api you'll see most of it is concerned with colour 
matching and transformation.

In short, one can say "here's the profile of a hardware device and here's a 
colour - get me as close as possible. There's more too it than that, because 
there is the concept of an end to end workflow (scanner->screen->ink jet->
professional proofs) and suchlike, but that's beyond me.

Ultimately we should probably be using these colour matching functions, but I 
don't think that's within the scope of this bug.

An important comment to read on the "parent" bug is:
http://bugzilla.mozilla.org/show_bug.cgi?id=53597#c175

Here's the main thing it seems we want to fix: the user has adjusted his/her 
gamma on the display using Coloursync to match a PC, and it seems because we're 
hard coding the assumption of mac gamma we're effectively correcting twice. To my 
mind, fixing this is the goal of this bug. However - there may be more to it than 
that.

Psuedo code coming up...

Comment 38

[Andrew Thompson]

Here's an extremely rough patch with a bunch of guesses :

NS_IMETHODIMP
nsScreenMac :: GetGammaValue(double *aGammaValue)
{

    CMProfileRef  profile;
    CMError       theErr;
    AVIDType      theAVID;
    unsigned long size;
    void          *data;
   
    // Get the AVID for that device.
    theErr = DMGetDisplayIDByGDevice(mScreen, &theAVID, true);
    if (theErr != noErr) goto cleanup;
    
    // Get the profile for that AVID.
    theErr = GetProfileByAVID(theAVID, &profile);
    if (theErr != noErr) goto cleanup;
    
    theErr = CMGetProfileElement(profile, cmGrayTRCTag /* guess!*/ , &size, 
data);
    if (theErr != noErr) goto cleanup;
    
    //in reality, have to do more conversion to get the right number
    *aGammaValue = data[0];  //and what if its a curve rather than a single 
figure?
      
  
// Do any necessary cleanup. In this case, just return.
cleanup:
    *aGammaValue = 2.2*(1.8/2.61);
    return theErr == noErr ? NS_OK : ... etc ;

} // GetGammaValue

Comment 39

[Eric A. Meyer (dead account)]

Greg (comment 29): if I wanted a feature-for-feature or bug-for-bug match with
IE, then odds are I'd, you know, run IE.  I do that a lot, actually, because
it's a very good browser and I figure the choice of browsing environment is in
fact my prerogative.  I don't know if that automatically stains me around here,
but it shouldn't.

However, I do know that if Mozilla starts making images and all colors
noticeably different than the other browsers on Macintosh (such as Opera and IE)
then Web authors will simply write Mozilla off as a hopeless case.  No amount of
"but we're cool because we do gamma correction" will change their minds.  This
would be the case even if we make said correction a preference and set it to be
enabled by default-- our only hope would be to make it a preference and leave it
disabled by default.  Web authors value standards compliance a lot lower than
they do consistency, especially when it comes to something as fundamental as
color representation.

As someone who is primarily a Macintosh user, when I run 2002041903, every image
looks far too dark to me, and frankly it's very annoying.  The doppler radar
images from weather.com, for example, become murky and details get drowned out
by the darkness.  Every Web site I visit is obviously darker and often
color-shifted-- I can see it on CNN.com, Bugzilla, my personal site, you name
it.  The experience is, not to put too fine a point on it, mentally jarring. 
NObody will care that we're attempting to do the "right" thing.  If the colors
shift from previous builds of Mozilla and don't match other browsers in the same
OS, we'll be preceived as broken or stupid.  Or, more likely, both.  That was
the point I was trying to make with my comparison images.  My apologies if I
didn't make the point clear enough before: I trust I have done so now.

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Eric:  Will web authors really write off Mozilla as hopeless if it displays
colors in its Mac version the same way all Windows browsers do, rather than
differently from all Windows browsers?  Won't they prefer that instead?

Comment 41

[saari (gone)]

Uh, IE supports ICC profiles, AKA ColorSync. So the right thing happens to be
the same as the compatible thing in this case.

Comment 42

[Eric A. Meyer (dead account)]

David (comment 40): I propose that we patch Mozilla so that the gamma correction
in the Windows and Linux (and any other platform) versions match the appearance
that the MacOS has had for all these years.  Think people will prefer that?  If
not, why not?  It makes as much sense as changing the Mac version to look like
Windows.

When I'm surfing with 2002041903, the browser's color handling looks broken.  I
can immediately see that everything looks too dark.  If I were to load the same
Web site into the four Macintosh browsers I have available, three would look the
same and one (Mozilla) obviously different.  Neither developers nor everyday
surfers will see this as a good thing.  As both, I know what I'd do: stop using
Mozilla and just switch to IE/Mac for my Macintosh browsing.  It may not be as
cool as Mozilla, but at least it doesn't force me to squint at sites through
what appears to be a fairly dirty window.On the other hand, I will admit that
making gamma correction into a perference could actually be a useful development
tool.  That way a Web designer could create a design, and then flip it to
"Windows gamma" to see how the colors fare in that operating system, and maybe
to other gammas to see what happens in those circumstances.  But said
preference, if it existed, would have to default to "Mac gamma" (or "off" or
whatever) so as not to alienate either developers or everyday surfers.  Even
those who use it to check designs in other-OS gammas, will almost certainly
switch it back to the Mac gamma the instant they're done with color-checking and
just want to go Web surfing for a while.

Comment 43

[Greg Roelofs]

Eric (comment 39):  I understand your point, but I think you missed mine, which
were twofold.  The first point is philosophical: you believe consistency with
legacy browsers should take precedence over conformance with the specifications
because "that's what users want." I fundamentally disagree with that philosophy;
that's how we ended up with an unusable OBJECT tag for four years. If the user
preference is that strong, then the proper way to address it is by revising the
spec accordingly.

The second point is more immediate:  before getting too worried about what users
will or won't like about a truly spec-conformant browser, we need to verify that
it *is* in fact conformant.  I've already indicated that there's probably a bug
in the Mac part of the gamma-handling code (based on the side-by-side PNG
comparison, although that wasn't definitive); that needs to be verified and, if
it's real, fixed before tossing out the baby with the weather.com bath water. 
(There's also this bug to fix, namely the hardcoding of a Mac gamma value.) My
guess is that the visible differences will be pretty small if everything is
working correctly.

In the meantime, it's probably worthwhile to temporarily disable gamma
correction on the Mac by hardcoding a 2.2 value in the whatever::getGamma()
method (per one of tor's newest comments in bug 53597). It doesn't appear that
we're going to be able to nail down the specifics of the Mac-gamma bug any time
soon, so there's no real sense in leaving the door open to gobs of "it changed
and I don't like it" bugs.

As for your web-design point in comment 42:  gamma correction already *is* a
user preference--that's exactly what the system setting is there for.  If you
want to see what a PC display looks like, set it to sRGB.  It's not Mozilla's
place to duplicate that sort of functionality; aside from being redundant, it
would be very difficult to get right, since you're basically second-guessing the
user and/or the system (possibly twice).

Greg

Comment 44

[bruno lapeyre]

As I show it the issue isn't appearing with 1.0rc1 but only since 20020419. Is
it so difficult to come back to 1.0rc1 gamma correction ?
Answering to comment #36 the default "iMac" calibration is used.
I had another idea, today, to show you the difference between what 20020419 is
rendering and what it should be rendering.
I created an html table with 3 boxes using 3 web safe colors, 0066ff, ffff33,
33ff00 and used the Apple DigitalColor Meter utility  (a software provided with
Mac OS X) to calculate the value of these colors displayed with Mozilla
2002041903. The results are :

0066ff is becoming 0042ff
ffff33 is becoming ffff18
33ff00 is becoming 18ff00

So people who don't use Mac OS X can now see how important is the difference :
creating a 2 columns and 3 rows html table with one of these values in each cell ;)


Mozilla 1.0rc1, on the other hand, is giving excellent results :

0066ff is becoming 0063ff
ffff33 is becoming ffff31
33ff00 is becoming 31ff00

 I.E 5.1.4 is giving  *exactly* (no difference at all) the same excellent results.

Comment 45

[Eric A. Meyer (dead account)]

Greg (comment 43): I guess you're right, I didn't understand your points.  I
agree with you that conformance is highly important, and often more important
than legacy behavior.  I don't agree that one always takes precedence over the
other, though.  That's why I really like the quirks/standards mode mechanism--
it lets us get to conformance without blowing off legacy compatibility.

And I certainly agree that if this is in fact a bug that's causing the darkness
in Mac builds, then it needs to be fixed.  Then we can argue about what to do. 
Disabling the correction for the moment is definitely something I favor.

However, I'm confused about this: "gamma correction already *is* a user
preference--that's exactly what the system setting is there for.  If you want to
see what a PC display looks like, set it to sRGB.  It's not Mozilla's place to
duplicate that sort of functionality; aside from being redundant, it would be
very difficult to get right, since you're basically second-guessing the user
and/or the system (possibly twice)."

Again, I agree with what you've said.  So why is Mozilla doing gamma-correction
at all?  Why not just live in the OS, use the OS gamma setting, and stop trying
to change it?  That's what confuses me-- if Mozilla is not trying to duplicate
gamma handling, what's making all the colors wonky in 2002041903?  And why does
the browser need to get the gamma value from the OS?

Comment 46

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I did a bit of investigation on a Mac in the computer lab.  I found the following:

MacIE5 gamma corrects PNG images at 1.29 (and CSS colors at 1.0), rather than
the 1.45 that we're currently doing.  It doesn't change its correction when the
system gamma settings change.

I poked around in the system gamma settings a bit, and got the sense that the
2.61 number is no longer valid.  In particular, when I ran through the
"Calibrate" wizard in the Colors tab of the Monitors control panel, I was able
to choose two different things:
 * first, using test images, choose the "native gamma" of the monitor.  This
defaulted to 2.2 when I used the non-advanced version of the wizard, but about
2.61 when I used the advanced version and it gave me separate R/G/B dialogs.  I
suspect the 2.2 may come from a monitor profile or something like that.
 * second, it allowed choice of a number of gamma settings, including "1.8"
(traditional Mac) and "2.2" (PC).

Considering these things, I suspect that we should be returning 1.8 rather than
2.2*(2.61/1.8).  This would result in a correction of 1.22 (rather than 1.29 or
1.45).

Finally, I wonder what exactly we're going to get back from the ColorSync
profile.  I think we shouldn't be undoing things that result from the
calibration of the monitor.  What would be nice is if we could actually access
that gamma setting that could be 1.8 or 2.2, and simply return that so that we
could correct for (i.e, undo) it, but not correct for anything else.  Does that
make sense?  (Yes, we really do want to undo it, since the whole point of this
is that colors should be consistent across platforms.  If they're not, and if,
as Mac people like to say, the lighter images look better, then doing otherwise
would be attempting to do to images on the web something just as bad as what
Microsoft has attempted to do to other things in the computer world -- exploit
the fact that many web designers and photo/image editors use Macs to make the
Web so that it works better on Macs than on PCs.  That is, IMO, an unacceptable
practice and Mozilla shouldn't be encouraging it.)

Comment 47

[Greg Roelofs]

Eric,

[trying to make this more email-friendly]

> Again, I agree with what you've said.  So why is Mozilla doing
> gamma-correction at all?  Why not just live in the OS, use the OS gamma
> setting, and stop trying to change it?  That's what confuses me--if Mozilla
> is not trying to duplicate gamma handling, what's making all the colors wonky
> in 2002041903?  And why does the browser need to get the gamma value from the
> OS?

If we accept the edicts of the HTML, CSS and PNG specs (and probably the sRGB
and/or ICC spec(s)), then the goal is for a given color in an image or a web
page (HTML or CSS) to _look_ the same on all systems.  That means the light that
comes out of the monitor should be the same, not the pixel values in memory
somewhere.

(Aside:  that's why all these screenshots showing absolute pixel values are
fairly useless for those of us without Macs--they display differently on my
system than on the systems where they were captured, so all I can say about them
is that yes, those are the absolute pixel values in those captures.  The
screenshots that _are_ useful are the ones showing two side-by-side renderings
["differential"]; if we know exactly how one of the apps works, then we can
determine whether the other one is correct or not.  That's also why I need some
Mac display code--then I can merge it with my own PNG demo code and have
somebody compile it and run it on some PNG images whose characteristics I know
exactly.  That's then the known reference, and we can test whether MSIE and
Mozilla match it or not.)

We all know and accept that systems are different in how they display things,
right?  That is, the same mid-range pixel data on a NeXT will look brighter and
more washed out than on a default SGI console, which in turn will look brighter
than on a classic Mac, which in turn will look brighter than on a standard PC. 
Most of us have seen this effect firsthand, often between Macs and PCs with
scanned images or whatnot.

All of these systems' monitors are basically the same (not counting differences
due to "color temperature" settings, which have to do with shifting gamuts and
*slight* changes to the overall gamma, I think); that value is 2.2 according to
almost everybody except for Charles Poynton, who still maintains it's 2.4.  The
real differences come in the system (graphics card) lookup tables, which always
sit between the pixel data and the monitor, I believe.  PCs generally don't have
any LUT, so the pixel data are effectively in the sRGB color space--i.e., the
total display-system gamma is LUT * CRT = 1.0 * 2.2 = 2.2 = sRGB.  Macs have a
LUT with (reportedly, and maybe formerly) a slightly strange fudge factor, so
their overall gamma is [(mac-gammalike-number)/2.61 * 2.2] = 1.5 or so for the
default setting of the mac-gammalike-number (1.8).  SGIs also have a gamma-like
number, but it's the inverse of what we PNG folks call the LUT exponent; that
is, the overall gamma is [1/(sgi-gammalike-number) * 2.2] = 1.3 or so for the
default SGI gamma-like value of 1.7.  Note that the LUT exponent for a Mac
should be _bigger_ (either 2.61 or 2.2, depending on how we reconcile David's
tests with previous "expert knowledge") to make the overall setting the same as
in a PC, while the LUT exponent for an SGI should be _smaller_ (1.0) to do the
same thing.  Both settings make the LUT a linear ramp.  (And NeXTs have a LUT
with exponent 1/2.2 by default, so their _overall_ system gamma is 1.0.  This is
great for doing graphics calculations but lousy from a human-perceptual point of
view; our eyes are logarithmic.  But that's neither here nor there.)

Anyway, the point is that different systems do different things to the pixel
values, and that makes the light coming out of the monitor different for the
same pixel values.  Macs, SGIs and even NeXTs (I think) go further by allowing
you to change the system behavior (i.e., modify the LUT); thus a single system
can behave like many different ones, depending on its settings.

With regard to the PNG/CSS/HTML specs, the goal is to make the *light* look the
same, so the pixel data must be modified to cancel out all of the LUT
shenanigans.  And that's why Mozilla, in attempting to conform to those specs,
needs to query the local system for its LUT settings in order to know how to
cancel out the local differences in display system.  And that, in turn, allows a
designer to use a tool like Photoshop or the GIMP to create web graphics with a
certain brightness/saturation/etc., view it with Mozilla, and know that it will
look identical on any other Mozilla/hardware combination.  It is a different way
of working than designers are currently used to, no question about that, but a
lot of us think it's a better way.  (Btw, note that any given image can be
post-adjusted by adding (or modifying) an ICC profile or internal gamma info;
there's no need to modify the compressed pixels themselves.)

Sorry for the excessive verbosity, but it is a moderately complex subject. :-) 
(And I meant to send this hours ago, but I got sidetracked...)

Greg

Comment 48

[bruno lapeyre]

For your information: the gamma problem found under Chimera 0.2.2 and 0.2.3 has
been solved under Chimera 0.2.4. 

Comment 49

[Michel Fortin]

Well, if you want to handle colors correctly on the mac then I think you should use ColorSync Manager functions to get the appropriate colors. Here is what I've found:

Matching Colors to Displays Using ColorSync With QuickDraw Operations
http://developer.apple.com/techpubs/mac/ACI/ACI-66.html

Matching Colors Using the Low-Level Functions
http://developer.apple.com/techpubs/mac/ACI/ACI-68.html

If you really want to duplicate another thing, well on Mac OS X the current gamma setting is easy to obtain. Take a look at ApplicationServices/CoreGraphics/CGDirectDisplay.h header, then you can use this function:

CGDisplayErr CGGetDisplayTransferByFormula(CGDirectDisplayID display,
                                    CGGammaValue *redMin,
                                    CGGammaValue *redMax,
                                    CGGammaValue *redGamma,
                                    CGGammaValue *greenMin,
                                    CGGammaValue *greenMax,
                                    CGGammaValue *greenGamma,
                                    CGGammaValue *blueMin,
                                    CGGammaValue *blueMax,
                                    CGGammaValue *blueGamma);

Just take the average of redGamma, greenGamma and blueGamma. I think with Mac OS 9 you must calculate it with the transfer table.

Comment 50

[Andrew Thompson]

I wrote a test program based on the sample code I posted the other day. What's 
below is 4 gamma settings, and the Red, Green, Blue TRC curves they produced. 
There is no grey curve in the profile.

Gamma 2.6:

size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 2, 154, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 2, 154, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 2, 154, 


Gamma 2.2:

size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 2, 51, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 2, 51, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 2, 51, 
the error, if any: 0


Gamma 1.8

size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 1, 205, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 1, 205, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 1, 205, 
the error, if any: 0

Linear 1.0 Gamma

size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 
size: 14
99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 
the error, if any: 0

Recall that these are bytes, and as such should be converted to floats by 
dividing by 256 if this is desired.

As to the meanings of these curves, some insight can be gained here:
http://java.sun.com/j2se/1.3/docs/api/java/awt/color/ICC_ProfileRGB.html

See in particular getGamma and getTRC - even though this is documentation for 
Java, I'm pretty sure the Apple API is providing the same information (so long as 
you remember to divide each of the above figures by 256).

I'm not sure this helps us much, as we're getting back a curve and we're only 
eqipped to handle a simple value. Plus, from the Java doc, I don't think the TRC 
curve is gamma values per se - its a lookup table for colour adjustment. I'm 
going to try calling the function proposed in comment 49 and see what I get.

Comment 51

[Andrew Thompson]

Attachment: Simple command line tool to dump Mac Gamma settings

Simple C program (make a new CoreServices Tool project in project builder and
add the ApplicationDervices Framework to the External Frameworks and Libraries
group) command line app which dumps gamma settings

Comment 52

[Glenn Randers-Pehrson]

> I wrote a test program based on the sample code I posted the other day.
> What's below is 4 gamma settings, and the Red, Green, Blue TRC curves they
> produced. 

>Gamma 2.6:
>
>size: 14
>99, 117, 114, 118, 0, 0, 0, 0, 0, 0, 0, 1, 2, 154, 

They aren't curves.  They are just encodings of gamma.  Here's the
decoding per ICC spec, paragraph 6.5.2:

99, 117, 114, 118: type signature='curv'
 0,   0,   0,   0: reserved= 0000 (4 reserved bytes)
 0,   0,   0,   1: count = 1 (following 2 bytes are gamma)
 2, 154:           gamma = 2-154/255 = 2.6039

Glenn

Comment 53

[Andrew Thompson]

Here's what I get for the same 4 gamma settings with the new prog attached in the 
patch:

Gamma 2.6:
r: 1.116776, g: 1.116776, b: 1.116776

Gamma 2.2:
r: 0.944962, g: 0.944962, b: 0.944962

Gamma 1.8:
r: 0.773163, g: 0.773163, b: 0.773163

Gamma 1.0
r: 0.429535, g: 0.429535, b: 0.429535

Can anyone make sense of this?

Comment 54

[Andrew Thompson]

Thanks to [e-mail] it looks like we can ignore the Mac OS X only core 
graphics function. I read the 'curv' definition in the ICC spec last week but the 
significance escaped me tonight!

Thanks for setting me right on this. So it looks like we have our Gamma values 
now - I can just average accross the RGB channels to get a single figure. So 
could someone with a clue on this stuff decide what nsScreenMac::GetGammaValue 
should be returning? If so I'll code it up - what I mean is, is the 1.8/2.61 
fudge factor still needed?

Comment 55

[Glenn Randers-Pehrson]

> can anyone make sense of this?
>Gamma 2.6:
>r: 1.116776, g: 1.116776, b: 1.116776

2.6/1.116776=2.328

>Gamma 2.2:
>r: 0.944962, g: 0.944962, b: 0.944962

2.2/0.944962=2.328

>Gamma 1.8:
>r: 0.773163, g: 0.773163, b: 0.773163

1.8/0.773163=2.328

>Gamma 1.0
>r: 0.429535, g: 0.429535, b: 0.429535

1.0/0.429535=exercise for the reader

>Can anyone make sense of this?

Well, there does seem to be a pattern.

Glenn

Comment 56

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd guess 2.328 was the result of the calibration from the Monitors control
panel, or perhaps the default profile for the monitor that the system in
question has.  (See comment 46.)  It would be nice if we could avoid correcting
for that, but, then again, it's probably always going to be close to 2.2 (or
slightly larger).

Comment 57

[Masatoshi Kimura [:emk]]

You don't have to care about "real" gamma on Macintosh.
All you have to do is:
1. Simply return 2.2 in nsScreenMac::GetGammaValue()
   to convert the color profile to sRGB (NOT an actual
   display color profile).
2. Call NCMBeginColorMatching(sRGBProf, nil, &matchRef)
   to tell the system about source color profile.
3. Draw whatever you want.
4. Call CMEndColorMatching(matchRef).
System will convert from sRGB to actual display color
profile. That's all.

Comment 58

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Would we have to make those calls for every paint request, or for the lifetime
of the application?

Comment 59

[Masatoshi Kimura [:emk]]

Per paint event.
http://developer.apple.com/techpubs/mac/ACIReference/ACIReference-254.html
| Note 
| If you call NCMBeginMatching before drawing to the screen's graphics device 
| (as opposed to an offscreen device), you must call CMEndMatching to finish a 
| matching session and before calling WaitNextEvent or any other routine (such 
| as Window Manager routines) that could draw to the screen. Failing to do so 
| will cause unwanted matching to occur. Furthermore, if a device has color 
| matching enabled, you cannot call the CopyBits procedure to copy from it to 
| itself unless the source and destination rectangles are the same. 

Comment 60

[Kai Lahmann (is there, where MNG is)]

*** Bug 140314 has been marked as a duplicate of this bug. ***

Comment 61

[Andrew Thompson]

Attachment: Screenshot shows GetGammaValue() returning 1.0, 1.8, 2.2 and 2.6

I implemented GetGammaValue() and checked it returns the expected values (or
close to) for my 4 test cases 1.0, 1.8, 2.2 and 2.6. (top to botton in
screenshot)

Screenshot captured using built in Mac screen capture with the display set to
that gamma using the Displays control panel.

I'm pretty uneducated about this, but I'm beginning to see these screen shots
have little value - eg, the 1.0 screenshot will probably look *way* to dark to
you, as it does to me now with my monitor set to 1.8 (where I usually have it).

But if I switch my monitor profile to 1.0 gamma, it looks OK, which isn't
surprising if you think about it...

Whether that's right I don't know.

When I post the patch you'll see I haven't included the traditional mac fudge
factor, I'm just literally returning 1.0, 1.8 etc. Thoughts on this?

Comment 62

[Andrew Thompson]

Attachment: Patch to implement GetGammaValue on Mac OS.

Comment 63

[Henri Sivonen (:hsivonen)]

[e-mail]: Mac IE 5 does support ColorSync. It just isn't enabled by
default. I guess they left it off by default in order to avoid complaints
similar to your complaints about Mozilla's gamma correction. :-/ Have you tested
IE with the ColorSync pref turned on? Are you using the Mac default display
gamma in the display setting of the OS?

[e-mail]: My guess is that 
target_gamma / value_returned_by_Quartz = device_native_gamma

[e-mail]: (Why do users change the display gamma?) I switched to 
the 2.2 gamma after realizing that
1) Graphics on the Web have been usually designed for uncorrected CRT gamma 
   anyway.
2) Graphics made by me will be viewed without gamma correction anyway by 
   others, so using the 2.2 gamma makes my graphic work degrade more 
   gracefully.
3) My color printing workflow works relatively well if the image data is 
   targeted to the 2.2 gamma. Using the 1.8 display gamma and applying fancy 
   color matching tricks didn't work.

(I'm not opposed to gamma correction when it is correction, but double
correction is very uncool.)

Comment 64

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 140964 has been marked as a duplicate of this bug. ***

Comment 65

[nnooiissee]

re: comment #63, just tested the colorsync option in mac os x ie 5.1.4, and it
is not perfect. my test of choice is http://www.debian.org/ which, mac os x
mozilla (with gamma correction) renders with the pngs matching the html colors,
and nothing else does.

ie's rendering with colorsync does seem to be lighter then moz's, but that is to
me not important enough to be a point in either's favor.

Comment 66

[Matthias Versen [:Matti]]

*** Bug 141302 has been marked as a duplicate of this bug. ***

Comment 67

[Rafael Ebron (:rebron)]

adt: nsbeta1-

Comment 68

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 69

[Greg K.]

See also Bug 16769.

Comment 70

[d]

This bug hasn't been updated since 2003, wasn't this supposed to be WONTFIX according to #68? Also, it's assigned to a person who is gone.

Is this fixed, and so, can we close this and update the status on Wikipedia, http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28graphics%29 ?

Comment 71

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 72

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.