Re: Profile compression
Re: Profile compression
- Subject: Re: Profile compression
- From: Phil Green <email@hidden>
- Date: Wed, 01 Mar 2006 23:27:05 +0000
Hi, Olaf
I understand the need, and I am sure the ICC will discuss any changes in
the profile specification which are required to support it and other
future workflows. However, I don't think you should expect ICC to
standardize all aspects of the approach such as the method you use to
look up a file by its url, or what you do with the information in the
profile. The 'slimmed-down' profile you describe is essentially the
profile header, so any approach is going to start by reading the first
128 bytes of the profile. I think this can be implemented now without
waiting for it to be standardized.
As you know, ICC is working on supporting referenced profiles in
document formats that require it, as in the PDF/X-5 proposal.
Phil
Gudrun Templin wrote:
Hi Phil,
yes, certain things can easily be done today. Nevertheless I would like
to see an approach that is done the same by everyone. If Quickcut does
it one way, and every other vendor in their way, it won't be much fun
for anybody.
There is currently a discussion in ISO TC 130 WG 2 (the 'PDF/X
committee') whether and how to incorporate referenced ICC profiles in
future versions of PDF/X. Nevertheless this will only help for PDF/X
(and maybe PDF in general if Adobe decides to support such an approach
in upcoming PDF specs). What about other document formats? What about
mechanisms to make use of referenced profiles? Wouldn't the OS be a good
place in the long run? How would one go about it to make that happen?
So having a 'slimmed down' flavor of ICC profiles, mostly with reference
info (URL), identification info (MD5), maybe IP info (license, usage
rights) and some core descriptive info (name, color space, type of
profile, filesize ...) to me looks like a very smart thing to ask for.
Olaf Druemmer
email@hidden wrote Wed, 1 Mar 2006 21:45:47 +0000
Chris
There is no reason why you can't reference a profile by url today, and
the ICC certainly anticipates this form of using profiles becoming
increasingly common.
As far as I can see, there is also nothing to stop anyone extracting the
header from a profile and incorporating it into an application or OS for
a purpose such as referencing by url - as long as the usage accords with
the license given by the vendor of the profile creation software. In a
V4 profile, the MD5 checksum from the header could be used to help
ensure the correct file was being referenced.
Phil
Chris Murphy wrote:
Tom,
This is a good example of why the ICC needs to update the specification
to allow for a bodyless profile. Basically it would contain just the
header, and a couple of URLs pointing to the actual profile data which
could then be kept up to date. The implementation of this by the
operating system vendors would involve caching the body of the profile
so that it would first search locally and then if not found there it
would use the URLs in the profile header to locate that data (and then
cache it for future use).
This doesn't solve your problem now, but we really need the ICC to get
on the stick. This has been a big pain point for CMYK based workflows
(among a number of other unrelated things), and I predict it will be a
problem for the larger ICC v4 versions of editing space profiles such
as sRGB and Adobe RGB. The ICC has to figure this out VERY soon, so
that the operating system vendors can implement this in a reasonable
time frame. If they do it now, there is a good chance this could be
implemented in the next major version of the OS's, but if they diddle
around for another year or more on this issue, then it will just be
that much longer.
My suggestion is to go to the ICC web site, www.color.org, and "Ask
Phil" in the upper right hand corner. When can we get header+URL
profiles? What's the time frame? The squeaky wheel gets the oil so I'd
make a point of asking this every few months. Standard time frames for
the ICC are glacial.
I've found binary files to not be very compressible, and that includes
ICC profiles. One way vendors make them smaller is to build them using
a smaller table size, which then compromises their accuracy. Some
vendors assume people won't use them for softproofing, only for B2A
conversions, so they'll put in high quality 33x33x33 matrix tables for
B2A but use much smaller A2B tables to save size, compromising the soft
proof quality.
I haven't tried it, but you might give bzip2 a crack at an ICC profile
and see if they come out any smaller than just zip compression.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40colourspace.demon.co.uk
This email sent to email@hidden
--
Phil Green
Colour Imaging Group
London College of Communication
Elephant and Castle, London SE1 6SB
Tel: +44 020 7514 6759 Fax: +44 020 7514 6772
http://www.digitalcolour.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Phil Green
Colour Imaging Group
London College of Communication
Elephant and Castle, London SE1 6SB
Tel: +44 020 7514 6759 Fax: +44 020 7514 6772
http://www.digitalcolour.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden