Adjust5 v5.2.0 returns a tiff file that Gimp sees as transparent

Hi. I am running Adjust5 from Linux/Wine64. I recently updated Linux, Wine and Adjust5.

If I start Adjust5 on a jpg, Adjust5 returns a jpg that is readable by all my display/edit programs. No problem here.

The problem occurs when I give Adjust5 an 8-bit tiff, Adjust5 then returns an 8-bit tif that looks completely transparent on both Gimp and Geeqie. The tiff is not empty though since if I reload that transparent tiff with Adjust5 I can see the picture.

So it looks like an issue with the tiff format used when Adjust5 writes the tiff.

Any clue on how to fix that?

Thanks

(Edit) On second thought it may well be an issue with Wine. After all Adjust5 v5.2.0 has been out for over a year now. I will record the output of Wine and try to find out more information from there.

(Edit 2.) Indeed Wine has problems writing the tiff file as can be seen from the end of the Wine output. I found out that XV can display the file written by Adjust5 anyway; XV just pops up a warning window to complain saying it ignores ExifFDOffse but it goes on and displays the picture. My copy of XV is old and links to libtiff.so.3.9.7 while Geeqie links to libtiff.so.5.2.6. Gimp is not linked directly to libtiff. So there is an issue with the tiff libraries somewhat.

I marked the thread ‘Solved’ from the Topaz side since the issue is most likely on the Linux/Wine side.

Here’s what I still haven’t output:
tiff:Orientation
tiff:XResolution
tiff:YResolution
tiff:ResolutionUnit
tiff:PhotometricInterpretation
tiff:PlanarConfiguration
tiff:Compression
tiff:subfiletype
photoshop:DateCreated
xmp:CreateDate
Not find in EXIF TAG Dictionary oiio:BitsPerSample int
Try to set Orientation which type is int, but failed
Try to set XResolution which type is float, but failed
Try to set YResolution which type is float, but failed
Try to set ResolutionUnit which type is string, but failed
Not find in EXIF TAG Dictionary DocumentName string
Not find in EXIF TAG Dictionary tiff:PhotometricInterpretation int
Not find in EXIF TAG Dictionary tiff:PlanarConfiguration int
Not find in EXIF TAG Dictionary planarconfig string
Not find in EXIF TAG Dictionary tiff:Compression int
Not find in EXIF TAG Dictionary compression string
Not find in EXIF TAG Dictionary tiff:RowsPerStrip int
Not find in EXIF TAG Dictionary PixelAspectRatio float
Not find in EXIF TAG Dictionary tiff:subfiletype int
Not find in EXIF TAG Dictionary ICCProfile uint8[25572]
Try to set DateTime which type is string, but failed

I have a dual boot PC so today I first booted Windows10 64 Pro to see how Adjust5 would handle that 8-bit tiff. Same problem in Windows10 as in Linux/Wine64. Adjust5 running on Window10 returns an 8-bit tiff that displays as a black frame in Irfanview64. I should have checked with other programs and I will the next time I boot Windows.

So the problem occurs in both Windows10 and Linux/Wine. So I removed the Solved label from the title.

We no longer support Irfanview. Can you try running Adjust 5 from Topaz Studio? It’s free to use, and can launch Adjust 5, as long as you’re using the latest version of Adjust 5.

I am running Adjust5 standalone; I am not running Adjust5 from Irfanview. I mention Irfanview as it is one app I use to view pictures in Windows.

My post is about an issue with the format of the 32-bit tiff file returned by Adjust5. Irfanview is not even part of the workflow. May I ask which tiff library Adjust5 is linked to. That may help me find a viewer that can show the tiff file returned by Adjust5.

Thanks

(Edit) I re-checked in Windows64 Pro and the final result is,

  1. Both the jpg and the 16-bit tiff are readable by any picture viewer.
  2. The 8-bit tiff is dispayed as a black panel by all the picture viewers that come with Window10 as well as all the viewers I have in Linux. There is just one exception which I have described in an earlier post: a 2012 version of XV that is linked to an old libtiff can recover the picture and display the 8-bit tiff.

I report this problem to you for your own benefit since from my side I have now found some workarounds for my own use.

Cheers