Re: NSImage with multiple representation sizes
On Tue, Sep 8, 2009 at 10:30 AM, Benjamin Rister bdris...@gmail.com wrote: 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 9x...@72dpi, 16x1...@72dpi, 32x3...@72dpi: - This is an entirely supported configuration, despite what man tiffutil says and the warning it generates. No, these reps would not have the same -size. If you set the DPI metadata for the reps to 72, 128, and 256 respectively, then each rep would have -size 9x9. This is what I meant above. It's fine to have different pixel sizes, but it's best to set the metadata so that the -size is consistent. - 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 32x3...@72dpi rep to fill a 16x16pt space at scale 2.0, even though the 16x1...@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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSImage with multiple representation sizes
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 9x...@72dpi, 16x1...@72dpi, 32x3...@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 32x3...@72dpi rep to fill a 16x16pt space at scale 2.0, even though the 16x1...@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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSImage with multiple representation sizes
So to be clear: if I create a TIFF image, with tiffutil -cat, that has 9x...@72dpi, 16x1...@72dpi, 32x3...@72dpi: - This is an entirely supported configuration, despite what man tiffutil says and the warning it generates. No, these reps would not have the same -size. If you set the DPI metadata for the reps to 72, 128, and 256 respectively, then each rep would have -size 9x9. This is what I meant above. It's fine to have different pixel sizes, but it's best to set the metadata so that the -size is consistent. Okay, take 2 then. If I do the same thing, with 9x...@72dpi, 16x1...@128dpi, and 32x3...@256dpi (so the tiffutil warning isn't applicable anymore), will NSImage correctly use the more detailed image when drawing into a 16x16pt space? As I mentioned, Cocoa Drawing Guide Images How an Image Representation Is Chosen gives rules to be applied in the order of color space, dpi, bit depth. All have the same color space, the 9x...@72dpi matches dpi (when at 1.0 scale factor) and the others don't, so according to the docs it's the one that would be chosen, with poor results. Best, Benjamin Rister ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSImage with multiple representation sizes
On Tue, Sep 8, 2009 at 11:42 AM, Benjamin Rister bdris...@gmail.com wrote: So to be clear: if I create a TIFF image, with tiffutil -cat, that has 9x...@72dpi, 16x1...@72dpi, 32x3...@72dpi: - This is an entirely supported configuration, despite what man tiffutil says and the warning it generates. No, these reps would not have the same -size. If you set the DPI metadata for the reps to 72, 128, and 256 respectively, then each rep would have -size 9x9. This is what I meant above. It's fine to have different pixel sizes, but it's best to set the metadata so that the -size is consistent. Okay, take 2 then. If I do the same thing, with 9x...@72dpi, 16x1...@128dpi, and 32x3...@256dpi (so the tiffutil warning isn't applicable anymore), will NSImage correctly use the more detailed image when drawing into a 16x16pt space? As I mentioned, Cocoa Drawing Guide Images How an Image Representation Is Chosen gives rules to be applied in the order of color space, dpi, bit depth. All have the same color space, the 9x...@72dpi matches dpi (when at 1.0 scale factor) and the others don't, so according to the docs it's the one that would be chosen, with poor results. On 10.6 and later, yes, you can count on it choosing 16x16 pixel representation. We're not looking at resolution anymore, only number of pixels in rep vs number of pixels to be filled. I'm pretty sure it would on previous OSes too, but not 100% positive. -Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSImage with multiple representation sizes
On 09/09/2009, at 6:20 AM, Ken Ferry wrote: On 10.6 and later, yes, you can count on it choosing 16x16 pixel representation. We're not looking at resolution anymore, only number of pixels in rep vs number of pixels to be filled. I'm pretty sure it would on previous OSes too, but not 100% positive. It works this way on 10.5. It's easy to test, dump a multi-resolution TIFF into an NSImageView set to resize with the window and scale the window up and down. If the TIFF contains different images at each resolution (say the number 16 for a 16x16px rep, and the number 128 for a 128x128px rep) then you'll see the various representations drawn as you resize. -- Rob Keniger ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSImage with multiple representation sizes
(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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSImage with multiple representation sizes
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 bdris...@gmail.com 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com This email sent to kenfe...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSImage with multiple representation sizes
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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
