Hello Tom and all
Some comments in the text:
Am 01.08.11 15:25, schrieb Tom Lianza:
1. The mobile network providers don't want to see a lot of images on the
network. They use bandwidth (which you are paying for) and it can have a
real impact on through put in crowded urban networks. Mobile providers,
especially in the US, would rather not have to deal with the issues images
at all.
Mobile devices today have access both to the mobile network and to W-Lan
networks. They have integrated cameras and provide applications like
e.g. image and PDF viewers, where the users expects support for
ICC-profiles in images, pdf files and other data.
Especially in the tablet market, we have a growing group of professional
users like e.g. photographers, people in medical imaging, graphic
designers doing presentations at customer sides....
2.ICC profiles are effectively user-supplied, binary, meta data which is an
absolute negative security issue on a mobile network. The reason that phone
applications are so carefully screened and the development environments are
so tightly bound to the OS is the fundamental security issue. An
application CANNOT BE ALLOWED to bring down a phone, hence they will be
restricted to very carefully controlled application memory space. I
seriously doubt that user supplied profiles will ever be used at the highest
level in a mobile device. At best, it will be application based. An app on
a phone is far more restricted than an application on the desktop. The
browser issue is more complex because it should run seamlessly in both
worlds.
Firstly, the device itself should be delivered with a cannend display
ICC-profile and the OS should deliver a framework, that Apps can use the
canned display ICC-profile. The current problem is, that such basic
things are not available for iOS and Android.
If the App for creating and configuring an individual display
ICC-profile is certified e.g. through Apple and available through the
iTunes Store, I don´t see any security issues.
If people in the professional imaging area already have an instrument
and software for profiling their desktop environment, they probably
would buy an App to profile their iPad, if they have the need for
accurate colors.
3. For traditional color management to work, there must be a source and a
destination defined BEFORE RENDERING. The question of untagged (source
unknown) has generally been defined to be sRGB. If that assumption is
followed in the system, a very good rendering of sRGB to display can be done
with a relatively simple transformation. The fact is that nearly all mobile
devices do this in the hardware pipeline. The need to accommodate a wide
range of display technologies is well understood and graphics engine
designers have various color correction hardware built into the chip. From
the standpoint of the mobile designer, they already have done "color
management" and the fact that you can't see it or change it is of no
consequence to them. If you render the image to sRGB, leave it untagged,
there will be no major surprises, unless something stupid happens in the
upload process.
What about digital images having AdobeRGB embedded and shared between
desktop, mobile device and the cloud ?
4. I cannot understand how a photographer would allow some alien device,
with unknown rendering characteristics, perform color management on the
image. Given that the trend is towards lower gamut, high luminance
displays, it is very likely that the output after late binding color
management will clip, in relative colorimetric mode. If the manufacturer
decides on a perceptual rendering, then the color you see will be very much
determined by the taste of the platform vendor, not you the photographer.
In any instance, the result that the end user sees, will not be the image
the photographer saw.
If an mobile device with hardcoded "sRGB-to-display-transformation"
ignores an embedded AdobeRGB profile in images, we have a very strange
form of gamut mapping. At least such images should be rendered from
AdobeRGB to sRGB before rendered to the display.
Jan-Peter