• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: untagged RGB data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: untagged RGB data


  • Subject: Re: untagged RGB data
  • From: Chris Murphy <email@hidden>
  • Date: Sat, 20 Dec 2003 14:52:10 -0700

On Dec 19, 2003, at 10:19 PM, John Zimmerer wrote:
Frankly, not knowing how CMYK was generated has more problems. At least having the profile embedded gives the recipient a shot at knowing whether the file in its current state is appropriate for the given workflow, and also provides a starting point for creating a device link profile (after extracting the embedded profile, of course). The profile isn't to blame for poorly designed workflows.

Anyone sharing CMYK images haphazardly without respect to how they were separated or where they will be printed are asking for problem, period. Embedding a profile does not solve this problem. And given the realities of existing workflows concerning embedded profiles in CMYK images, you're just asking for trouble to do it and then hand off those images to people you haven't had explicit discussions with. Embedded profiles for RGB images communicate color well. Embedded profiles for CMYK images do not, they're insufficient as they're currently designed.

CMYK profiles don't have to be large, they can be 500K or less. Large profiles can be downsampled, unnecessary tags can be stripped. In dealing with files that start at 16-bit then get separated to CMYK, I don't think 500K is too high a price to pay to insure the file is properly treated further down the workflow.

It is too large. 1000 images x 500K = 488MB of redundant data that isn't necessary in the vast majority of existing workflows. And the existence of the embedded profile can actually ensure the file is improperly treated further down the workflow if that image gets repurposed automatically. (This is not an obscure problem, InDesign 2 does it if color management is turned on and the destination profile is different than the embedded profile. And there's no way for this NOT to occur except to turn color management completely off.)

CMYK profiles embedded in images can be a good thing when the destination is a device with perfect register (space concerns notwithstanding).

CMYK profiles embedded in images is asking for trouble when the destination is a device with imperfect register.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management"
Published by PeachPit Press (ISBN 0-201-77340-6)
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: untagged RGB data
      • From: "john c." <email@hidden>
References: 
 >Re: untagged RGB data (From: Roberto Michelena <email@hidden>)
 >Re: untagged RGB data (From: John Zimmerer <email@hidden>)
 >Re: untagged RGB data (From: Chris Murphy <email@hidden>)
 >Re: untagged RGB data (From: John Zimmerer <email@hidden>)
 >Re: untagged RGB data (From: Chris Murphy <email@hidden>)
 >Re: untagged RGB data (From: John Zimmerer <email@hidden>)

  • Prev by Date: Re: Colorsync Architecture
  • Next by Date: Re: ColorSync and printing -- Panther (1 of 2)
  • Previous by thread: Re: untagged RGB data
  • Next by thread: Re: untagged RGB data
  • Index(es):
    • Date
    • Thread