woltapp / blurhash

A very compact representation of a placeholder for an image.

Home Page:https://blurha.sh

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Account for transparent pixels in .PNGs

cmanning96 opened this issue · comments

I'm working on an iOS app that has a ton of images with transparent pixels. As of right now, it seems like any pixels that are transparent are treated as if they were black.

basketball-removebg-preview
becomes
IMG_1320

It may be that I'm calling it incorrectly, but I didn't see anything in the docs about this.

For what it's worth, if someone could point me in the right direction as to how to implement this (ie if another platform supports it) I would be more than happy to give it a shot! I'm brand new to using this tool and would love to help out

commented

The specification for the core algorithm is pretty hand-wavy and subjective, but it would be good to have some kind of specification or standard "things to consider" like color space conversions and transparency and all that to guide alternative implementations that would each make compatible results with each other.
Something like transparency would mean that the encoded data would need to include an alpha channel in the color data(RGBA), which would break all current implementations of the encoder and decoder which only expect RGB data as described in the core algorithm.
https://github.com/woltapp/blurhash/blob/master/Algorithm.md#structure

commented

The issue you're seeing too, is that transparent parts of the image can still have color, and despite certain pixels of the image being totally transparent, the RGB color data there is generally undefined. Most compressors and PNG optimizers just put "easy to compress" streaks of pixels there that lend itself to the defate algorithm since that RGB data is not contributing to the final image anyways. Generally, expect garbage data there.

Most algorithms that only care to pick up the RGB data though will wrongfully interpret a transparent image like this:
food_ChocoTaco
As its RGB data alone:
food_ChocoTaco-rgb

The best way I can think of handling this, that lends itself to current RGB-only encoders, is to have a matte option to encoders, where the user provides an RGB value to clip the transparency to(defaulting to something like white) and to flatten out the transparency while(or before) processing the image.

Is there a workaround for this, it is a breaking thing for me in my project?

commented

The workaround would be to possibly multiply the RGB color channels with the A channel, causing the transparent pixels to contribute less to the generated blurs, but will cause transparent areas to contribute black to the color-averages. Another solution is to use transparency to linearly interpolate between the source image's RGB colors and a specified matte color.

An offline way to accomplish all this, is to just flatten the image to remove transparency ahead of time before generating the blur-hash, like previously mentioned.

The real fix, would be for blur-hash to support Alpha-transparency so that it can properly contribute to the blurred image.

The real fix, would be for blur-hash to support Alpha-transparency so that it can properly contribute to the blurred image.

Could there be a separate issue for that?

Kindly commenting so that this issue doesn't go stale. I'd be very much interested in finding a solution for this

Maybe checkout Thumbhash as an alternative that supports alpha: https://github.com/evanw/thumbhash

Since the alpha value is ignored during the encoder implementation, that makes all transparent pixels appear black which doesn't seem acceptable to most people.

A simple acceptable solution will be to check if the alpha value is 0 and then flip all the r,g,b values to 255 to make it white instead of black.

The alpha value can be retrieved at pixelOffset + 3.
Will try making a good PR.