Re: NSImage with multiple representation sizes
Re: NSImage with multiple representation sizes
- Subject: Re: NSImage with multiple representation sizes
- From: Ken Ferry <email@hidden>
- Date: Thu, 3 Sep 2009 11:41:54 -0700
Hi Benjamin,
I think there's some confusion here between size and pixel size.
The "size" of an image is the default size of the rect in which it's drawn
when the person drawing it doesn't have any more specific information.
That's a concept that there can only be one of for the entire image, so
it's confusing if the -size for contained reps doesn't match that of the
image itself.
The -size is unrelated to the number of pixels in a rep. The ratio
determines resolution. Reps can definitely have different numbers of
pixels.
It's pretty common for people to hit cases where they feel like their image
has no intrinsic size it wants to be drawn at. Like, it might be equally
natural at 32x32 vs 128x128. That's okay, it just means you're going to
ignore the size. There still is one, you just don't care what it is.
-size is not used in representation selection. Rep selection is based on
the number of pixels to be filled in the context and the number of pixels in
each candidate rep.
So it's perfectly fine to pack in different representations with different
numbers of pixels. What the docs encourage is setting the metadata so that
the -size of each representation is the same.
-Ken
On Thu, Sep 3, 2009 at 11:00 AM, Benjamin Rister <email@hidden> wrote:
> (Apologies if this ends up a duplicate…I sent the original over a week ago,
> and as far as I can see it's not in either Apple's or Cocoabuilder's
> archives, so I don't see any other explanation besides it just being eaten
> by something.)
>
> The core question:
> Is it still the best practice to have conceptually same images of different
> sizes in different files, e.g. Foo9x9.tiff, Foo32x32.tiff? icns isn't an
> option because they aren't all the standard icns sizes, and several places
> in the docs seem to discourage lumping them together (e.g. with tiffutil)
> anyway.
>
>
> The details:
>
> We have several images that are displayed at different sizes at various
> places in an application. Our artist has generated several bitmaps for
> these different scales. Modeling on the concept of an .icns file, my
> inclination would be to try and lump them all together in one
> multi-representation file and let NSImage figure out what the best
> representation is to draw from at any given point. This not only is
> convenient for the various usages around the app, but also for resolution
> independence (...maybe...see below).
>
> However, man tiffutil says:
>
>> -cat allows combining multiple TIFF files into one. ... If the real sizes
>> (pixel size
>> divided by dpi) of the images being combined are not the same, a
>> warning
>> will be generated. This makes sure that NSImage can successfully
>> choose
>> the right size image out of the generated TIFF file.
>>
>
> And Cocoa Drawing Guide: Images, "How an Image Representation Is Chosen"
> gives rules about color space, dpi, and bit depth, but there's no rule about
> choosing representations based on size. (But there's icns, right? How is
> that supposed to work, then?)
>
> I'm also concerned for resolution independence that the system might not
> choose the 32x32px rep to fill a 16x16pt space at a 2x scale factor, because
> everything I've seen in the resolution independence docs only talks about
> representations with different dpi. It would be rather inelegant to have to
> have multiple representations with the same pixels and just different
> metadata.
>
> So between the resolution independence concern, and the docs seemingly
> discouraging having different sized images in one file, this raises the core
> question above. What's the best way to arrange this for both drawing the
> image at different sizes in different places and resolution independence?
>
> Best,
> Benjamin Rister_______________________________________________
>
> 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