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

Introduce mozjpeg and pngquant post-processors, add transform options. #717

Merged
merged 3 commits into from
May 6, 2016

Conversation

alexwilson
Copy link
Collaborator

Implementing mozjpeg and pngquant post processors, as both allow for significantly greater lossy compression to the current options. This also allows for options to be passed at run-time, as different image filter sets may require different degrees of compression.

Concerning mozjpeg in particular I'd like to revisit this later on, as the current implementation can be improved to account for the level of detail required in an image (and dpr), but the current default is fairly safe and I'm already seeing reductions of 80-90% compared to the raw images.

@lsmith77 lsmith77 added the State: Reviewing This item is being reviewed to determine if it should be accepted. label Mar 21, 2016
* @param int|null $quality Quality factor
*/
public function __construct(
$mozjpegBin = '/opt/mozjpeg/bin/cjpeg',

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be this made configurable somehow?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already configurable here as a parameter - the value in the constructor shouldn't ever need to be used. https://github.com/antoligy/LiipImagineBundle/blob/implement-pngquant-mozjpeg/Resources/config/imagine.xml#L79

@alexwilson
Copy link
Collaborator Author

Hiya @lsmith77, any updates with this PR? I'd love to start rolling this out to production as it really has been helping cut back on page weight. Please let me know! 😄

@m8tt
Copy link

m8tt commented Apr 30, 2016

Hey @lsmith77. Are you actually going to respond to this PR anytime soon? It's been over a month.. Would love to see this merged sometime soon so i can take advantage of better compression 👯

*
* @throws ProcessFailedException
*
* @return BinaryInterface
*
* @see Implementation taken from Assetic\Filter\optipngFilter
*/
public function process(BinaryInterface $binary)
public function process(BinaryInterface $binary, array $options)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is BC break, not sure we can do it,

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you have any idea BC way?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am the second argument was added to the interface

@makasim
Copy link
Collaborator

makasim commented Apr 30, 2016

@antoligy Hi, I am fine to merge this if you can do it BC way.

@alexwilson
Copy link
Collaborator Author

@makasim Cheers for reviewing! Just looking at this, instead of making the change to process, does it make more sense to introduce a new setOptions setter? IMO the processors should remain stateless, which I think is why I originally made the change to process...
Can you think of any (better) cleaner way of allowing per-operation configuration whilst maintaining the stateless nature of the PostProcessors?

@alexwilson
Copy link
Collaborator Author

alexwilson commented Apr 30, 2016

One alternative might be to introduce a new ConfigurablePostProcessor interface enforcing a new method - processWithConfiguration(BinaryInterface $binary, array $options), which could be callable from the older process...

That said I'm not so sure that this does break BC - Looking at the iterator in FilterManager, an array is always passed to the processors and I can't see anywhere else from where these are called. I suppose this affects custom post processors, however if this change is documented somewhere or there's a new minor revision then to me this wouldn't be so much of an issue.

What do you think?

@makasim
Copy link
Collaborator

makasim commented Apr 30, 2016

Let's create a new interface with a note "This for BC and so on" so while working on the 2.x version we can merge them into one again.

@alexwilson
Copy link
Collaborator Author

How's this? (Separate interface, versus an extended one)

StyleCI has failed on the Test bootstrap.php.

@makasim
Copy link
Collaborator

makasim commented Apr 30, 2016

I'll do a deeper review on wednesday when I finally come back to work.

@alexwilson
Copy link
Collaborator Author

Hey @makasim, have you had a chance to look at this yet? 😄

@makasim makasim merged commit b657b66 into liip:master May 6, 2016
@lsmith77 lsmith77 removed the State: Reviewing This item is being reviewed to determine if it should be accepted. label May 6, 2016
@makasim
Copy link
Collaborator

makasim commented May 6, 2016

https://github.com/liip/LiipImagineBundle/releases/tag/1.5.3

@antoligy Thanks for the contribution

@ceesvanegmond
Copy link

Is there an option to always add (the same) post processor to every filter_set?
Now, in every filter_set I have to define the same post processor.

@robfrawley
Copy link
Collaborator

@ceesvanegmond There is not.

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.

7 participants