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

Better performance (especially on large files). #9

Open
wants to merge 53 commits into
base: master
Choose a base branch
from

Conversation

aeh
Copy link

@aeh aeh commented Mar 26, 2018

Dealing with large images (especially SVG images with a large viewport) can take a long time and use an excessive amount of memory or even die with a resources exhausted error.

Using this test file:

<?xml version="1.0" encoding="UTF-8"?>
<svg version="1.2" viewBox="0 0 20000 20000">
  <circle cx="10000" cy="10000" r="8000" stroke="black" stroke-width="30" fill="red" />
</svg>

Using the time function and the memusg function found here: https://gist.github.com/netj/526585

identify -format "%m %[size] %[width] %[height] %[colorspace]" test.svg
MVG 215B 20000 20000 sRGB
time: 62.56s user 8.36s system 92% cpu 1:16.41 total
memusg: peak=7578552

This alternative implementation uses ImageMagick's convert -ping function which doesn't keep any pixel information.

convert -ping test.svg -format "%m %b %[width] %[height] %[colorspace]" info:
SVG 180B 20000 20000 sRGB
time: 0.01s user 0.01s system 51% cpu 0.038 total
memusg: peak=940

Significantly better.

I needed to change %[size] to %b since %[size] returns 0 in the -ping version. Reading the docs I'd expect both options to be the same however that isn't quite the case in practice.

  • The above identify will return 215B for both %b and %[size]. It also states that it is an MVG file so maybe it is converting it first and 215B is the size of the converted file?
  • Requesting identify -format "%b" test.svg it will return 180B as does the above convert -ping call. Using ls also returns 180B so I'd argue this is the correct number. I'm not exactly sure where the other 35B are coming from in the other case.

I've also added the -precision 12 option. There were some failing tests on my local OSX box since it seems the default precision for OSX is 6 while Linux is 4. Setting it to 12 removes that difference and also gives better accuracy.

Hans Kristian Flaatten added 30 commits April 22, 2015 23:57
Based on the image exif data returned width and hight properties will
be reversed to match the image's real orientation.

**Usage:**

```
metadata(path, {autoOrient: true}, function(error, data) {
  console.log(error);
  console.log(data);
});
```
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