• 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: NSImage with multiple representation sizes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSImage with multiple representation sizes


  • Subject: Re: NSImage with multiple representation sizes
  • From: Benjamin Rister <email@hidden>
  • Date: Tue, 8 Sep 2009 13:30:48 -0400

Hi Ken,

Thanks for your response.

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.


I'm not concerned/confused about the results of -[NSImage size], I know it'll draw wherever I ask it to in whatever space that is.

The -size is unrelated to the number of pixels in a rep. The ratio determines resolution. Reps can definitely have different numbers of pixels.


The issue/question comes from tiffutil's explicit warning that NSImage doesn't like it or may be confused if the net sizes of the different representations in the tiff are different. So the reps can have different numbers of pixels, but if the dpi is the same across the different reps, they have different "real sizes," and man tiffutil says that that is a problem.

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.

man tiffutil says that NSImage may not be able to "successfully choose the right size image out of the generated TIFF file." That sounds much stronger to me than encouraging it so that -size isn't potentially confusing to a programmer calling it.


I'm not questioning whether what you say about the frameworks is true, just making sure we're on the same page, because you said the doc says one thing and that's not what I read in it. =)

So to be clear: if I create a TIFF image, with tiffutil -cat, that has 9x9px@72dpi, 16x16px@72dpi, 32x32px@72dpi:
- This is an entirely supported configuration, despite what man tiffutil says and the warning it generates.
- NSImage will correctly choose and draw representations now and in the future when drawn at different sizes, and both at 1.0 and non-1.0 scale factors. For instance, it will use the 32x32px@72dpi rep to fill a 16x16pt space at scale 2.0, even though the 16x16px@72dpi is the one that matches the physical size, despite the NSImage docs only giving rules based on color space, dpi, and bit depth for choosing representations.


Is this correct, and something I can safely rely upon?

Thanks,
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


  • Follow-Ups:
    • NSURLDownload delegate methods seperate thread
      • From: Colin Deasy <email@hidden>
    • Re: NSImage with multiple representation sizes
      • From: Ken Ferry <email@hidden>
References: 
 >NSImage with multiple representation sizes (From: Benjamin Rister <email@hidden>)
 >Re: NSImage with multiple representation sizes (From: Ken Ferry <email@hidden>)

  • Prev by Date: Re: KVO on Distributed Objects with exception handling.
  • Next by Date: NSTextView resizeability and scrolling
  • Previous by thread: Re: NSImage with multiple representation sizes
  • Next by thread: Re: NSImage with multiple representation sizes
  • Index(es):
    • Date
    • Thread