Re: Bitmaps, colorspaces, etc.
Re: Bitmaps, colorspaces, etc.
- Subject: Re: Bitmaps, colorspaces, etc.
- From: Aandi Inston <email@hidden>
- Date: Mon, 21 Dec 2015 09:55:05 +0000
I don't know anything about these methods. But in colour space work,
"retagging" would usually mean changing the attached colour profile without
changing the pixel values.
For example, if an image starts as AppleRGB, it could be tagged as sRGB.
This is not a conversion. The pixel values, numbers, are unchanged. So the
meaning of the pixel values, now interpreted as sRGB rather than AppleRGB,
would change, and the colour would shift. At a push "retagging" an untagged
image would give a specific meaning to the pixels rather than a
default/device dependent meaning.
So (pure speculation) maybe creating as CalRGB would create it with some
unknown/default profile and you can later tag it. That would imply that the
main job of colorSpaceName is to deliver information on the number of
components, rather than how to colour map.
On 21 December 2015 at 01:15, Graham Cox <email@hidden> wrote:
> I’m trying to understand how properly to use colorspaces with bitmaps.
>
> In my app’s Export function, we’d like to offer the ability to choose a
> colorspace for the exported image, in whatever format the user chose. My
> thoughts were to use NSBitmapImageRep to capture the image, then use its
> -representationUsingType:properties: method to get the image data in
> whatever format before writing it to disk. So far so good.
>
> NSBitmapImageRep accepts a ‘colorspaceName’ parameter when it’s created,
> and these can be one of the following:
>
> • NSCalibratedWhiteColorSpace
> • NSCalibratedBlackColorSpace
> • NSCalibratedRGBColorSpace
> • NSDeviceWhiteColorSpace
> • NSDeviceBlackColorSpace
> • NSDeviceRGBColorSpace
> • NSDeviceCMYKColorSpace
> • NSNamedColorSpace
> • NSCustomColorSpace
>
> Which are all strings, and seem to represent a very generic non-specific
> kind of colorspace.
>
> These don’t match with the colorspaces known to the system as returned by
> +[NSColorSpace availableColorSpacesWithModel:], which returns an array of
> NSColorSpace objects, each of which is able to return a -localizedName
> property, which are very specific, and do not relate to the above names at
> all.
>
> How do I bridge this impedance mismatch? If the user wants to Export using
> a specific, named colorspace, as chosen for example from a list of the
> colorspaces returned by the +availableColorSpaces method, how should I go
> about creating the appropriate bitmap? I see that NSBitmapImageRep has
> methods such as -bitmapImageRepByRetaggingWithColorspace: and
> -bitmapImageRepByConvertingToColorSpace:renderingIntent:
>
> What does ‘retagging’ mean? Presumably converting duplicates the bitmap,
> so could be a memory strain. This seems unnecessary if I could create the
> bitmap with a specific colorspace in the first place.
>
> Also, when creating a bitmap, what does using ‘NSNamedColorspace’ do?
> Which named colorspace? What about ‘NSCustomColorSpace’? These seem only to
> indicate what general kind of colorspace to expect, not a specific one.
>
> The problem here is that I can find no documentation that goes anywhere
> near explaining this. Maybe NSBitmapImageRep is too high level and I need
> to drop down to CGImageRef? That class does seem to take a specific
> CGColorSpace object, though how I get there from +[NSColorSpace
> availableColorSpecs] is unclear.
>
> Am I even asking sensible questions? This sort of impedance mismatch
> usually suggests a conceptual misunderstanding somewhere, but without a
> clear explanation of how colorspaces and bitmaps are used, I can’t see
> where I may have gone wrong.
>
> Anyone able to illuminate?
>
> —Graham
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden