Re: proposal: background-image-alpha

On Mon, 08 May 2006 09:09:52 +0300, Andrew Fedoniouk  
<> wrote:

> Hi, Emrah,

Thanks for taking your time to criticise.

> First of all PNG supports 16 bit per channel, so there is also PNG64
> Also it supports for example 16 bit grayscale + 16 bit alpha-channel  
> configuration
> Lets limit ourselves for the second by JPEG, GIF and PNG only.
> The only useful combination here: PNG on background and PNG as alpha.
> Reasons: 1) GIF does not support grayscale (needed to serve alpha mask  
> purpose)
> 2) JPEG is not suitable for alpha mask purpose because of its lossy  
> encoding -
> being combined with another image will create artifacts.
> So the only option is PNG/PNG. Why not use single PNG16/32/64 then?

I don't believe the only option would be PNG/PNG. PNG is suitable for  
certain types of images (straight gradients, typography, logos), while JPG  
is for others, (photographs, images with natural transitions), so a  
a JPG/GIF combo could only benefit designers. A simple example that does  
not do justice to the proposal would be a photo fading into background  
color with a simple PNG gradient.

>> *Using different bit depths for image and alpha (e.g. 5bit foreground  
>> image, 3bit alpha)
> 3bit alpha is rather theoretical than practical I think.
> GIF has 1bit alpha and PNG supports 8/16bit alpha - for practical cases
> this is enough I believe.

You are to some extent right, 8bit would do the job of any lesser bit  
depths, but just as we could, on some images, "get away" with 3 bit colors  
due to the nature of a particular image, we could also get away with 3  
bits of transparency, which should seem a lot better than 1 bit  
transparency, and save bandwidth and memory compared to 8 bit transparency.

>> *Alpha on a color background instead of an image, hence the ability use  
>> different colors with same alpha.
> grayscale PNG image with alpha channel can serve this purpose pretty  
> well I think.

I believe this may cause gray shifting, unless the UI chooses to apply the  
transparency with compensation, which is not practical to define without a  
separate property or value. Anyway this was just a bonus functionality.

> Another idea: to introduce foreground-* attributes similar to
> background-* attributes. So element could have two images
> if needed. This will also solve your case but will give significantly  
> more.
> foreground-* will be drawn on the same layer as 'outline' currently.

I don't think it does what my proposal suggests, but it is a good idea in  
its own right.

Also, if we enhance the proposal with seperate positioning/repeat such as:
background-image-alpha: <alpha-image> || <image-alpha-type> || <opacity>  
|| <position> || <repeat>
we'd have the ability to use e.g. a 32x32 image as alpha for a 800x800 jpg  
image, coming up with

**pasting from other mail replying to David Woolley's comment
> Yes, but it is still RGB value in GIF. So to be able to use it as single  
> alpha
> channel
> value you need also to define how this single value produced from  
> *arbitrary*
> This RGB to grayscale translation is a subject of holy wars on the Net,  
> like is
> it
> luminance or what...

Whatever the method, RGB to grayscale conversion would create a much less  
havoc than PNG's gamma feature (Which should have never been brought up  
and used in the first place, as it is a constant nuisance when used  
together with other image formats and even simple color declarations).   
But I am indeed glad we have other options.


Received on Monday, 8 May 2006 22:29:56 UTC