Re: Profile compression
Re: Profile compression
- Subject: Re: Profile compression
- From: Tom Beckenham <email@hidden>
- Date: Sat, 04 Mar 2006 20:55:00 +1100
- Organization: Quickcut Adstream
Hi Chris,
Firstly, I can't believe I missed the URL Profile Specification in the
PDF/X-5 spec! I'd actually read through the two specs but somehow missed
it. I have actually been working on getting an Australian PDF/X
technical committee together, so we can give input into future specs.
Big oops on missing that one!
Wasn't sure whether PDF/X-5 can be spoken about publicly yet, but yeah,
the format they have for URL based Output Intents is great! I was very
glad to see it included, and especially glad there was a separate level
for PDF/X-5 that allowed partial profiles, but complete graphic content.
Glad it includes an MD5, plus other parts of what would be in a profile
header such as data colour space, ICC version, and the profile
description. This will be awesome for file exchange.
I think there's still more that could be done by the ICC in defining a
profile format that can be efficiently used by remote users. There are a
couple of things I can think of that could extend this idea further.
What about being able to reference the tags/tables as separate URL
referencable files? This way a CMM could download only the pieces of a
profile it needs. Instead of the tag table including offsets, it could
include URLs. That way when doing a perceptual conversion for example,
you'd only download the perceptual table you need.
It would be nice if this was done in a standardised way. We could always
do this ourselves in software, and dynamically build profiles on the
fly, but then nothing else would be able to use those profiles. If it
was built into CMMs or into the system, then all applications using
ColorSync for example could take advantage of it.
Of course, there are problems with this idea as some CMS's require just
about all the tables. Adobe's Black Point Compensation requires both the
perceptual and relative tables plus both forwards and backwards versions
of those (according to the document on color.org that is).
Thoughts?
Tom
Chris Murphy wrote:
On Mar 1, 2006, at 4:27 PM, Phil Green wrote:
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.
The main task of the ICC is defining a file format. A bodiless profile
is a different format that currently isn't in the specification. I
don't know of any profile vendors that build such profiles. If
everyone has the URL in a different location in this new kind of
profile, via different implementations, the interoperability is going
to be zero.
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-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
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
_______________________________________________
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