Legacy ImageMagick Discussions Archive

Is there a way to supply original width/height (not an image, just 2 numbers) to convert or identify command, and receive a resulting width/height based on a geometry, as if an actual image was resized? For example: I would supply 1000,600 (w/h) and geometry '600x600>' and I should get 600,360 on ...

For those who might find this thread, here's my solution that's been working well so far. Vector images don't have density, so trying to identify their density is useless, it will just waste time and return 72. What you do need, is to identify their width and height, and you can just assume it's at ...

fmw42 wrote:try adding -ping. does that make it faster

Code: Select all

identify -ping -density 300 -format "%w %h" x.eps

Just tried this and it didn't seem to help. Looks like identify actually creates the images according to arguments in order to extract the information.

identify -density 300 -format "%w %h" x.eps This seems to return whatever pixel dimensions convert would create at the given density. If this is too small, increase the density. If too large, decrease it. If this trick fails on a file, please post that file, or at least the "identify -verbose ...

Best I can suggest is to test for known types of issue, such as the one you mentioned. This is understood. However, I need to figure out the next step. Let's say I get 5000x7000 EPS file showing 72 (default) density. By which logic should I proceed making it a reasonable PNG file? Should I use ...

Fred,

What do I do after I discover these values? As I mentioned, width, height, and density are not always set (correctly) in vector images, so I could end up getting default density of 72 and no WxH.

Imagine a use case where customers upload vector images (eps, pdf, svg, etc) and you need to automatically convert them to high quality raster images. Problem is — those uploaded images could have missing or bad width/height info. So if you simply convert foo.eps foo.png you may end up with a tiny r ...

fmw42 wrote:I did some time tests

Awesome, thanks for trying these (I'm a bit swamped). This confirms that it's worth it to switch to MPC when running conversions at scale.

For fastest but portable performance, I use uncompressed ("+compress") tiff. You could also try NetPBM PAM format. Thanks, will keep this in mind. However, if I do manage to load the same MPC with proper colorspace in different IM versions, I should be fine with MPC. Will also do some benchmarks ...

Just to highlight in case it wasn't clear from previous posts, this issue was entirely resolved by avoiding MPC files, and using PNG instead. While not ideal, I decided to abandon this optimization for now.

Follow up question: what is the next most performant format to use if I was to abandon MPC?

After some research, and thanks to fmw's answer above, I discovered that both my mpc files and the colorspace could've been the root of the problem. However, I'm not sure what's the best way to fix it now. Here's what happens: 1. If I take my local MPC file, upload it to production (with older IM ...

This problem has a few moving parts, but let me try to be clear and concise. Our production Ubuntu 12.04 is running 6.6.9-7 (latest in official apt-get) My local OS X is running 6.8.0-10 (newer) So far all my complex scripts worked identically locally and in production, but this one latest script ...