I heard that only premultiplied alpha is needed when doing layer blending etc. How do I know if my original image is premultiplied alpha?
You can't.
The only thing that you can check is if it's not premultiplied. To do it go over all the pixels and see if there is a color-value that has a higher value than the alpha would permit if(max(col.r,col.g,col.b) > 255*alpha)//not premul. Any other cases are ambiguous and could or could not be premultiplied. Your best guess is probably to assume that they aren't as that's the case for most PNGs.
Edit: actually, not even the code that I posted would work as there are a lot of PNGs out there with white matte, so the image would have to include parts that have an alpha of 0 to determine the matte color first.
Android Bitmap stores images loaded from PNG with premultiplied alpha. You can't get non-premultiplied original colours from it in usual way.
In order to load images without RGB channels being premultiplied I have to use 3rd party PNGDecoder from here: http://twl.l33tlabs.org/#downloads
Related
I would like to combine two images that partially contain content and otherwise are transparent (alpha = 0). Where the content of the two images overlaps I would like to use half the color value (alpha=0.5) from the first image combined with half the color value of the other image. All pixels that still does not contain content should be transparent. I can't seem to find a convenient way to do this using Core Graphics or Core Image or maybe I am missing something... Does anyone have any tips on how to do this?
If anyone else encounters this problem:
I was able to solve it by using pixel wise processing inspired by this answer https://stackoverflow.com/a/31661519/3652610
and alpha blending described here https://stackoverflow.com/a/727339
I have a large number of PSD files which contain semi-transparent layers. These layers are not getting flattened correctly regardless of what flags I use via convert or mogrify
The simplest form looks as follows:
convert -background transparent source.psd -flatten output.png
Here is what the source image looks like in Photoshop. Note that this is a drop shadow layer and not a layer effect:
Here is how it comes out:
This may not be obvious from the photoshop background, so here it is in laid over a grey background:
Source:
Output:
EDIT:
I dug a bit into what is happening in the numbers. For the initial source image, the shadow is completely black and the alpha fades in. For the output image, the alpha is not as high, but it compensates by inaccurately lightening the image in a somewhat bumpy fashion. Its almost as if its pre-multiplied, but its taking the background as white?
Here is a strait RGB render without alpha multiplied in:
Source:
Output:
In other words, the RBG values are not at all being preserved. Alpha is being dimmed, but not distorted as theses values are. My guess would be some sort of rounding error based on trying to extrapolate the color from the alpha as though it is trying to "unpre-multiply" the values. Any help is appreciated.
Short answer is it is fixed in V7 of the software (I think). I run mac and the installer for V7 doesn't work well at all and it appears unstable. After running it on an Ubuntu VM, it works good. I have also confirmed with another user that V6 has this problem and V7 does not on Windows
How can I set a transparent background on JPEG image? This is a doubt of many colleagues of mine.
What would be the solution using Paint on Windows?
What are the other simple alternatives?
You can't make a JPEG image transparent. You should use a format that allows transparency, like GIF or PNG.
Paint will open these files, but AFAIK it'll erase transparency if you edit the file. Use some other application like Paint.NET (it's free).
Edit: since other people have mentioned it: you can convert JPEG images into PNG, in any editor that's capable of working with both types.
If you’re concerned about the file size of a PNG, you can use an SVG mask to create a transparent JPEG. Here is an example I put together.
JPEG can't support transparency because it uses RGB color space. If you want transparency use a format that supports alpha values. Example PNG is an image format that uses RGBA color space where (r = red, g = green, b = blue, a = alpha value). Alpha value is used as an opacity measure, 0% is fully transparent and 100% is completely opaque. pixel.
JPG does not support a transparent background, you can easily convert it to a PNG which does support a transparent background by opening it in near any photo editor and save it as a.PNG
How can I set a transparent background on JPEG image?
If you intend to keep the image as a JPEG then you can't. As others have suggested, convert it to PNG and add an alpha channel.
JPG doesn't support transparency
Just wanted to add that GIF "transparency" is more like missing pixels. If you use GIF then you will see jagged edges where the background and the rest of the image meet. Using PNG, you can smoothly "composite" images together, which is what you really want. Plus PNG supports highly quality images.
Don't use "Paint". There are many high quality art applications for doing art work. I think even the cell phone apps (Pixlr is pretty good and free!) and web-based image editting apps are better. I use Gimp - free for all platforms.
While a JPEG can't be made transparent in and of itself, if your goal is to reduce the size of very large image areas for the web that need to contain transparent image areas, then there is a solution. It's a bit too complicated to post details, but Google it. Basically, you create your image with transparency and then split out the alpha channel (Gimp can do this easily) as a simple 8-bit greyscale PNG. Then you export the color data as a JPG. Now your web page uses a CANVAS tag to load the JPG as image data and applies the 8-bit greyscale PNG as the Canvas's alpha channel. The browser's Canvas does the work of making the image transparent. The JPEG stores the color info (better compressed than PNG) and the PNG is reduced to 8-bit alpha so its considerably smaller. I've saved a few hundred K per image using this technique. A few people have proposed file formats that embed PNG transparency info into a JPEG's extended information fields, but these proposal's don't have wide support as of yet.
I am successfully using the cool FreeImage library to load images in various formats.
Among these, gif and png with transparency information.
After loading the images, I convert them to 32bpp using FreeImage_ConvertToRawBits. With my png images, this works fine and I can retrieve all four Red/Green/Blue/Alpha components with meaningful Alpha values.
With gif images, on the opposite, the Alpha plane remains all 255's, even though FreeImage_IsTransparent says true.
What am I missing ? Is this related to the fact that gifs are palettized ? How do I handle this ?
I found a clear answer by looking at the source code: transparency is not handled when converting a palettized image to 32 bits. The Alpha field is always set to 255.
Anyway, it is quite possible to retrieve transparency from the original palettized bitmap, pixel by pixel, knowing the value of the transparent color (FreeImage_GetTransparentIndex(dib)).
Which format of PNG should I use PNG 8 or PNG 24? Which one is better for a website. I am confused about these. What is main different between PNG 8 and PNG 2?
Png-24. Png-24 has alpha transparency (where Png-8 only has on/off transparency).
Png-8 is indexed. Png-24 is loss-less.
Png-24 is better in almost every way.
http://www.elated.com/articles/understanding-image-formats/
PNG has several modes which can be used. It may contain:
Greyscale
Indexed colour, usually meant by PNG-8
Greayscale with alpha
Truecolour (RGB)
Truecolour with alpha (RGBA), usually meant by PNG-24
Indexed colour is different from the others that it is a palette of maximum 256 colours, from which indexes are used to denote the colour of specific pixels. It can contain transparency via an auxillary chunk. So every pixel is denoted by a byte-wide value or even less if palette isn't that big. If you use truecolour, there will be more data per pixel, depending on whether you use an alpha-channel.
So in a large image indexed colour will save you a lot of data per each pixel. However, if you use more than 256 colours, some colour data will be lost, which is also more probable in a large image. I would advise to save your image in both formats and see if the loss is worth the gain in smaller file size. Though if you are designing your image for normal web site, not for mobile phones, you should better use PNG-24 anyway, since no one will notice the difference in the size.
I would say that it depends on the image you want to store as PNG*, but in case you've doubts, PNG-24 is better: "true color" (8bits per channel), so that the image must not be dithered and don't "loose" "exact" color match, and optionally PNG-32 if with the alpha channel (transparency) too. PNG-8 images are limited (256 colors chosen from a 24bit palette) and allow only for a mask, you can use it e.g. if you convert from a GIF image; if you convert from other "true color" formats, you "loose" "exact" color match as said (the program try to reduce the real number of used colors into only 256 colors, and other tricks to give resemblance with the original). Some style of icons do not need "true colors", they are "described" well by 256 "fixed" colors or less, and so PNG-8 is ok; as said, if you have GIF images as source, go for PNG-8... if you convert from JPG, go for PNG-24; if you create you image by yourself directly "in" PNG, you know if you can "crunch" the result in PNG-8 or not, but if you are not able to evaluate or use tools to evaluate, PNG-24/32 is ok in any case.
I've written article about it: PNG that works, which outlines all major variants of PNG and their trade-offs/compatibility.
In short, use PNG8 (paletted) whenever you can, as it has much smaller file size. You can have full alpha transparency in PNG8 if you use good tools (Photoshop is not good for PNG).