I want to convert some animated PNG (APNG) images to animated GIF. I can successfully convert with a utility I found on the web called apng2gif. Expertly named if I may say. The problem is it does not convert the images with sufficient color depth so the output is a little bit to pixelated and not so smooth relative to the original.
Does anyone know of any other image converters that might convert APNG to GIF with more that 16 bit color depth?
The problem is not with the converter, but with GIF format itself:
http://en.wikipedia.org/wiki/Graphics_Interchange_Format
The format supports up to 8 bits per pixel thus allowing a single image to reference a palette of up to 256 distinct colors.
If you need the GIF to blend better with the background, click on Settings button in apng2gif and then choose the background color you want.
Related
How can I convert PNG to GIF keeping the transparency?
I would have hoped that using the Assign( ) method would work but it doesn't seem to migrate transparency. In the GIF, it's represented as black.
png:=TPngImage.Create;
try
png.LoadFromFile(sFile);
// comes from file: png.TransparencyMode;
// comes from file: png.Transparent
// didn't help: gif.Transparent:=true;
gif.Assign(png);
// didn't help: gif.Transparent:=true;
gif.SaveToFile('e:\tmp\out.gif');
finally
png.Free;
end;
I haven't found a way to handle this in Delphi...
thanks!
It is possible to transfer an image from a PNG to a GIF. However, I don't recommend that you do so. The GIF format is substantially less capable than PNG. PNG supports RGBA color channels and partial transparency. GIF uses a 256 color palette and no support for partial transparency.
There are many libraries available that will make the best of a bad job and attempt to produce a GIF image that is close to the PNG image, but information will be lost.
The GIF format dates from the late 1980s and time has moved on. It has long since served its purpose. PNG is modern, capable and well supported. If it is possible to do so you should switch from GIF to using PNG.
Seems like CMFCToolBar Allowing only BITMAP Images ( which are of color depth 24 ) to place on Buttons. How to get rid of this limitation. i am neither able to place a PNG nor a bit map with color depth 32 (alpha channel included).
i tried attaching my CPngImage to CBitmap but didn't work.
CPngImage image;
image.Load(AfxGetInstanceHandle(), IDB_PNG1);
bitmap.Attach(image.Detach());
so, finally my doubt can we add a PNG/ Bitmap with alpha channel to CMFCToolBar Button as Image?
Does this work: Icons on menus of MFC Feature Pack classes ? You'd probably have to adapt it a bit to get it to work in your specific case. I'd suggest staying away from using PNG for toolbar icons etc; you can use AlphaConv (google a bit to find it - it moves around a bit it seems) to convert from png to 32 bit bmp.
In my app, I convert and process images.
from colour to greyscale, then doing operations such as histogram-equalisation, filtering, etc.
that part works fine.
my UIImage display correctly, I also save them to jpeg files and it works.
The only problem is that, although my images are now greyscales, they are still saved as RGB jpegs. that is the red, green and blue value for each pixel are the same but it still waste space to keep the duplicated value, making the file size higher than it could be.
So when i open the image file in photoshop, it is black & white but when I check "Photoshop > Image > Mode", it still says "RGB" instead of "Greyscale".
Anyone know how to tell iOS that the UIImageJPEGRepresentation call should create data with one channel per pixel instead of 4?
Thanks in advance.
You should do an explicit conversion of your image using CGColorSpaceCreateDeviceGray() as color space which is 8 bits per component, 1 channel.
I need to edit a png image,by giving it border and drop shadow effect. But the final size of the edited image is too high to use for a mobile app .I know that size of jpeg is less compared to that of png.So i convert that image to jpeg and tried to give drop shadow and border effect.But that image is not having transparent background..Is their any other methods to accomplish this using jpeg?
Another option is to try either ImageOptim for losseless compression, or its lossy cousin, ImageAlpha.
ImageOptim tries a series of lossless algorithms to shrink a PNG and selects the smallest result of the bunch. It has taken 25% to 50%+ of quite a few of our images.
ImageAlpha, on the other hand, is lossy and can further crunch the image, with results more like JPEG but without losing Alpha.
You would also do well to disable PNG compression in Xcode as shown here, with additional details here.
What #minitech wanted to say is not about scaling, it's about file compression. jpg and png files usually have some data that could be removed from the file. There are some compression methods to reduce file size (note that is size in kbs, not in scale measurement). Jpg images can reduce file size by reducing image quality, too.
If you want another file type that accepts transparency, there are the gif format, which gives you a smaller file, but have some drawbacks, like a lack of alpha channel (variable transparency). Check this link for more details: http://www.w3.org/QA/Tips/png-gif
There are a couple of online file compressors. If you want to compress png files, you could try using http://tinypng.org/
No, jpeg image wont support transparency.But you can change the white background coming along with jpeg image
I am able to use PNGs that have drop shadows but the effect when displayed on the BlackBerry looks like it collapses the transparent channel down from its original smooth gradient to only several transparent values giving it a choppy look.
The same issue is encountered by drawing on the UI using BlackBerry fields or the graphics.drawBitmap method. Anyone want to share hints for getting great looking transparent effects on the BlackBerry?
Dither your images or pre-composite them. When loading an image on a BlackBerry, you get at most 4 bits of alpha data, which allows 4 bits each for RGB. So, if you want to dither your transparent images, go for RGB4444. If you don't dither them, that's what causes 8-bit alpha to just be mapped to the nearest 4-bit value.
If you include no alpha data (i.e., precomposite), you can get RGB565, which will have a better image quality overall, but you will have to deal with static positioning for your dropshadows.