bug when converting PSD to TIFF with transparency

[fmw42]

Dirk,

Can you look into this issue, when you have time.


One clear bug is related to saving the negative page offsets.


The PSD file hidden layer has

Page geometry: 4694x4561-32-73

When PS saves to TIF, the second layer has

Page geometry: 4694x4561-32-73


But when IM does it, it loses the negative offsets

Page geometry: 4694x4561+0+0

and I get an error message

Code: Select all

convert RGB-SRC.psd RGB-SRC_im_.tif

convert: TIFF: negative image positions unsupported RGB-SRC_im_.tif @ error/tiff.c/WriteTIFFImage/3533.

and even with -layers merge, I get the same error

convert RGB-SRC.psd RGB-SRC_im_.tif

Code: Select all

convert RGB-SRC.psd -background none -layers merge RGB-SRC_im_repage_transplayersmerge.tif

convert: TIFF: negative image positions unsupported RGB-SRC_im_repage_transplayersmerge.tif @ error/tiff.c/WriteTIFFImage/3533.

Is not -layers merge suppose to expand the canvas to a larger size according to the page geometry and handle negative offsets?

[fmw42]

I tested GIMP conversion of this image to TIF and it compares to the PS converted TIF much better than IM's conversion compares to the same PS converted TIF.

IM

Code: Select all

compare -metric rmse RGB-SRC_im_transpflatten.tif RGB-SRC_ps_nolayers_none_transp_lzw.tif null:

1155.24 (0.0176279)

GIMP

Code: Select all

compare -metric rmse RGB-SRC_gimp.tif RGB-SRC_ps_nolayers_none_transp_lzw.tif null:

8.53947 (0.000130304)




LIkewise, with another transparent PSD file converted to TIFF

IM

Code: Select all

compare -metric rmse RGB-SAMPLE-02_im.tif[0] RGB-SAMPLE-02_ps_none_nolayers.tif null:

133.809 (0.00204179)

GIMP

Code: Select all

compare -metric rmse RGB-SAMPLE-02_gimp_none.tif RGB-SAMPLE-02_ps_none_nolayers.tif null:

4.55356 (6.94828e-05)


Without the transparency, the files compare perfectly. So this seems to be associated with how IM handles or extracts the alpha data.

[246246]

But when IM does it, it loses the negative offsets

Page geometry: 4694x4561+0+0

and I get an error message

Code: Select all

convert RGB-SRC.psd RGB-SRC_im_.tif

convert: TIFF: negative image positions unsupported RGB-SRC_im_.tif @ error/tiff.c/WriteTIFFImage/3533.

This error is introduced in 2013. viewtopic.php?t=23810
Offset values are stored in tiff tag XPosition (286) RATIONAL and YPosition (287) RATIONAL, but if I try to set it from tiffset command (from libtiff), it failed.

libtiff 3.9.4 in CentOS 6.7
$ tiffset -s 287 -0.0533333 16x16-16-16.tif'
16x16-16-16.tif: Warning, "YPosition": Information lost writing value (-0.0533333) as (unsigned) RATIONAL.

libtiff 4.0.3 in Cygwin
$ tiffset -s 287 -0.0533333 16x16-16-16.tif
assertion "value>=0.0" failed: file "/usr/src/ports/tiff/tiff-4.0.3-3.i686/src/tiff-4.0.3/libtiff/tif_dirwrite.c", line 2084, function: TIFFWriteDirectoryTagCheckedRational
Aborted (Core dumped)

So at least libtiff can only handle positive offset.

See Tiff sepcification. http://partners.adobe.com/public/develo ... /TIFF6.pdf

TIFF 6.0 Specification
Final—June 3, 1992

Types
The field types and their sizes are:

4 = LONG 32-bit (4-byte) unsigned integer.
5 = RATIONAL Two LONGs: the first represents the numerator of a fraction; the second, the denominator.


So it seems negative offsets are allowed only in Photoshop layer.

[fmw42]

246246

Thanks for the information. So how is GIMP handling that issue? GIMP can convert this file properly. Are they not using libtiff and is libtiff the limitation here?

[246246]

Thanks for the information. So how is GIMP handling that issue? GIMP can convert this file properly.

I don't know Gimp internal, but it crops out outside the canvas, isn't it?

Create with Gimp.
v:\tmp>identify xxx.xcf
xxx.xcf[0] XCF 320x200 320x200+0+0 8-bit sRGB 64.5KB 0.031u 0:00.020
xxx.xcf[1] XCF 400x300 400x300-40-50 8-bit sRGB 0.031u 0:00.020

Export to psd with Gimp
v:\tmp>identify xxx.psd
xxx.psd[0] PSD 320x200 320x200+0+0 8-bit sRGB 138KB 0.016u 0:00.009
xxx.psd[1] PSD 320x200 320x200+0+0 8-bit sRGB 138KB 0.000u 0:00.006
xxx.psd[2] PSD 400x300 400x300-40-50 8-bit sRGB 138KB 0.000u 0:00.012

Export to tif with Gimp
v:\tmp>identify xxx.tif
xxx.tif TIFF 320x200 320x200+0+0 8-bit sRGB 22.3KB 0.000u 0:00.000

WIth IM
v:\tmp>convert xxx.psd xxx2.tif
convert.exe: TIFF: negative image positions unsupported xxx2.tif @ error/tiff.c/WriteTIFFImage/3533.

v:\tmp>convert xxx.psd[1] xxx.psd[2] -crop 320x200+0+0 -background none -layers merge -compress LZW xxx2.tif

v:\tmp>identify xxx2.tif
xxx2.tif TIFF 320x200 320x200+0+0 8-bit sRGB 27.9KB 0.000u 0:00.002

[246246]

Are they not using libtiff and is libtiff the limitation here?

In my environment, gimp is linked with libtiff.

Code: Select all

$ ldd "D:/Program Files/GIMP 2/bin/gimp-2.8.exe" | grep tiff
        libtiff-5.dll => /cygdrive/d/Program Files/GIMP 2/bin/libtiff-5.dll (0x68ec0000)

But here, the problem is not there. Your simple convert command

convert xxx.psd xxx.tif

will generate multi-page tiff if success. If negative offset layer exists in psd, the result have to include it, but tiff spec dose not allow it. So I think GImp cropped it.

If some convert option in IM can generate layered tiff, It should be worked. It should write the layer part to tiff tag 37724 without depending on libtiff. The content of 37724 is almost PSD, so it could be achieved somehow, but I think that is not implemented yet.

[fmw42]

Thanks for the information.

But I also took the first layer (the one that is supposed to be the flattened layer) of the PSD and convert it to TIFF in IM and that was also bad. So was flattening the two layers in IM with a transparent background, though it was better. What is puzzling is that the first layer of the PSD does not seem to be a completely flattened layer, since the latter test was different from using just the first layer.

[246246]

I don't understand what is the problem.

Every application will have a different way to merge even using simpler file.

xxx.psd is my simple test file above.

Code: Select all

$ identify -verbose xxx.psd[0] | egrep -i '(red|green|blue|alpha):[^$]'
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 8-bit
  Alpha: srgba(255,255,255,0)   #FFFFFF00

$ identify -verbose xxx.psd[1] | egrep -i '(red|green|blue|alpha):[^$]'
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 8-bit
  Alpha: none   #00000000

$ identify -verbose xxx.psd[2] | egrep -i '(red|green|blue|alpha):[^$]'
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 16-bit
  Alpha: none   #00000000

xxx.tif is converted with Gimp

Code: Select all

$ identify -verbose xxx.tif | egrep -i '(red|green|blue|alpha):[^$]'
    red: 16-bit
    green: 16-bit
    blue: 16-bit
    alpha: 8-bit
  Alpha: none   #00000000
    tiff:alpha: associated

xxx2.tif is merged with IM.

Code: Select all

$ convert xxx.psd[1] xxx.psd[2] -crop 320x200+0+0 -background none -layers merge -compress LZW xxx2.tif
$ identify -verbose xxx2.tif | egrep -i '(red|green|blue|alpha):[^$]'
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 8-bit
  Alpha: srgba(255,255,255,0)   #FFFFFF00
    tiff:alpha: unassociated

xxx3.tif is simple convert with IM:

Code: Select all

$ convert xxx.psd[0] xxx3.tif
$ identify -verbose xxx3.tif | egrep -i '(red|green|blue|alpha):[^$]'
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 8-bit
  Alpha: srgba(255,255,255,0)   #FFFFFF00
    tiff:alpha: unassociated

xxx4.tif is merged by photoshop (save without layer).

Code: Select all

$ identify -verbose xxx4.tif | egrep -i '(red|green|blue|alpha):[^$]'
    red: 16-bit
    green: 16-bit
    blue: 16-bit
    alpha: 8-bit
  Alpha: none   #00000000
    tiff:alpha: associated

result

Code: Select all

$ compare -metric PSNR xxx.psd[0] xxx.tif null:
37.2018

$ compare -metric PSNR xxx.psd[0] xxx2.tif null:
30.118

$ compare -metric PSNR xxx.psd[0] xxx3.tif null:
inf

$ compare -metric PSNR xxx.psd[0] xxx4.tif null:
37.215

As far as I see here, ImageMagick will not change image during psd to tiff conversion. See xxx3.tif.

What is puzzling is that the first layer of the PSD does not seem to be a completely flattened layer

I think first layer [0] of your psd is somewhat broken - i.e. in PSD format, merged layer is saved in different place from other layers [1], [2] etc. So it is possible to create a PSD file whose merged layer is totally irrelevant. (That's why Dirk said it might be "old Photoshop bug" that might occurred in saving.)

For example,

Code: Select all

$ convert \( -label "top" rose: -resize 32x32! \) \( -label "bottom" logo: -resize 32x32! \) \( -clone 1 -negate -mosaic \) -reverse result.psd

$ identify result.psd
result.psd[0] PSD 32x32 32x32+0+0 8-bit sRGB 9.44KB 0.000u 0:00.033
result.psd[1] PSD 32x32 32x32+0+0 8-bit sRGB 9.44KB 0.016u 0:00.007
result.psd[2] PSD 32x32 32x32+0+0 8-bit sRGB 9.44KB 0.016u 0:00.008

If you open result.psd in Photoshop or Gimp, you only see rose (and logo on layer view), but what is the result with

Code: Select all

display result.psd[0]

[fmw42]

Yes, in IM you need to prepare the flattened layer when combining layers to put into a PSD file. But my file, I was told, was created in PS and should have a proper flattened layer.

When I have any PSD file that has background transparency, there is a larger different when converted to TIF by IM than by GIMP or PS. I can see some differences around the boundary, especially if the boundary is irregularly shaped and not just a rectangle.

[fmw42]

OK. I created a test image, which can be posted, that shows the problem. This is a 250x250 transparent image that I inserted into a larger (300x300) transparent background in PS and saved as PSD. Then I converted it to TIF in PS, IM and GIMP.

Source:


PSD file:
http://www.fmwconcepts.com/misc_tests/p ... mickey.psd

PSD to TIF in PS without saving layers:
http://www.fmwconcepts.com/misc_tests/p ... layers.tif

PSD to TIF in GIMP:
http://www.fmwconcepts.com/misc_tests/p ... layers.tif

Code: Select all

compare -metric rmse mickey_ps_nolayers.tif mickey_gimp_none.tif null:
22.653 (0.000345663)

PSD to TIF in IM from the first layer in the PSD
http://www.fmwconcepts.com/misc_tests/p ... m_none.tif

Code: Select all

convert mickey.psd[0] -compress none mickey_0_im_none.tif
compare -metric rmse mickey_ps_nolayers.tif mickey_0_im_none.tif null:
1479.38 (0.022574)

PSD to TIF in IM by flattening against transparent background:
http://www.fmwconcepts.com/misc_tests/p ... n_none.tif

Code: Select all

convert mickey.psd -background none -flatten -compress none mickey_flatten_none.tif
compare -metric rmse mickey_ps_nolayers.tif mickey_flatten_none.tif null:
1467.59 (0.022394)

You can see the antialiasing differences by flickering the IM and PS images. It is quite striking in Mickey's tail.

Just using PS, GIMP and the first IM example above:

[fmw42]

I tested the above also by using -define tiff:alpha= for unspecified, associated and unassociated in the IM conversion, but they were all the same and bad as above. So the tiff alpha setting makes no difference.

[fmw42]

I tested the IM conversion to TIFF with IM 6.8.6.9 Q16 and it behaves the same way. So this problem is not due to the relatively recent bug fix for transparency.

[246246]

I see the difference, but you provide png (not psd), so I simply start testing from it.

$ convert Mickey_Mouse.png Mickey_IM.psd
$ identify Mickey_IM.psd
Mickey_IM.psd[0] PSD 250x250 250x250+0+0 8-bit sRGB 500KB 0.016u 0:00.063
Mickey_IM.psd[1] PSD 250x250 250x250+0+0 8-bit sRGB 500KB 0.000u 0:00.006
$ convert Mickey_IM.psd[0] MI0.png
$ convert Mickey_IM.psd[1] MI1.png
$ compare -metric PSNR -format "\n" MI0.png MI1.png null:
inf
$ compare -metric PSNR -format "\n" Mickey_Mouse.png MI0.png null:
inf

Create Mickey_Gimp.psd with Gimp. (Import and Export only.)
$ identify Mickey_Gimp.psd
Mickey_Gimp.psd[0] PSD 250x250 250x250+0+0 8-bit sRGB 219KB 0.000u 0:00.146
Mickey_Gimp.psd[1] PSD 250x250 250x250+0+0 8-bit sRGB 219KB 0.016u 0:00.006
$ convert Mickey_Gimp.psd[0] MG0.png
$ convert Mickey_Gimp.psd[1] MG1.png
$ compare -metric PSNR -format "\n" MG0.png MG1.png null:
31.3638

So I think gimp saved different one in merged layer.

$ compare -metric PSNR -format "\n" Mickey_Mouse.png MG0.png null:
31.3638
$ compare -metric PSNR -format "\n" Mickey_Mouse.png MG1.png null:
inf

But original is kept in the layer.

Same is true for Photoshop.

$ identify.exe Mickey_PS.psd
Mickey_PS.psd[0] PSD 250x250 250x250+0+0 8-bit sRGB 252KB 0.016u 0:00.047
Mickey_PS.psd[1] PSD 250x250 250x250+0+0 8-bit sRGB 252KB 0.000u 0:00.005
$ convert Mickey_PS.psd[0] MP0.png
$ convert Mickey_PS.psd[1] MP1.png
$ compare -metric PSNR -format "\n" MP0.png MP1.png null:
31.3439
$ compare -metric PSNR -format "\n" Mickey_Mouse.png MP0.png null:
31.3439
$ compare -metric PSNR -format "\n" Mickey_Mouse.png MP1.png null:
inf

[fmw42]

The orginal image was a transparent PNG, but I opened it in Photoshop and made it into a PSD file.

I convert the PSD (not PNG) to TIFF in all cases, except the animation. Only the animation at the end was converted from TIFF to an animated gif for display. But if you take the TIFF files and alternate them or flicker them in a viewer you will see the same issue.

[246246]

Look carefully what I am checking. Converting to tiff from PSD results the same thing.
Mickey_PS.psd is made by Photoshop. (I don't know exactly how you made your PSD. In my case it is simply converted. It has only 1 layer.)

$ convert Mickey_PS.psd[0] MP0.tif
$ convert Mickey_PS.psd[1] MP1.tif
$ compare -metric PSNR -format "\n" MP[0].tif MP[1].tif null:
31.3439
$ compare -metric PSNR -format "\n" Mickey_Mouse.png MP[0].tif null:
31.3439
$ compare -metric PSNR -format "\n" Mickey_Mouse.png MP[1].tif null:
inf

Converting from PSD[1] to Tiff does not alter anything. So there is no bug in converting process.

If you start from PSD[0], any conversion with IM cannot generate the same one as the original, because we don't know how Photoshop changed original to PSD[0].