Legacy ImageMagick Discussions Archive

Hi,

I'm creating a RLE compressed psd with four layers. The convert command below is similar to what I want to achieve, in reality I'm converting four jpegs of varying types, but it's good enough for visualising the question.
The RLE compression takes about 10–11 seconds —is that to be expected, or is there any way to change the command to improve the speed?

I read (https://github.com/ImageMagick/ImageMagick/issues/84) that zip compression of layers in psd files is supported, however I can't get that to work. When opening the psd in Photoshop I get an error message "Could not complete your request because the file is not compatible with this version of Photoshop." Is Photoshop at all compatible with zip compression?

Any help is highly appreciated!

Convert command

Code: Select all

convert \
\( -size 3000x3600 -depth 8 canvas:gray99 -flatten \) \
\( -page +1100+1000 -size 800x1600 -label first -depth 8 canvas:blue -transparent white \) \
\( -page +1100+1000 -size 800x1600 -label second -depth 8 canvas:red -transparent white \) \
\( -page +1100+1000 -size 800x1600 -label third -depth 8 canvas:green -transparent white \) \
\( -page +1100+1000 -size 800x1600 -label fourth -depth 8 canvas:yellow -transparent white \) \
-density 72 -colorspace sRGB -profile ./colorprofiles/sRGB.icm -compress RLE out.psd

Verbose output
canvas:gray99=>gray99 CANVAS 3000x3600 3000x3600+0+0 8-bit Gray 0.140u 0:00.139
canvas:blue=>blue CANVAS 800x1600 800x1600+1100+1000 8-bit sRGB 0.010u 0:00.009
canvas:red=>red CANVAS 800x1600 800x1600+1100+1000 8-bit sRGB 0.010u 0:00.000
canvas:green=>green CANVAS 800x1600 800x1600+1100+1000 8-bit sRGB 0.000u 0:00.009
canvas:yellow=>yellow CANVAS 800x1600 800x1600+1100+1000 8-bit sRGB 0.000u 0:00.000
./colorprofiles/sRGB.icm ICM 1x1 1x1+1100+1000 8-bit sRGB 3144B 0.000u 0:00.000
canvas:gray99=>out.psd[0] CANVAS 3000x3600 0x0+1100+1000 8-bit sRGB 989562B 2.630u 0:10.039

einake wrote:The RLE compression takes about 10–11 seconds —is that to be expected, or is there any way to change the command to improve the speed?

Your command takes 0.52 seconds on my laptop, with Cygwin bash on Windows, IM v6.9.5-3.

Thanks for the quick reply. I realise that I forgot to add version and OS…

Version: ImageMagick 7.0.7-22 Q16 x86_64 2018-03-08
MacOS HighSierra

I'll install IM 6.9.5 and give it a go. Thanks!

On my Mac INTEL 2-core Mini OSX Sierra running IM 7.0.7.25 Q16 HDRI, this command runs in 1.3 s

Code: Select all

magick \
\( -size 3000x3600 -depth 8 canvas:gray99 -flatten \) \
\( -page +1100+1000 -size 800x1600 -label first -depth 8 canvas:blue -transparent white \) \
\( -page +1100+1000 -size 800x1600 -label second -depth 8 canvas:red -transparent white \) \
\( -page +1100+1000 -size 800x1600 -label third -depth 8 canvas:green -transparent white \) \
\( -page +1100+1000 -size 800x1600 -label fourth -depth 8 canvas:yellow -transparent white \) \
-density 72 -colorspace sRGB -profile /Users/fred/images/profiles/sRGB.icc -compress RLE out.psd

Note that in IM 7, you should replace convert with magick (not convert and not magick convert)

Well, do I feel like an idiot. I was running the command, unknowingly, on a mounted drive… When moving the project to a better location, I have the exact same performance as you fmw42…

Thank you both for such quick responses, I really appreciate it. Any idea about the zip compression mentioned in the link (might be better to ask on github)?

fmw42 wrote: ↑2018-03-11T11:08:38-07:00 Note that in IM 7, you should replace convert with magick (not convert and not magick convert)

I'm confused about this. On my system (Mac High Sierra, IM 7.0.7-25), convert and magick convert seem to be equivalent, e.g., for this command:

Code: Select all

convert -background blue -size 4000x4000 -negate -scale 10% xc: show:

Or they produce the same output and take the same amount of time to run.

OTOH magick alone gives an error: magick: no images found for operation `-negate' at CLI arg 5 @ error/operation.c/CLIOption/5266.

And the docs at http://imagemagick.org/script/porting.php#cli say this:

To reduce the footprint of the command-line utilities, these utilities are symbolic links to the magick utility.

which I also observe on my system where the various specific commands are all symlinked to magick.

EDIT: OK, I should have looked at that error better. If I change the command to move the xc: before the negate, then it works and again in roughly the same time as the other two:

Code: Select all

magick -background blue -size 4000x4000 xc: -negate -scale 10% show:

So, I remain confused about the distinction.

muccigrosso wrote:convert -background blue -size 4000x4000 -negate -scale 10% xc: show:

This command isn't valid. Operations are performed in the order given, and you can't "-negate" or "-scale" an image that hasn't yet been created (by "xc:").

Older versions of IM (v6) didn't enforce the order, and rearranged operations. This is historic, based on the Unix convention of listing all the options in a command before the input and output files. But this creates ambiguity so it's a bad idea, and IM v7 enforces the rule.

As a general rule, "magick" is v7, but "magick convert" and "convert" are v6.

snibgo wrote: ↑2018-03-12T08:22:42-07:00
muccigrosso wrote:convert -background blue -size 4000x4000 -negate -scale 10% xc: show:
This command isn't valid. Operations are performed in the order given, and you can't "-negate" or "-scale" an image that hasn't yet been created (by "xc:").

Older versions of IM (v6) didn't enforce the order, and rearranged operations. This is historic, based on the Unix convention of listing all the options in a command before the input and output files. But this creates ambiguity so it's a bad idea, and IM v7 enforces the rule.

Yes, I realized that. See my edited command.

snibgo wrote: ↑2018-03-12T08:22:42-07:00 As a general rule, "magick" is v7, but "magick convert" and "convert" are v6.

Personally I like using the various specifiers(?) like convert as commands, since they make it clear what the command is doing. I don't have two versions on my machine (the usual case, I'd expect), so both are v7.

But I still don't quite understand how a bare magick is intended to work in ambiguous situations. For example, magick filename.jpg gives an error (Invalid argument or not enough arguments) whereas identify filename.jpg doesn't. Neither does magick identify filename.jpg, but now you're using two words instead of one. Also the docs explicitly say that the older commands are linked to the new one and they work as expected.

So I'm confused I guess about the purpose of the move to magick, and the advice not to use a command like magick convert, when, in the case of identify, it won't work otherwise, unless I'm missing something. (I do use the on-line and included docs, which seem to be mostly for v6, so maybe I'm just not informed about important details of v7.)

"magick convert" is v6 syntax. I can't see a good reason to use this. It might be a stopgap, if scripts written for v6 are to be used with v7.

snibgo wrote: ↑2018-03-12T09:12:45-07:00 "magick convert" is v6 syntax. I can't see a good reason to use this. It might be a stopgap, if scripts written for v6 are to be used with v7.

I agree with not using both words, but for the reason that convert works all by itself.

I find the code a lot easier to read with convert, identify, mogrify, etc., instead of magick. Plus it is often more concise, as with the identify example I gave above.

Well, you can do whatever you want, of course. But you have shown that "convert" by itself uses the old v6 syntax.

If you want to continue using IM 7 and want all the new features and any new ones that are subsequently added, then I recommend you start using the magick syntax so that you gain by using IM 7.

fmw42 wrote: ↑2018-03-12T12:49:46-07:00 If you want to continue using IM 7 and want all the new features and any new ones that are subsequently added, then I recommend you start using the magick syntax so that you gain by using IM 7.

So you're saying that by not using it, I'm missing out on something? This is my question: what exactly is the difference? I don't have any other version than 7 on my system, so what am I missing?

Is there a place to see what the new features in 7 are?

snibgo wrote: ↑2018-03-12T11:50:35-07:00 Well, you can do whatever you want, of course. But you have shown that "convert" by itself uses the old v6 syntax.

No, I've shown that convert by itself also uses the old syntax, since the new works as well. And I've shown that convert by itself seems identical to magick by itself, but that identify by itself can replace a more complex command with magick: magick identify.

But is there a difference in the output between using or not using magick?

Again, it seems to me that using the old commands has the advantage of being more readable, and saving me a little typing in some cases. I'm just trying to figure out what practical difference it makes.

wrote:And I've shown that convert by itself seems identical to magick by itself, ...

But you showed above a command that "convert" by itself accepts a sequence of arguments that "magick" by itself doesn't. They are not identical. (I suppose the symlinked program finds how it was called, and processes its arguments accordingly.)

Legacy ImageMagick Discussions Archive

PSD RLE compression — any speed improvements possible?

PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?

Re: PSD RLE compression — any speed improvements possible?