Legacy ImageMagick Discussions Archive

Hi everyone!

I've come across IM after searching for a way to scale images with interpolation algorithms other than bicubic/bilinear for a long time, and am very pleasantly surprised with the capabilities of this tool. Great work!

Because I'm working in Photoshop mostly, I'm using IM to downscale from 16bit sRGB PSD files. Sadly, I've encountered a little problem. When converting an image, I always got a weird displaced column of pixels on the far right that clearly belongs to the far left of the image. Below is a test image I created showcasing this.



After hours of testing all kinds of things, I learned that the cause isn't resizing itself, or the use of filters, as just converting the file with "convert xyz.psd[0] xyz2.jpg" yields the same results. The target format isn't at fault either.

What helped was changing the psd file to 8bit internally in PS. Using a command like -depth 8 or -colors 265 does not do anything about the displacement, albeit converting properly. -background white and -flatten did not work in a variety of tests either.

I've tried both IM 6.8.7-10 and 7.0.0.

So, the conclusion I came to is that this really just is a bug that has yet to be adressed - I know that the psd format is not yet perfectly supported.

The only work around I see right now is saving the psd file with PS as a png or similar (for retaining quality and 16bit color information) and then further downscaling from there with IM. While this works somewhat, it is not ideal and a little time consuming, mainly because of file management.

I figured I might as well present my findings and ask, if anybody here has an idea about what could be done that I haven't thought of. Maybe there's advanced commands to correct displacement, or someone has experienced a similar issue.

It would help if you published the original PSD file.

Thanks for the fast reply.

Sure, here it is.

http://www.sendspace.com/file/48rt9g

I forgot to mention - this is a psd file created with PSCS6, so there is a chance that this issue doesn't apply to files created with earlier versions of the program.

What I also noticed is, that the displacement doesn't seem to occur when you leave the background layer untouched, don't add any new layers and just save it from creation.

Your file shows 3 layers in my old PS CS, two of which are empty (transparent). But IM only sees two layers, the first one looks correct, but the second one is a shifted and partly green version.. That is very suspicious.

I tried processing only the first layer, but get your offset as well using IM 6.8.7.10 Q16 Mac OSX

convert displ.psd[0] -strip -resize 75% result.png

Same result with psd output.

Your file may be corrupt or the PS CS6 format has changed.


I created a similar file in PS CS

http://www.fmwconcepts.com/misc_tests/p ... s/test.psd

and did
convert test.psd -resize 75% test_resize.psd
convert test.psd -resize 75% test_resize.png

http://www.fmwconcepts.com/misc_tests/p ... resize.psd
http://www.fmwconcepts.com/misc_tests/p ... resize.png

and both looked just fine -- no offset


So I suspect it is either a corrupt file or a format change in PS CS6. try again -- generate the file without the extra layers

Looking at the verbose information in IM

identify -verbose displ.psd

at the end of the list you will see


Artifacts:
filename: displ.psd
psd:layer.opacity: 0
psd:layer.x: 0ld
psd:layer.y: 0
verbose: true

The "ld" appended does not seem to me to be correct, but that is just a guess.

It is also odd that IM identify -verbose says there are two layers, but identify without -verbose only says one layer.

PS. I opened your file in my PS CS and deleted the two extra layers and saved the file. It then resized without the offset. However, this may be due to saving in PS CS format (vs PS CS6 format).

I tried to delete the extra layers to see if I got the same output, and surely I did. Same with creating another new file and saving and converting it from the get-go. No offset.

Converting your file doesn't give me any offset either - except when I create a second layer and save it then. I assume CS6 will overwrite the CS psd format with its own, so that isn't surprising. Do you get any offset, if you create another layer or two (they don't need to be empty, of course) and save the file?

I don't think my file is corrupt, since I've tried a variety of conversions with many archived psd files of photos, and they all behaved the same. Maybe it has something to do with how the alpha channel is handled during conversion - on my search here in the forums, I remember stumbling across a topic that partly dealt with the layering in psd files that mentioned something of the sort. But frankly, this is at best a guess.

Thank you for your efforts - your knowledge is very much appreciated!

OK. I did 3 tests with PS CS. I added different kinds of layers. Then resized to png format. In each case, the additional layers were not converted correctly. This is a bug in IM (6.8.7.10 Q16), in my opinion.

Starting with one layer, test.psd

http://www.fmwconcepts.com/misc_tests/psd_bug/test.psd

1) I just resized it to png and all was fine

convert test.psd -resize 75% test.png




2) I added a second fully transparent layer to test.psd and resized it in IM. I got two layers, but the second layer was not a copy of the second layer in the psd file, but an offset copy of the first and partly cyan

http://www.fmwconcepts.com/misc_tests/psd_bug/test2.psd

convert test2.psd -resize 75% test.png






3) I added a second layer to test.psd that was a copy of the first layer and resized it in IM. This time I got 3 png images where and the second layer was not a copy of the second layer, but an offset copy of the first and partly cyan and the third layer was black.

http://www.fmwconcepts.com/misc_tests/psd_bug/test3.psd

convert test3.psd -resize 75% test.png








I got the very same thing saving to JPG.

I have reposted this as new bug topic.

It looks like some of the channels are compressed with zip compression. This is currently not supported by ImageMagick. I am working on adding support for this.

dlemstra wrote:It looks like some of the channels are compressed with zip compression. This is currently not supported by ImageMagick. I am working on adding support for this.

Thanks Dirk. I was aware you are working on the zip compression issue.

But in this case my test.psd, test2.psd and test3.psd have all layers with compression none according identify -verbose.

Your test.psd file does not contain layers, it only contains a merged result. And the other images have a zip compressed channel in one of the layers. PSD files have compression per channel. I am not sure why it is reporting there is no compression.

dlemstra wrote:Your test.psd file does not contain layers, it only contains a merged result. And the other images have a zip compressed channel in one of the layers. PSD files have compression per channel. I am not sure why it is reporting there is no compression.

test.psd is just one layer and converts fine. Sorry I was not clear about that one having only one layer. test2.psd and test3.psd have 2 layers when viewed in PS. IM reports 2 layers for test2.psd and oddly 3 layers (rather than 2) for test3.psd. IM reports compression=none for all layers.

EXIFTOOL reports for test3.psd
---- IFD1 ----
259 Compression : 6

This is thumbnail data (JPEG compressed) according to http://www.media.mit.edu/pia/Research/d ... /exif.html

0x0103 Compression unsigned short 1 Shows compression method. '1' means no compression, '6' means JPEG compression.

I do not see any tag that indicates compression for the actual image data.

My files were created by a very old PS CS. Perhaps more current CS6 versions of PS have an option to compress the main image, but I could not find any options in my old PS CS for any compression settings or options when saving as PSD.

How can you tell that it is zip compressed? Is that from the specs or do you have some other tool that indicates the zip compression in my test files?

I am making changes to the code and with the visual studio debugger I am seeing that one of the channels is zip compressed. I was hoping that PS would report that somewhere also. But this could also be a bug and explain the strange behavior you are reporting. I will get back to you when I know more.

Apparently this has been a long standing bug. I was finally able to recompile some old versions of IM and test these conversions on a number of versions going back as far as 6.7.5.5. They all show this same buggy behavior.

I just committed my changes to add support for reading zip compressed psd files. This will be included in the next release of ImageMagick (6.8.8-1).