I'm an experienced developer but a relative newbie with Cocoa. The Cocoa documentation says that toolbar items (NSToolbarItem) are 32x32 in regular size and 24x24 in small size. It goes on to say that you can (and should) include an image that includes both sizes and that a multi-page TIFF or an ICNS file can be used. This is where I am confused. I have tried several different programs that create ICNS files but all of them create files including 16x16, 32x32, and bigger. Is the assumption that the 24x24 toolbar icon uses a 16x16 image or is there a way to create a ICNS file with a 24x24 image? Or are people using an application to create multi-page TIFF files?
Use Icon Composer.app and supply the 16 and 32 sizes. The system will automatically up- or down-scale between them as needed and usually does a very good job of it.
Related
After long struggle I managed to generate (using Ant) on MacOSX (Yosemite) a DMG (of modular JavaFX application that deploys to *.app folder) even with custom icons of the app and DMG volume (both stored as *.icns files in build's package/macosx folder). Drag and drop works, it installs the app, the app launches so everything is fine. Well, almost.
I was tempted to make also the custom background for DMG. It is placed together with the icons in package/macosx folder as App-background.png file (where App part is the name of my app, as it is with icons). And javapackager actually picks up the background, but unfortunately after opening DMG the background seems to be placed in windows' top-left corner, the window itself is like twice the size of the background, so 3/4 of the window's background is just white.
I tried with different PNG sizes, but to no avail. DMG window is always way bigger than the image.
Is there any way to make javapackager (aka fx:deploy which I actually use) to generate DMG with proper settings, that just make the DMG window fit background size?
Edit: It seems like DMG window has actually the size of the PNG (the original background file), but for some reason the image, when displayed as background, is "slightly" scaled down.
After long investigation I found the (not so obvious and rather not direct) reason for this misbehavior. Fortunately I found also the solution.
Apparently there's some problem with Finder handling PNG while displaying DMG file. It all comes down to chunk pHYs which contains 3 fields (4b, 4b and 1b long respectively). It is pixels per unit on x axis, pixels per unit on y axis and 0 or 1 for unit (0 no unit, 1 a meter unit). Playing with these values (via hex editor) did change somehow scaling behavior (and window size), but I wasn't able to figure out correct values. Eventually I get rid of this chunk completely (exporting from GIMP as PNG without saving resolution) and that solved the case.
So for anyone struggling with this: just make sure, there is no pHYs chunk in PNG file.
Edit: One can do that easily with ImageMagick:
$ convert image.png -define png:exclude-chunk=pHYs image.png
This strips pHYs chunk from the image.png file.
When I add a multi-resolution-icon file to my Windows application in Visual Studio 2013 it seems Windows and/or VS ignores the resolution and it seems the 32x32x24bit icon is used for the task-bar. My icon file contains the following resolutions: 16x16,32x32,48x48,256x256 with 8-bit and 24-bit each. The application itself is DPI-unaware but expected that an appropriate icon is used though. Ideas?
There are very particular specifications for what formats should be present in your icon resources if you want Windows to use them properly. If you don't follow their recommendations you will get very inconsistent results from your application.
https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx has the guidelines you will want.
Application icons and Control Panel items: The full set includes
16x16, 32x32, 48x48, and 256x256 (code scales between 32 and 256). The .ico file format is required. For Classic Mode, the full set is 16x16,
24x24, 32x32, 48x48 and 64x64.
List item icon options: Use live
thumbnails or file icons of the file type (for example, .doc); full
set.
Toolbar icons: 16x16, 24x24, 32x32. Note that toolbar icons are
always flat, not 3D, even at the 32x32 size.
Dialog and wizard icons:
32x32 and 48x48.
Overlays: Core shell code (for example, a shortcut)
10x10 (for 16x16), 16x16 (for 32x32), 24x24 (for 48x48), 128x128 (for
256x256). Note that some of these are slightly smaller but are close
to this size, depending on shape and optical balance.
Quick Launch
area: Icons will scale down from 48x48 in Alt+Tab dynamic overlays,
but for a more crisp version, add a 40x40 to .ico file.
Balloon icons:
32x32 and 40x40.
Additional sizes: These are useful to have on hand as
resources to make other files (for example, annotations, toolbar
strips, overlays, high dpi, and special cases): 128x128, 96x96, 64x64,
40x40, 24x24, 22x22, 14x14, 10x10, and 8x8. You can use .ico, .png,
.bmp, or other file formats, depending on code in that area.
I have icons (.ico) in my vb6 application. They are of various dimension 16x16 and 32x32.
I want all the icons to be converted to 48x48 256 image format. Can I load a 48x48 icon file (.ico) in a VB6 form?
I want to know if VB6 support any other image format apart from .ico files?
Thanks
VB6 is capable of using icon files (.ico), including icon files with 48x48 pixel icons. I presume you were referring to Icons that can be assigned to forms for the purpose of displaying them on their title bars, in the far top-left corner. This can be done by assigning an Icon file to each form's Icon property during design time; or at run time, usually from either an ImageList control or Resource file (.res). However, with the exception of some Cursor files (.cur), VB6 is not capable of displaying an image for the same purpose, using another file format other than .ico (.bmp, .gif, .jpg, etc. cannot be used).
Icon images can also be used to display images elsewhere on forms, such as through the use of the PictureBox and Image controls.
Please note that there is no need to convert multiple icons to a particular format, as single Icon files (.ico) are capable of storing multiple icons of different dimensions and colour depths. When multiple icons are present within a program's icon resource, Windows Explorer will display the appropriate icon dimension for a particular file / folder view. For example, a 16x16 pixel version of the icon will be shown in "Small Icon", "Details" and "List" views, while a 48x48 pixel version will appear when the view is set to "Medium Icons". When a particular version of an icon is not available, Windows Explorer will usually try to use one of the other versions that is closest to what needs to be displayed for a particular view, which may involve stretching an icon to a larger or smaller size. Pixels of colours not able to be displayed from a high colour (24 bit) icon in a 256 colour mode, will be converted automatically to their closest equivalents, from a default system colour palatte. The disadvantage of the absence of multiple versions of the same icon, is that the quality of the icons will be reduced in particular file / folder views.
I am a bit confused about what the best approach is to resize a JPEG file on disk and save the resized JPEG as a new file to disk (on Mac OS X with Cocoa). There are a number of threads about resizing, but I am wondering what approach to use. Do I need to use Core Graphics for this or is this framework "too much" for a simple operation as a resize? Any pointers are welcome as I am a bit lost.
Core Graphics isn't “too much”; it's the right way to do it.
There is a Cocoa solution:
Create an image of the desired size (the destination image).
Lock focus on it.
Draw the source image into it.
Unlock focus on it.
Export it to desired file format.
Write that data somewhere.
But that destroys metadata.
The Core Graphics solution is not a whole lot different:
Use an image source to load the image and its metadata.
Create a bitmap context of the desired size with the source image's color space. (The hard part here is making sure that the destination context matches the source image as closely as possible while still being in one of the supported pixel formats.)
Draw the source image into it.
Capture the contents of the context.
Use an image destination to write the image and metadata to a file.
And the Core Graphics solution ensures that as little information as possible is lost along the way. (You may want to adjust the DPI metadata, if present.)
Install and use ImageMagick.
I'm trying to load some images using Bitmap.getBitmapResource(), but it takes about 2 or 3 seconds per image to load. I'm testing on the Storm, specifically. The odd thing is, when I install OS 5.0, the loading goes in a snap, no delay at all.
Should I be looking at the format used? Or where the files are stored? I've tried both 24- and 8-bit PNGs, with transparency. The files are stored in a subdirectory in the COD, so getBitmapResource is passed a path, like "images/img1.png" instead of just "img1.png".
Is any of this making things slower?
If you're looking for the most efficient format for storing image data within your application binary, the recommendation is PNG with the 565 colorspace. The BlackBerry Theme Studio toolkit has the ability to load any PNG and export it in this format. Its the best one because its what the BlackBerry uses internally.
Try to use EncodedImage, see Is it better to use Bitmap or EncodedImage in BlackBerry?
In case you need Bitmap class, try also bmp (don't forget to turn off "convert image files to .png" option in BB project settings)