Ryuichi Sakamoto on Flickr

kbaird says:

Great portrait!
Posted 19 months ago. ( permalink )

Caroline says:

Hero!
Posted 19 months ago. ( permalink )

Lightmash says:

Beautiful portrait!
Posted 19 months ago. ( permalink )

Koich says:

Beautiful picture
Posted 19 months ago. ( permalink )

In Flock on the Mac, this photo is closer to the normal tones in your series of beautiful portraits.
Do you have a Lightroom preset you use for portraits from the M8 or do you do every photo individually?
Posted 19 months ago. ( permalink )

todd_wood says:

Hello Ryu. Very very nice Joi!
Posted 19 months ago. ( permalink )

gwilmore says:

This is a nice portrait, and interesting, too!
Posted 19 months ago. ( permalink )

Burnt Pixel says:

Love him, love this!
Posted 19 months ago. ( permalink )

elmimmo says:

Did not fit in a twit.

This is what I think is happening with the color inconsistencies. I only assume what GC is actually doing. You can ask Lemke to verify my explanation, he is a rather receptive guy to feedback.

Knowing the following:

1. Firefox (and pretty much all non-cocoa Mac OS X software) discards profiles and forwards RGB values straight to Mac OS X display engine (preferences), which in turn, interprets those RGB values according to the display profile you selected in those preferences.

I.e. No matter the embedded profile, Firefox displays all images, not as managed sRGB, but in the user’s display profile’s color space.

2. In your specific case (although it probably extends to other users too) sRGB images look washed out if you discard the profile and interpret their colors as per your display profile.

Effect: Images uploaded straight from Lightroom, which have an sRGB profile embedded, will look considerably washed out in any non-color-savy browser (anything but Safari and upcoming Firefox v3 with custom settings).

There is no way around Mac OS X not defaulting to an sRGB color space for images without a profile embedded. (On Apple’s defence, it is just as crap as Windows there). There was a discussion ages ago in Apple's Colorsync mailing list about why Apple decided not to use sRGB as the default profile for images without one embedded. Apple’s comments really made no sense at all (as people quite smarter than me agreed), but one has to assume it is for performance reasons.

This is how GC is trying to solve it:

GC tries to fix it by “Merge’ing (your display’s) color profile into image”, i.e. converting the RGB values of the image from sRGB to your display’s profile, so that the colors look the same using your display’s profile (i.e. when colors are not managed), as they would if they would look sRGB-color-managed. On your computer, that is, since other people use their own custom display profiles. Then it proceeds to save without embedding any color profile.

That, though, (IMHO) is a weird solution: since it is not possible, anyway, to be color-accurate on most scenarios (since dummy browsers do not color manage), GC is trying to produce accurate images that will look accurate, if only, on your display.

Still, it goes against the standard of implying that non-profiled images should be considered as sRGB (a standard, again, that both Apple –who can color manage but decided not to for unprofiled images– and Windows –who does not color-manage at all– ignored).

So, if point 2 above (non-color-managed images look washed out) is true for most users, which I do not know (but presume so), well, at least GC is making a blind approximate guess by bumping up the saturation to match your display profile, hoping it approximates better to other user's display profile than the dull sRGB. It SHOULD be embedding your display profile (which is not), though, in case someone does ever see your image in a color-managed environment and incorrectly assumes the image is sRGB.

Still, I take the non-practical, standard-correct position that images for the web SHOULD be in a sRGB color space (not one’s specific display’s) and that they SHOULD have the sRGB profile embedded (just for the sake of being a nerd, since like I tried to explain, according to what I think GC is guessing, all my pictures will look washed out on most scenarios)

Should I note that, as soon as Firefox 3 comes out and some of it smart-ass users tell it to render un-profiled images as sRGB, the ones you “Merge’d color profile into” will look wrong on their displays (or, should I say, wronger than they look now, if I may remind that they cannot look right in any display but yours as of now, anyway) and overly-saturated.
Posted 19 months ago. ( permalink )

Perlina (Per) away for a few days says:

This man is a genious. I love him. When i saw him in the movie"Merry xmas Mr Lawrence" It was love. (from my part :)
Posted 18 months ago. ( permalink )

Sài says:

great portrait!
Posted 18 months ago. ( permalink )

joshhikes says:

Hi, I'm an admin for a group called imagist - numinoso come parole, and we'd love to have this added to the group!
Posted 18 months ago. ( permalink )

in/camera says:

Great
Posted 18 months ago. ( permalink )

MikeyPics says:

I would like to hug him please.

beautiful photo.
Posted 18 months ago. ( permalink )

nhr says:

elmimmo wrote:
> No matter the embedded profile, Firefox displays all images, not
> as managed sRGB, but in the user’s display profile’s color space.

On OS X, there's indeed a "default" color profile that is used to interpret image files that haven't got any valid color profile tags, or those that have been stripped of their tags by non color management-aware apps like Firefox v1.x and v2.x

That default profile is not the display profile's color space, but one named "Generic RGB Profile".

A reference version of that profile can typically be found in:
/System/Library/ColorSync/Profiles/Generic RGB Profile.icc

I wish Apple had provided a mechanism to override that default Generic RGB Profile, so that the user could direct the system to interpret all untagged image data e.g. as sRGB.

I've once edited the aforementioned "Generic RGB Profile.icc" file using a hex editor, putting in the white point and RGB primaries XYZ coordinates, RGB tonal response curves and chromatic adaptation matrix values copied from a sRGB profile, hoping that the system would then, in effect, interpret untagged RGB data as sRGB.

That didn't work :-( sRGB pictures displayed by Firefox v.2 came out desaturated, as usual.

I thus suspect that the Generic RGB Profile's mathematical description is in fact hard-coded somewhere in the OS libraries, and that the aforementioned Generic RGB ICC file is provided only for reference purposes by 3rd-party apps, and isn't actually loaded and used by OS X itself...

I guess the basic rule one should follow is to always embed a color profile — e.g. sRGB, AdobeRGB — to the picture files one produces, so that OS X doesn't have to fall back to this somewhat bizarre and Apple-specific "Generic RGB Profile".

Sakamoto-san's previous picture posted by Joi doesn't have any embedded color profile tags [frown], and its colors appear a bit unnatural on a Mac, the skintones being unnaturally reddish, for example.
The second version of this picture, to which I'm posting this comment, has a proper sRGB profile embedded, and the skintones look quite natural in Safari.

One easy way to check whether a picture file contains a proper color profile tag is to launch /Applications/Utilities/ColorSync Utility and open the picture file. ColorSync Utility can display the name of the embedded color profile, if any, and one can also embed a standard color profile like sRGB or AdobeRGB to files that don't have valid color profile tags.
Note, however, that ColorSync Utility will decompress and recompress JPEG files when saving a version with a new color profile space, leading to some slight degradation of picture quality due to the lossy JPEG recompression process.

Anyway, until the hopefully color-managed Firefox v.3 is released, it might be a good idea — especially when accessing photography-oriented web sites like Flickr — to use a color management-aware web browser like Safari that will properly process the color profile tags embedded in picture files...
Posted 18 months ago. ( permalink )

elmimmo says:

@nhr
> That default profile is not the display profile's color space, but one named "Generic RGB Profile".

While that is the common thought (and what Apple insisted in on that non-sensical thread I linked to), there one easy way to debunk it:

1. Open this very page in Firefox, and by its side, open Sakamoto's picture in Preview (tried on Mac OS X 10.5's).

2. Change its embedded sRGB profile by going to menu Tools > Assign profile… (which doesn't touch the stored RGB values, just the way they should be interpreted by color managed applications) and select Generic Profile. You will see the colors of the images are slighly different, hence, Firefox is NOT falling back to Generic RGB profile.

3. Try this time embedding your display profile. They should look identical.
Posted 18 months ago. ( permalink )

elmimmo says:

@nhr
> I guess the basic rule one should follow is to always embed a color profile — e.g. sRGB, AdobeRGB — to the picture files one produces, so that OS X doesn't have to fall back to this somewhat bizarre and Apple-specific "Generic RGB Profile".

Again, this solves nothing. For a start, note again that both Sakamoto's pictures are being rendered with the same default profile (which I state is the display profile, which you seem to –mistakenly– disagree with), since Firefox cares about it being embedded or not as much in one image or the other (that is, not one bit).

They look different because, while their RGB values are being interpreted the same way, those values are simply different from one image to the other. Joi converted the first one from sRGB to whatever GC's is using (me says again his display profile).

So, what you suggest, while compliant with the sort-of agreed-upon (by everyone but the very two most popular OS developers) standard proper way of doing things (and like I said, what I will continue to do with my pictures), will not solve his problem one bit. Mac OS X will still fall back to each user's display profile (Generic RGB, according to you) in Firefox no matter what.

Note: I do and did suggest the same as you, I am just pointing out that I do so because, if there is no way around the problem, I'll at least do it according to the paper.

There is still the issue that Joi is delivering his images on his display's profile color space by using GC's "merge profile" feature. If he goes this way he should be embedding it, since at least Safari users will still see the picture the same as him. Regarding non-Safari users, well, the doubt is if his purportedly properly calibrated display's color space compares better to another average uncalibrated one (which is what most people will have, I guess) than to sRGB. If that is so, I guess he is going for the most practical solution by using that GC feature. Otherwise, he is just screwing up things worse.
Posted 18 months ago. ( permalink )

nhr says:

elmimmo wrote:
> While that is the common thought (and what Apple insisted in
> on that non-sensical thread I linked to), there one easy way
> to debunk it:
>
> 1. Open this very page in Firefox, and by its side, open
> Sakamoto's picture in Preview (tried on Mac OS X 10.5's).

Excellent test, and the results indeed look identical, as you predicted.

Your proposed test managed to convince me 65% that I'm wrong, and that untagged RGB data is indeed, as you say, interpreted by OS X with the currently active display profile, instead of the "Generic RGB Profile".

There's a lingering 35% of doubt left in my mind, however (^^;

Consider the following color space transformations presumably applied by OS X when displaying untagged RGB data:

1. System notices that a particular piece of RGB data is untagged, and thus assigns it, say, the currently active display profile.

2. Assume we have two different displays connected to the system, e.g. an analog VGA-connected CRT and a DVI-connected LCD. Assume both displays have been calibrated, resulting in two distinct display profiles.

3. Open the untagged picture in Firefox. Display it on the CRT. Then display it on the LCD. Which is the "active" display profile used to interpret the untagged data ? The CRT's, or the LCD's ?

4. Will OS X change the interpretation of the untagged data on the fly, on a per-pixel basis, as I move Firefox' window between the LCD and the CRT, or leave the window straddling the two displays ?

The "canonical" way to properly display a tagged, thus properly identified piece of RGB data on a calibrated display is as follows:

1. Convert the source RGB data from its originally specified profile — e.g. AdobeRGB — to the "Esperanto" of all color spaces, i.e. Lab space a.k.a. PCS or Profile Connection Space. To do so, use the mathematical description of the source space — e.g. AdobeRGB's white point and RGB primaries' CIE XYZ coordinates, tonal response curves etc.

2. Then convert from this Esperanto Lab space to the display's space, now using the mathematical definitions — tonal response curves etc. — measured by the display calibrator and stored in standard ICC format in the display's profile file.

3. Perform the above two conversions — algebraically merged into a single 3x3 transform matrix for efficiency — for every pixel to be displayed.

My current understanding of color management principles is that if the untagged data is interpreted using the display profile, then the combination of these two transformations:

1. from display profile-interpreted RGB triplet to Lab/PCS space

2. from Lab/PCS space to display space

will result in an identity transform matrix, i.e. that a particular RGB triplet contained in the original untagged file, say, (R=12,G=33,B=50) will, after transiting through Lab/PCS, emerge as an identical, unchanged (R=12,G=33,B=50) triplet.
Thus, regardless of the RGB primaries coordinates, tonal response curves etc. contained in the display profile, the 8R+8G+8B = 24-bit RGB data contained in the untagged file should always be mapped as arithmetically identical 24-bit values — barring any rounding errors — in the video card's VRAM, and thus look identical on a DVI-connected LCD.

In practice, however, this assumption that [display profile -> Lab/PCS -> display profile] ~= [identity transform] does not seem to hold on OS X.

On my single-LCD Mac, switching the currently active display profile from the calibrated profile file to various profiles like Generic LCD or AdobeRGB will result in an untagged picture displayed by Firefox to change colors.

This I find bizarre, as my assumption is that if I switch my display's profile to, say, "Generic LCD" and then launch Firefox, the color transform [untagged data assumed "Generic LCD" -> Lab/PCS -> display profile a.k.a. "Generic LCD"] must be equivalent to the identity matrix, and should result in the same RGB triplet to be sent to my LCD over the DVI link as when I had set my display profile to, say, AdobeRGB.

The fact that untagged data looks different when switching display profiles has been verified using Bruce Lindbloom's LAB-encoded Macbeth ColorChecker Chart TIFF file transformed into untagged JPG by Photoshop configured with Adobe98 as working color space.
The untagged JPG has been displayed by Firefox v2.0.0.14, GraphicConverter v5.9.4 and ColorSync Utility v4.4.3 on a LCD in a darkened room, photographed slightly blurred to avoid sensor pixel and LCD pixel moiré interference with a tripod-mounted digital camera using fixed "sunny" white balance and fixed manual exposure, the resulting RAW files being then developed and then the colors sampled and compared in Photoshop by averaging 5x5 pixel areas.
Note that my test showed that Firefox, GC and ColorSync Utility have absolutely identical behaviors, i.e. display absolutely identical colors when displaying untagged RGB data. No signs e.g. of "profile merging" by GC v.5.9.4 have been observed.

The fact that the displayed colors change — i.e. that we don't see an identity matrix that should be identical, independent of the active display profile — when switching between different display profiles is consistent with the fact that untagged data is always interpreted with an unchanging profile, e.g. "Generic RGB Profile" which is the most plausible candidate among the profiles found under /System/Library/ColorSync/Profiles.

If you could provide an explanation as to why [display profile -> PCS -> display profile] doesn't always result in an identity transform, then my 35% of lingering doubt about the assertion that untagged data is interpreted using the display profile would disappear... (^^;
Posted 18 months ago. ( permalink )

Joi says:

Thanks for the comments on both the portrait and the color stuff. Very helpful. I'm going to recalibrate my monitors and stick to sRGB and stop using GC and assume that some day browsers will become "smarter".
Posted 18 months ago. ( permalink )

elmimmo says:

@nhr My head is about to go nova, and closing this damn window doesn't seem to help ^_-

It'll take a while for my two neurons to determine if I agree or not with you. But thanks for such a detailed insight!
Posted 18 months ago. ( permalink )

Joi says:

FWIW: I connected my computer to a better display and did a proper eye-one match color sync and this picture now looks the same as it does in LightRoom. Yay!
Posted 18 months ago. ( permalink )

trisha_sakamoto [deleted] says:

You've made this girl very, very happy with another great shot of Ryuichi. I could kiss you. Actually, I think I'd rather kiss Ryuichi. I'll give you a big hug instead.
Posted 18 months ago. ( permalink )

i5prof says:

I love this and his music - thanks so much!
Posted 18 months ago. ( permalink )

Gen Kanai says:

Firefox 3 will have color profile support BUT it won't be on by default. More info at Deb Richardson's blog:

www.dria.org/wordpress/archives/2008/04/29/63 3/
Posted 18 months ago. ( permalink )

Straws pulled at random says:

Wonderful portrait!
Posted 18 months ago. ( permalink )

d2s says:

Nice colours in this one.
Posted 18 months ago. ( permalink )

dakusaso says:

A great man!
Posted 18 months ago. ( permalink )

wsulistio says:

Great musician, composer..
Posted 13 months ago. ( permalink )

Vitolino says:

Master and great man !
Posted 11 months ago. ( permalink )

vca3210 says:

Genius of our time
Posted 10 months ago. ( permalink )

vca3210 says:

And I just love his hair. Hair, Glorious Hair
Posted 10 months ago. ( permalink )

fail tem reven says:

what a portrait!
Posted 6 months ago. ( permalink )

koitalow says:

wow! great!
Posted 2 months ago. ( permalink )

You	Sign in \| Create Your Free Account
Explore	Places \| Last 7 Days \| This Month \| Popular Tags \| The Commons \| Creative Commons \| Search
Help	Community Guidelines \| The Help Forum \| FAQ \| Sitemap \| Get Help

Ryuichi Sakamoto

Comments

kbaird says:

Caroline says:

Lightmash says:

Koich says:

Lars Plougmann says:

todd_wood says:

gwilmore says:

Burnt Pixel says:

elmimmo says:

Perlina (Per) away for a few days says:

Sài says:

joshhikes says:

in/camera says:

MikeyPics says:

nhr says:

elmimmo says:

elmimmo says:

nhr says:

Joi says:

elmimmo says:

Joi says:

trisha_sakamoto [deleted] says:

i5prof says:

Gen Kanai says:

Straws pulled at random says:

d2s says:

dakusaso says:

wsulistio says:

Vitolino says:

vca3210 says:

vca3210 says:

fail tem reven says:

koitalow says:

Would you like to comment?

Joi's photostream

imagist - sublime poetic direct (Pool)

Additional Information

Ryuichi Sakamoto

Comments

kbaird says:

Caroline says:

Lightmash says:

Koich says:

Lars Plougmann says:

todd_wood says:

gwilmore says:

Burnt Pixel says:

elmimmo says:

Perlina (Per) away for a few days says:

Sài says:

joshhikes says:

in/camera says:

MikeyPics says:

nhr says:

elmimmo says:

elmimmo says:

nhr says:

Joi says:

elmimmo says:

Joi says:

trisha_sakamoto [deleted] says:

i5prof says:

Gen Kanai says:

Straws pulled at random says:

d2s says:

dakusaso says:

wsulistio says:

Vitolino says:

vca3210 says:

vca3210 says:

fail tem reven says:

koitalow says:

Would you like to comment?

Joi's photostream

imagist - sublime poetic direct (Pool)

Tags

Additional Information