TIFF output uses legal, but non-standard encoding affecting metadata - IPTC

[Beep6581]

Originally reported on Google Code with ID 1590

16-bit TIFF (and maybe 8-bit, don't know) output apparently has a legitimate, but unusual
metadata (IPTC) encoding (LONGs instead of BYTES or UNDEFINED).  The impact is that
several programs, notably Neat Image, don't work well with TIFFs - after going through
Neat Image, IPTC information no longer shows in Windows Explorer.  When one subsequently
runs Neat Image output through IrfanView (for watermarking), the IPTC is completely
stripped.

So, my request(from Neat Image's support) is to have the TIFFs use a more-common (UNDEFINED?)
encoding for metadata.

My correspondance with Neat Image support:
"> Hi - TIFF in and TIFF out, 16-bit uncompressed. I have not tried JPG; I
> need 16-bit TIFF in the workflow to prevent banding.

> Batch queue, auto-match profile (profiles done against the calibration
> targets), output bitdepth set to "match input", "preserve image
> metadata..." selected. "filter presets" are "do not load preset(s)".

> That's all I can think of that might be relevant.

> Having said that, I just checked more carefully. From the Windows
> Explorer, the originals show data in "Tags", "Title", etc. while the
> converted files do not - which is why I wrote. And yet, when I look at
> the metadata with ExifToolGUI, the IPTC is there!

> Strange.

> Here is the image before NI, as seen in Explorer:

> Here it is after:

> When I run the NI image through Irfanview to resize / watermark, the
> IPTC disappears altogether - no longer visible in ExifToolGUI (which
> does not happen to the originals - they go through Irfanview with
> metadata fully intact).

I have downloaded the images, run them through my analysis
programs, through NI itself, also through Photoshop and found
the following:

1) the IPTC information in FALRD_20121004_0195.tif is encoded as
a set of LONG numbers (that is one of the data types supported by TIFF);

2) TIFF format normally uses other types of encoding to encode
the IPTC information, specifically UNDEFINED or BYTE
( http://www.awaresystems.be/imaging/tiff ... /iptc.html );

3) Neat Image did resave the IPTC information from the input
image (FALRD_20121004_0195.tif) to output image
(FALRD_20121004_0195_nr.tif), so the information is present there;

4) Because of (1), the IPTC information resaved by NI may be not
readable anymore in some TIFF readers.
The main reason is that to be readable at all times it would
need to be saved as suggested in (2) and for that the
original image should already have it in accordance with (2);

5) A simple test confirms that:

a. we take FALRD_20121004_0195.tif, open it in Photoshop
CS5.5, and re-save as FALRD_20121004_0195-PS.tif;
Photoshop re-saves the image with the IPTC information
encoded using the UNDEFINED type.

b. we then open FALRD_20121004_0195-PS.tif in Neat Image, process
the image and save the output image as FALRD_20121004_0195-PS-NI.tif;

c. the resulting image does show its IPTC details in Windows
Explorer and in other TIFF readers.

So it looks like the simplest solution would be to resave the
TIFFs using an application that re-saves IPTC using the UNDEFINED type.
For example, Photoshop CS5.5. I think other PS versions should
work similarly.

The next most simple solution would be to change the software
that created the original TIFF (RawTherapee?), perhaps to use
another software. Or the software used to edit those IPTC
fields, if it is different than the original saver of the TIFF.

The next option would be to fix RawTherapee itself (its authors
could do that).

Hope this helps,
Vlad
"

Click on Preferences > About > Version and paste all that here.
Branch: default
Version: 4.0.9.50
Changeset: ca684d56e7d7
Compiler: GCC 4.6.1
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V2.22.0
Build type: RELEASE
Build flags:  -mtune=generic -O3 -DNDEBUG
Link flags:  -mtune=generic -mwindows -s
OpenMP support: ON
MMAP support: ON

Operating system (e.g. winXP-32bit, Ubuntu-11.10-64bit):
Win 7 64-bit, fully patched as of 2012-10-10

The problem is reproducable, so I don't think we really need an image, but here are
two anyway:
http://www.comrace.ca/temp/FALRD_20121004_0195.tif (direct output)
http://www.comrace.ca/temp/FALRD_20121004_0195_nr.tif (after Neat Image processing)

Reported by aaronburns@comrace.ca on 2012-10-11 13:32:30

[Beep6581]

For your information, i'm trying to finish ASAP the XMP branch (if all goes well, before
Christmas). I guess that i'll be able to use Adobe's XMP SDK to create the metadata
for TIFF output, so this issue will be solved.

But if it can't wait, another dev may look at it and fix it now (maybe it's a trivial
bug, i don't know).

Reported by natureh.510 on 2012-10-16 22:54:08

• Status changed: Accepted
• Labels added: Priority-Medium, OpSys-All
• Labels removed: Priority-Low

[Beep6581]

Hombre, this will be absolutely invaluable! Please let me know when you need help in
testing, etc.

Reported by michaelezra000 on 2012-10-16 23:21:39

[Beep6581]

Okay, the XMP branch will be... erm... a little bite postponed. As an immediate fix,
we could convert the strings to utf-8 using functions from libiptcdata, but as stated
in their documentation, not all software will understand them (e.g. Picasa).

We could convert the Glib::ustring to local prior dumping them into the jpg/tiff file,
but i'm not sure if it will be okay for all languages (i guess no).

Reported by natureh.510 on 2013-01-20 22:26:54