I just came across this:
Mac OS X v10.6: About gamma 2.2
<http://support.apple.com/kb/HT3712> (Last Modified: May 06, 2010)
"To better serve the needs of consumers and digital content producers,
Mac OS X v10.6 Snow Leopard uses a gamma value of 2.2 by default. In
versions of Mac OS X prior to 10.6, the default system gamma value was
1.8."
I had been under the impression that Apple had changed to gamma of 2.2
several years ago, but I guess not!
I *think* this change should noticeable only when viewing images that
do not have a color profile. You wrote "the
picture goes very flat if I strip an sRGB profile..." If by that you
mean that you leave the image without a profile, then, according to
the kb article
"... images that do not contain color profiles might appear darker in
Mac OS X v10.6 than they did in earlier versions of Mac OS X. Adding
the sRGB IEC61966-2.1 profile or Adobe RGB (1998) profile to these
images lets them display correctly."
They say "darker," you say "flat." Hmm.
If your images have color profiles attached, and you use a custom
profile for your monitor and a custom or manufacturer's profile for
your printer, then this "change" to gamma 2.2 in OS X 10.6 should not
matter.
eo
On Jul 14, 2010, at 1:09 AM, Martin Middelhoek wrote:
The SL stands for OS X 10.6 aka Snow Leopard. I make the distinction
with 10.5 aka Leopard, because the color management and printer driver
stuff have been subtly modified in this revision. In 10.5 and with
Aperture2 it was clear what to do independent of the printer. Now in
10.6 and with Aperture3 the final step of the color management has
been delegated to the manufacturers printer driver, which is a world
of pain. Most people with an Epson are still fighting; luckily I have
a Canon but I am still not completely happy with the results on some
non-Canon papers.
Mark Dubovoy is mainly referring to these printing problems in OS X
with the hand-off from the application to the printer driver.
The choice between sRGB and Adobe RGB comes down to the gamut of the
image. If the image has a wide gamut to begin with it is better to go
with Adobe, with rather "flat" images sRGB will utilize the bits
better. I do mainly landscapes and have never been able to see the
difference in a side by side comparison (maybe with a better monitor
or printer...). So I go with sRGB mainly for the better compatibility
between applications and devices. Adobe gets so easily tripped up
somewhere in the workflow. The 16-bit versus 8-bit debate is also
interesting. I never expected to see the difference, but I did, and
always in deep blue skies. There the hue changes very subtly, and you
require all the resolution you can get to prevent banding. The 8-bit
images fall apart too easily when imported back into Aperture and
subjected to final adjustments.
I have started a thread in the Apple forums to find out how OS X
handles (or should handle) images without a color profile. I always
assumed it would default to sRGB, but it appears that it does not: the
picture goes very flat if I strip an sRGB profile, so maybe Adobe is
the default?
As you say, slightly off topic. But this is the Hugin on OS X thread,
so only slightly.
Martin
On Jul 14, 7:14 am, Eric O'Brien <eri...@extramonday.com> wrote:
First, I guess missed something along the way. You (Martin) wrote
"...I have not yet discovered how images
without a profile are supposed to be handled in SL." Uh... what is
"SL?"
Next, I don't know if there's a "default" color space in OS X, but if
you are going as far as using 16 bit deep images it seems counter
productive to use a color profile on the list that has pretty much
the
smallest gamut. Of course, *eventually* you would probably want to
reduce the pano to 8 bit sRGB, but while you're working with it it
seems that a wider gamut such as Adobe RGB (1998) or ProPhoto RGB
would be better. In theory anyway... I don't know if ordinary
persons
would be able to see any problems if you just kept using sRGB.
(Adobe
RGB is much larger than sRGB and ProPhoto is much, much larger than
Adobe RGB.)
Slightly off topic now, but it appears that there are circumstances
on
the Mac where it is *impossible* to have "no" color management.
See <http://www.luminous-landscape.com/tutorials/solving.shtml
>
eo
On Jul 13, 2010, at 2:10 AM, Martin Middelhoek wrote:
Hi Harry,
thanks for the prompt response.
I export from Apple Aperture3 to 16-bit TIFF with the color profile
sRGB IEC61966-2.1. It was my believe that sRGB was the default color
space on OSX, so loosing the profile would not lead to disaster.
Obviously I was wrong, but I have not yet discovered how images
without a profile are supposed to be handled in SL. The finished
pano's get imported back into Aperture for final adjustments and are
then exported again as 8-bit TIFF and sRGB to Pano2VR. There also
seems to be a color profile issue with that application which I will
try to tackle next (or maybe it is just a scaling thing).
My whole flow is color managed and calibrated using icc-profiles all
the way. As a stopgap I can use Preview to assign the correct
profile
and after that the input and output of Hugin are
indistinguishable. I
will try to figure out where the profile information is living in
the
images. In preview it shows up under General Info as "ColorSync
profile: sRGB IEC61966-2.1" and under More info -> General as
"Profile
Name sRGB..". Is there any reason why exiftool -all:all can't find
it,
all groups and all writeable tags, right?
Martin
On Jul 13, 9:17 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
2010/7/13 Martin Middelhoek <m.middelh...@gmail.com>
Hi Harry,
just found another bug: Hugin is stripping the color profile from
the
output file; or maybe not copying it.
I tried to use exiftool -all:all to copy it myself, but to no
avail.
Where is this going wrong? I seem to remember that this once
worked.
This explains some of the weird color casts that I have been
seeing.
Martin
Hi Martin,
These are the settings that exiftool should use:
#define HUGIN_EXIFTOOL_COPY_ARGS "-
ImageDescription -Make
-Model -Artist -W
hitePoint -Copyright -GPS:all -DateTimeOriginal -CreateDate -
UserComment
-ColorSpace -OwnerName -SerialNumber"
These parameters are missing the "-icc_profile" and the "-XMP"
option tags
from exiftool. I think that's the biggest problem for you as
colorspace is
not the only parameter that should be used when using images with
color
profiles.
IMO, Hugin could and should also use: "-IPTC:all -JFIF:all -
ColorSpace
-icc_profile -XMP"
I will post a separate mail about this asking users if I can add
these to
the trunk or whether there are some serious arguments why I should
do that.
What kind of input files do you use and what kind of output files
(including
bit depths)?
Are you using icc color profiles?*
*Harry*
*
--
You received this message because you are subscribed to the Google
Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available
at:http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group athttp://groups.google.com/group/hugin-ptx
--
You received this message because you are subscribed to the Google
Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
--
You received this message because you are subscribed to the Google Groups "Hugin and
other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
