We are using tycho v0.13 and maven 3.0 for building our product.
We get the following error/warning when building
Error - 7 icon not replaced in C:\Users\AppData\Local\Temp\p2.brandingIron7115583353836584113\launcher.exe using D:\Builds\workspace\plugins\icons\app-icon.ico
the ico files are all proper.
as a result window icons are being replaced by the standard eclipse icons.
I'm not overly familiar with Tycho itself, but here I believe it is using the branding code that ships with p2 (and which originally came from PDE/Build).
The code extracts the icon images from the originating launcher executable and searchs for matching images in the provided ico file. If an image is found that matches the size and bit-depth exactly, then that image is replaced. There are 7 images embedded in the launcher and the provided ico should provide images that match those in size and bit-depth.
The error message indicates that 7 of the icons found in the executable did not have matching sizes/bit-depths in the provided ico file.
The launcher that shipped in 3.7.2 contains the following sizes (order does not matter):
48x48 8 bit (256 colors)
32x32 8 bit
24x24 8 bit
16x16 8 bit
48x48 32 bit (RGB + Alpha)
32x32 32 bit
16x16 32 bit
The launcher that is shipping in 4.2 (3.8) contains the following sizes:
256x256, 32 bit (RGB / Alpha Channel)
48x48, 32 bit (RGB / Alpha Channel)
32x32, 32 bit (RGB / Alpha Channel)
16x16, 32 bit (RGB / Alpha Channel)
48x48, 8 bit (256 colors)
32x32, 8 bit (256 colors)
16x16, 8 bit (256 colors)
We had some frustrating moments where we got the error about missing icons, so I decided to dig into it.
Below are my findings… basically adding extra information to Andrew Niefer's answer.
For Windows, the process of replacing the images in the native launcher is described below. The processing is done by p2 class: org.eclipse.pde.internal.swt.tools.IconExe
This class looks at the resources of native launcher and notes the bitmaps that are in there: their sizes and their color depth.
Then it looks at the provided images. This can be a list of separate BPMs or an ICO file containing multiple BMPs. Their sizes and color depths are also noted.
This only works when all provided images are uncompressed. When one or more of the images is compressed, the process stops and no bitmaps are replaced in the native launcher.
Next it tries to match the provided BMP sizes and color depths to the ones in the native launcher and where they match, they are replaced in the native launcher.
When one or more bitmaps in the native launcher are not available in the provided images, the following message is written to System.err:
Error - <n> icon(s) not replaced in […]using […]
The class IconExe has a main method and can be run as stand-alone. Its first argument is the native launcher that needs to be modified and the following arguments are the provided BPM or ICO files.
For Eclipse 4.3(.x), the native launcher contains 7 bitmaps:
256x256, 32 bit (RGB / Alpha Channel)
48x48, 32 bit (RGB / Alpha Channel)
32x32, 32 bit (RGB / Alpha Channel)
16x16, 32 bit (RGB / Alpha Channel)
48x48, 8 bit (256 colors)
32x32, 8 bit (256 colors)
16x16, 8 bit (256 colors)
So, for the process of replacing the images to be successful, 7 images with the same size and depth need to be provided, either as separate BMPs or inside an ICO.
However, when using the tycho-p2-publisher-plugin, you cannot provide 7 separate BPMs, since the tycho-p2-publisher-plugin is not aware of the 256x256x32 image when it is specified in the .product file.
Its class org.eclipse.tycho.model.Launcher only reads the other 6 image locations from the .product file and hence, the 7th image (the 256x256x32 one) is skipped.
Therefore, the list that IconExe gets is one image short and will always report:
Error - 1 icon(s) not replaced in […]using […]
The solution that worked for us was to combine the 7 BMPs into one ICO file and provide that in the .product file.
But note that some image manipulation applications, that can create ICO files, tend to compress the 256x256x32 image by default. This is what got us on the wrong foot!
So be careful that all images in the ICO file are uncompressed.
I had a similar problems with 3.7.2 when my ICO file contained
higher resolution images such as 512x512
some images were compressed.
I deleted the unused layers from my ICO file using Gimp.
Just to add to previous answers:
All of the images in the .ico file should be BMP format, not PNG. I've seen at least two utilities that wanted to use the PNG format for one or more of the images.
If you are targeting Eclipse 4.2 then you will have to wait for Tycho 0.16.0 (or use the SNAPSHOT version already available) to get a version that includes the latest IconExe that copes with 256x256 bitmaps. If your .ico file contains one of these then it causes a read error in the old IconExe and none of your icons get replaced (and you get the error as seen in the opening message). See https://bugs.eclipse.org/bugs/show_bug.cgi?id=384509.
Related
I added 33 mb worth of sprite assets (they are large character illustrations), so I would expect the data folder to increase proportionally. However, the size actually increases by 2 GB (6000% increase!) increasing total data size by over 500% too.
Doesn't make any sense to me. Is there a mistake with my import options? I use mip maps, bilinear/trilinear filters. Truecolor/ vs compressed doesn't change anything.
Additional info: It's like 10 files with 5-8 large sprites each. Another weird thing is that when it's compressed to a zip file the size collapses to 142mb (from like 2.3 GB). Which is weird because that's too big of a difference.
It's also very slow to start.
I believe this is related to how unity handles image compression. The assets live in your project in compressed (jpg/png) form, but they get recompressed (or not) to a form thats fastest to decode on the target platform. Try playing with the compession settings with the asset import settings (available if you highlight your asset in the project window)
There are a few reasons why file sizes can get so big.
As #zambari said, PNG/JPEG are compressed forms, which compress much better than what unity will. Due to that, you have to be careful with your file sizes, since they will be much bigger in-game.
Another issue I had was that my files weren't sized properly. The compression method that I was trying to utilize requires file sizes divisible by 4 (DTX5).
Another big issue was I had large images that I did not need. I used "generate mip-maps" + trilinear filtering, and that once again doubled the file sizes. The best thing you can do is just use image sizes that reflect their use. Relying on Unity to do that for you by using max image size does not guarantee good quality (in fact it looked terrible). This was all in Unity 5
The image at the end of this question is a PNG with mode I, which stands for Indexed, as far as I can tell.
I'm trying to create a thumbnail out of it, and save it as JPG with PIL.
However, is I leave the mode alone, PIL won't let me resize it with error unable to generate thumbnail: cannot write mode I as JPEG.
If I convert it to RGB, the result will be a fully white image.
Is there a way to fix this?
https://www.dropbox.com/s/2d1edk2iu4ixk25/NGC281.png
The input image is a 16-bit grayscale PNG, and it appears PIL has a problem with this. Manually converting it to an 8-bit image before further processing makes it work again.
The problem may originate inside PIL itself. The PyPNG homepage asserts
..PIL only has internal representations (PIL mode) for 1-bit and 8-bit channel values. This makes me wonder if PIL can read PNG files with bit depth 2 or 4 (greyscale or palette), and also bit depth 16 (which PNG supports for greyscale and RGB images).
Then again, that page is from 2009. It could be worth tracking down where PIL is maintained from, and report this as a bug (? Or possibly a feature request?).
I 'd like to prepare my PNGs for the best optimization, so I can get the best image quality (lossless if possible) and the smallest size.
From what I understand, I should use: PNG, 72 dpi, RGB, but what else?
Here is what we find in the iPhone HIG:
Note:*The standard bit depth for icons and images is 24 bits (8 bits each for red, green, and blue), plus an 8-bit alpha channel. The PNG format is recommended, because it preserves color depth and supports an embedded alpha channel.
I guess this mean we should save the image as PNG 24 and create them in 8 bits mode? But I also read about 32 bits for best quality ?
The interlacing scheme (witch add to the file size) allows for the PNGs to display faster. Does this applies to the iPhone?
Thanks.
I suggest using ImageAlpha (lossy) on as many images as you can, because it greatly reduces their size.
Optimize all images with ImageOptim — it will remove all invisible junk and re-compress the data.
Disable Xcode conversion, because it undoes other optimisations and can make images much slower to load.
24 bit is red, green and blue with 8 bits each. 32 bits is RGB plus an 8-bit alpha channel. So if you need (semi-)transparent images, you should go for 32bit PNG, otherwise 24bit.
You don't have to compress/crush the PNGs yourself, Xcode's build steps will automatically use pngcrush and re-order the color channels for the iPhone's BGR memory alignment.
For my background app I am using JPEG (Export for web in photoshop) with quality 70.
Last day I heard about pngcrunch, tried it but file size is the same...
http://pmt.sourceforge.net/pngcrush/
Take a look at this previous post :
Understanding 24 bit PNG generated with Photoshop
A 24 bit .png file with transparency, as those that can be generated with Photoshop, has really 24 bits distributed across each color plus the alpha ? or the 24 bit refer only to the colors and ignores the alpha (RGBA 8888).
Is there any tool to examine a PNG file and verify this kind of information? Does Photoshop have any options to verify or configure this?
24 bit + alpha is actually 32 bits per pixel. Meaning you have the Red, Green, Blue and Alpha channels, each being 8 bit, allowing for 256 shades per channel translating to 256 x 256 x 256 x 256 possible colour combinations. That's what the "millions of colours" and "billions of colours" mean in certain graphics and video software.
As I understand it, there are three kinds of "24 bit" pngs:
24 bits with no transparency. No alpha information, truly 24 bits per pixel.
24 bits per pixel with alpha transparency. This would be 24 bits of color information with 8 bits of alpha (allows for various levels of transparency) - 32 bits per pixel total.
24 bits per pixel with binary transparency. This would be 24 bits of color information with 1 bit of alpha (transparent or not transparent) - 25 bits per pixel total.
24 bit PNG doesn't say much. An image has a pixel format. The pixel format describes the Colorspace used (such as CMYK, RGB) and bits per channel information (i.e. how many bits are allocated to represent each channel of the colorspace in use).
Go to File > File Info > Advanced. That should tell you what you are looking for.
After dissecting the exported file myself (from Photoshop CS6), I found that the "24 bit" file generated by Photoshop is actually still 8 bit. The RGBA is still one byte per channel. The IHDR PNG chunk still says that it's 8 bits per channel.
It's an 8 bit PNG.
The exported PNG also contains about 825 bytes of useless marketing text data (per PNG image).
See the image (with the byte for "bits per channel" selected):
See the specification for more details:
http://www.libpng.org/pub/png/spec/1.2/png-1.2.pdf
CGBitmapContextCreate takes an parameter that's not very obvious to me:
For example, for a 32-bit pixel format
and an RGB color space, you would
specify a value of 8 bits per
component.
I have created 24-bit PNG files with alphatransparency, and added them to Xcode. At compile time, Xcode optimizes those PNG tiles with pngcrunch.
So, when trying to make an graphics context out of such an image file on iPhone-OS, I need to specify the bits per component.
In this case, I would say they're 4 bits per component, although I dont know if alpha counts as an component.
It's 8 bits per component:
Red:8;
Green:8;
Blue:8;
Alpha:8;
That adds up to 32 bits per pixel. Your 24-bit png with transparency is 24-bits for RGB, plus 8 bits for transparency (the 'alpha channel').