PSB to JP2 fails

[Porsupah]

I just tried converting a PSB (Photoshop Big) file to JPEG-2000 using the simple form:

Code: Select all

convert image.psb image.jp2

The system was busy for some fifteen minutes, before keeling over with no further output than "Abort trap: 6".

ImageMagick 6.9.0 via MacPorts, under OS X 10.10.2, on a late-2013 MacBook Pro 16GB/1TB.

The source PSB is 18GB - it's a cityscape stitched from 711 separate shots, making for an image that exceeds 65536 pixels horizontally, therefore unsuitable for almost any image file format other than PSB (which AutoPano Giga supports) and JPEG-2000 (which it doesn't, frustratingly).

Suggestions would be gratefully received.

[snibgo]

How many pixels does the image have? Q16 IM needs 8 bytes per pixel. Do you have enough free space in the temporary area of your disk?

[Porsupah]

How many pixels does the image have? Q16 IM needs 8 bytes per pixel. Do you have enough free space in the temporary area of your disk?

It's 86501 × 26400 pixels, which would suggest a requirement of about 18GB, if my calculation's correct. I do have that free - currently, I'm at about 250GB spare.

[magick]

Do you have a recent release of ImageMagick, the current release is 6.9.0-8?

Try this command:

• convert -define registry:temporary-path=/data/tmp -limit area 0 'image.psb[0]' image.png

where /data/tmp is a path on your disk with plenty of free space. If that works but this fails:

• convert -define registry:temporary-path=/data/tmp -limit area 0 'image.psb[0]' image.jp2

It may be because ImageMagick tries to only allocate one row of an image at a time (e.g. PNG) but the JPEG-2000 API allocates the entire image.

Its possible the abort is coming from the JPEG-2000 API. Try this:

• gdb convert
  run -define registry:temporary-path=/data/tmp -limit area 0 'image.psb[0]' image.jp2
  where

Post the stack trace here. The trace shows us whether the abort is in ImageMagick or the JPEG-2000 API.

[Porsupah]

Do you have a recent release of ImageMagick, the current release is 6.9.0-8?

Not quite, but very nearly; convert --version gives me:

Code: Select all

Version: ImageMagick 6.9.0-0 Q16 x86_64 2015-02-27

Try this command:

• convert -define registry:temporary-path=/data/tmp -limit area 0 'image.psb[0]' image.png

where /data/tmp is a path on your disk with plenty of free space. If that works but this fails:

• convert -define registry:temporary-path=/data/tmp -limit area 0 'image.psb[0]' image.jp2

It may be because ImageMagick tries to only allocate one row of an image at a time (e.g. PNG) but the JPEG-2000 API allocates the entire image.

Currently running the PNG test. I'll update this once both have completed. Many thanks for your assistance!

Oof, the JP2 API tries to grab the whole lot as a buffer in one go? Rather inelegant.

Confirmed: the PNG conversion ran successfully, but the JP2 failed with the same error as before. I'll see what gdb reveals.

[Porsupah]

Unfortunately, the stack trace seems to be a touch wanting.

Code: Select all

Starting program: /opt/local/bin/convert -define registry:temporary-path=/Users/porsupah/panotmp -limit area 0 'park.psb' park.jp2

Program received signal SIGSEGV, Segmentation fault.
0x0000000100db4707 in ?? ()
(gdb) where
#0  0x0000000100db4707 in ?? ()
#1  0x00007fff5fbf43d0 in ?? ()
#2  0x0000000100db21ab in ?? ()
#3  0x00000001009050e0 in ?? ()
#4  0x0000000100905670 in ?? ()
#5  0x0000000100b00498 in ?? ()
#6  0x327023e0009056f0 in ?? ()
#7  0x327023e000000000 in ?? ()
#8  0x000000166a000000 in ?? ()
#9  0x0000000100c01b60 in ?? ()
#10 0x0000000100904fb0 in ?? ()
#11 0x0000000000000001 in ?? ()
#12 0x0000000100c0a9b0 in ?? ()
#13 0x00000001009056f0 in ?? ()
#14 0x0000000100905670 in ?? ()
#15 0x0000000101826000 in ?? ()
#16 0x0000000101829278 in ?? ()
#17 0x0000000100b00440 in ?? ()
#18 0x0000000100c01c00 in ?? ()
#19 0x00007fff5fbf9ee0 in ?? ()
#20 0x00000001008f447f in ?? ()
#21 0x0000000000000000 in ?? ()
(gdb)