Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintain Alpha when compressing PNG #3

Open
dazuaz opened this issue Jul 30, 2020 · 1 comment
Open

Maintain Alpha when compressing PNG #3

dazuaz opened this issue Jul 30, 2020 · 1 comment

Comments

@dazuaz
Copy link

dazuaz commented Jul 30, 2020

Hey, great library!, is there an option to maintain alpha channel when converting PNG to webp, also, when I try to compress PNG, I only get a very small silluete of the image

@colbyn
Copy link
Member

colbyn commented Jul 31, 2020

Oh great question, and cool seeing someone taking an interest in my work! 🙂

PNG Issue

Regarding,

when I try to compress PNG, I only get a very small silluete of the image

can you upload an example of the source image, the resulting image, and the CLI command used?

Also the PNG optimization logic isn't at the same quality as the implementations for lossy codecs such as JPEG and WebP.

Supporting Transparency

Regarding,

is there an option to maintain alpha channel when converting PNG to webp

This is a no.

At the time, my concern was compressing media using any means possible, and alpha channels generally introduce significant overhead in this regard (well depending on the given codec). Also my focus was lossy codecs and only newer formats support transparency.

Though I can see why this may be necessary.

But anyway, the short answer is no.

The long answer, for those interested: the Imager frontend decodes a multitude of image formats into an intermediate (lowest common denominator) pixel format, i.e. YUV420P pixel buffers, which all subsequent components accept as input. VMAF for instance, only supports YUV420P and a few others. So supporting transparency will involve some changes to this intermediate format, which can be done... I'd imagine it wouldn't be too hard.

PS

  • Honestly, I'd love to move away from using YUV420P.

  • Regarding PNG support. The current implementation is based on non-GPL code... Part of me wanted to see Imager as the FFmpeg of automated media compression. So therefore, perhaps, I'd like to add optional support for pngquant... But this may complicate things from a licensing perspective (e.g. I generally try to avoid runtime dependencies since it can be frustrating for the end-user).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants