Skip to content

Conversation

@cmb69
Copy link
Member

@cmb69 cmb69 commented Oct 8, 2016

Lossless WebP is a rather interesting alternative to PNG, and already
supported by gdImageCreateFromWebp*(), so we add support for
gdImageWebp*(), too.

We can stick with the existing API, using the quality parameter to
request lossless encoding if it is set to gdWebpLossless, which we
define to PHP_INT (to avoid adding a new dependency to gd.h, we hard-
code the value – we're assuming sizeof(int)==4 anyway).

Lossless WebP is a rather interesting alternative to PNG, and already
supported by `gdImageCreateFromWebp*()`, so we add support for
`gdImageWebp*()`, too.

We can stick with the existing API, using the quality parameter to
request lossless encoding if it is set to `gdWebpLossless`, which we
define to `PHP_INT` (to avoid adding a new dependency to gd.h, we hard-
code the value – we're assuming `sizeof(int)==4` anyway).
@cmb69
Copy link
Member Author

cmb69 commented Oct 8, 2016

Apparently, WebPEncodeLosslessRGBA() is not defined in the Linux environments. :-/

@pierrejoye
Copy link
Contributor

Can you fix the conflict and see if we can get that merged?

@cmb69 cmb69 closed this Mar 29, 2019
@cmb69 cmb69 deleted the webp-lossless branch March 29, 2019 16:29
@morsssss
Copy link
Contributor

morsssss commented Apr 2, 2021

Hi @cmb69 !

Is the issue you mentioned above still a blocker? I see that the lossless functions are listed in the WebP API docs, at least...

/cc @adamsilverstein

@cmb69
Copy link
Member Author

cmb69 commented Apr 2, 2021

Well, I guess it's not a hard blocker anyway; we could detect whether it is supported during configuration, and use it if requested and available, and otherwise let the function call fail. If you want to take this PR, please do so. :)

@morsssss
Copy link
Contributor

morsssss commented Apr 5, 2021

Thanks, @cmb69. I could look at this, perhaps after I finish propagating #671 into PHP - or perhaps as a pleasant break from that task, once I get into it :)

I'd be curious to find out whether WebPEncodeLosslessRGBA() is still missing in any environment!
Also wondering how you'd feel about making the value of gdWebpLossless a number that's closer to the usual values instead...

@cmb69
Copy link
Member Author

cmb69 commented Apr 8, 2021

Also wondering how you'd feel about making the value of gdWebpLossless a number that's closer to the usual values instead...

I'm not sure why I've picked that value; it's only important to use a value which isn't useful for lossy quality (I think [0,100]). OTOH, the actual value doesn't really matter as long as we're defining a macro.

@adamsilverstein
Copy link
Contributor

Noting that in the WordPress imagick engine case, passing a value of 100 indicates we want to use the lossless format. Would that approach work here @cmb69?

@cmb69
Copy link
Member Author

cmb69 commented May 5, 2021

Well, 100 designates the best quality for lossy encoding, so using 100 to mean lossless takes that option away.

@morsssss
Copy link
Contributor

morsssss commented May 5, 2021

I've been struggling with the same thing. 100 would have been quite logical! It could well have made sense to make it lossless when the API was first created, but that ship has sailed.

I don't suppose 100 is already equivalent to lossless internally? The API docs do say it's still lossy, but I've not personally tried it.

0 would have sort of made sense, if not really... but it's also a valid quality. I believe -1 means "use the default" of 80, in which case that's no good either.

101? 😬

@cmb69
Copy link
Member Author

cmb69 commented May 5, 2021

Maybe treat any value > 100 as lossless; the value of gdWebpLossless could stay INT_MAX, or could be changed to 101; I don't really mind.

@adamsilverstein
Copy link
Contributor

value > 100 makes sense, thanks for the feedback, I will adjust the code and open a new PR.

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

Successfully merging this pull request may close these issues.

4 participants