Intervention
Trim function in v3
I understand that updates and improvements are essential, but the trim function served a crucial purpose for my projects. I kindly request the reconsideration and reimplementation of the trim function in future releases.
If there are specific reasons for its removal or alternative approaches, I would appreciate any insights you can provide. Your efforts in maintaining this library are highly appreciated, and I believe the reintroduction of the trim function would benefit many users.
Thank you for your time and consideration!
I can understand why you miss certain functions. However, my main goal with version 3 was to release with the most important and most used features first. Of course, I would have liked to include everything again, but I had to make some difficult decisions and leave some things out.
While for some features there are important reasons why the features were not adopted, the reasons for the trim() function were not definite.
The main reason was that the implementation was rather poor and slow. Furthermore, the function does not play well with multiple animation frames, which is the main feature of version 3.
I would not rule out the possibility of the function coming back, but I will concentrate on other things first. If you feel like it, you can try to implement the old code in the new base and publish a pull request. However, I cannot guarantee integration.
@olivervogel You are correct. Trim implementation is poor and slow. But the way you have envisioned it: To trim by direction and color - is kinda overkill. Most of the trimming is done to remove a uniform color with a "leeway" from the entire image.
Example 1
trimImage (imageMagick)
If you're OK with reimplementing the trim function in a simpler manner the way ImageMagick handles it - I'll implement the feature with unit tests.
Hey @seebeen
Thank you very much. I really appreciate your offer of cooperation. I agree with your thoughts that a simpler version of trim() could also be included but I still have some doubts.
Feasibility with GD
The goal of Intervention Image is to provide a unified API for GD and Imagick. In the best case, the functions will give the same results when you switch drivers.
For Imagick there is trimImage(). This would be sufficient for a simplified version. However, I wonder how this could be implemented with the GD library. There doesn't seem to be a similar function and the edge detection and trimming would probably have to be done manually, which I think would be very difficult. One possibility would be to integrate the function only for Imagick, but I would like to avoid this if possible, as it is not in line with the original goal of the library.
Dealing with animated GIFs
Things get even more complex when animated images need to be processed with trim(). After some tests of mine, I have the impression that Imagick seems to reach its limits here as well. This is probably and logically not even possible. One possibility would be to use the function only for non-animated images.
What do you think about this?
Feasibility with GD
The goal of Intervention Image is to provide a unified API for GD and Imagick. In the best case, the functions will give the same results when you switch drivers.
For Imagick there is
trimImage(). This would be sufficient for a simplified version. However, I wonder how this could be implemented with the GD library. There doesn't seem to be a similar function and the edge detection and trimming would probably have to be done manually, which I think would be very difficult. One possibility would be to integrate the function only for Imagick, but I would like to avoid this if possible, as it is not in line with the original goal of the library.
May I present imagecropauto? 😅
Works in a similar way as ImageMagick trim does. Which means there is an inherent feature parity with both GD and ImageMagick. So the trim function can be implemented in the same way on both drivers.
Dealing with animated GIFs
Things get even more complex when animated images need to be processed with
trim(). After some tests of mine, I have the impression that Imagick seems to reach its limits here as well. This is probably and logically not even possible. One possibility would be to use the function only for non-animated images.
During my entire development career, I've never seen a proper way to automate processing of animated gif images, especially auto-trimming.
From a logical standpoint, trimming an image makes sense if you want to trim the excess transparency from a PNG and stick it onto another image, or if you want to have a logo in a proper dimension.
Trimming an animated gif - not so much. There are changes frame by frame, meaning each frame can be a different dimension - which will cause further issues when joining the frames again.
I think trimming should be limited to static images only, with an exception thrown when trying to use on an animated container.
If we're in agreement, I can get the ball rolling, and make a PoC soon.
The missing trim function is the only thing preventing me from upgrading to v3 and php 8.1 on several of my projects.
May I present imagecropauto? 😅
That's great, how could I have missed that? However, the two functions seem to work differently. Imagick::trimImage() uses edge detection as far as I can see. imagecropauto just looks at the 4 corners of the image or takes a given color. But I would trust you to find the best solution here.
I think trimming should be limited to static images only, with an exception thrown when trying to use on an animated container.
I agree and will then assign this topic to you.
Do you use discord or any other IM services?
Currently not for open source projects.
Is trimming currently possible by combining other existing methods? I'm trying to trim a PNG that has a transparent background, I just want to trim the transparent edges as far as possible.
Not sure. But I'll finalize my PR in the next couple of days, so it will work as expected :)
The trim function has been reintroduced since version 3.6.0. It should be noted that this works differently than in version 2.
See documentation: https://image.intervention.io/v3/modifying/resizing#trim-image