Details
-
Bug
-
Resolution: Unresolved
-
High
-
None
-
None
-
None
Description
We ran into a memory issue, when generating aliases of large images (using LiipImagine with Imagick underneath). We tracked that down and found the cause in eZ\Bundle\EzPublishCoreBundle\Imagine\BinaryLoader which is registered as Loader for LiipImagine.
eZ\Bundle\EzPublishCoreBundle\Imagine\BinaryLoader` returns an Liip\ImagineBundle\Model\Binary even if its used to load a local image from filesystem. That makes the `ExifMetadataReader` of the underlying imagine/imagine library treat it as a binary stream. As a result it reads the complete file (again) into memory, just to extract the Exif-Metadata.
LiipImagine offers another Interface for local files:
Liip\ImagineBundle\Binary\FileBinaryInterface. Handing those over to the ExifMetadadaReader allows reading the tags without loading the binary in a string first.
A really simple fix would be to simply return a `FileBinary` instead of a `Binary` from `BinaryLoader` but I'm not sure if thats possible or if we need to support non-filesystem storages in the Loader. And if yes, what would be a sensible way to decide wether to return a Binary or a FileBinary from the Loader? If someone could give me some advice on that, i'd be happy to open a pull request.
Attachments
Issue Links
- relates to
-
EZP-31377 Use imagick by default on Platform.sh to avoid memory issues
- Closed