apache errors "wrong data type 7 for "RichTIFFIPTC""

[Ernie Gillis]

HI all!

I am recovering form a recent server issue (won't go into much more details, but will say it involved security stuff).

As I'm trying to decipher logs and such about what / where things happened, I came across errors unrelated to the issue I was experiencing.

My apache error log is filling with:

identify: /tmp/berklee-40329_OBJ.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory' @ tiff.c/TIFFWarnings/546.

The PID changes, but the errors are rather numerous.

The process at the moment of the errors is ingesting zipped files of TIFFs as a Islandora Newspaper type. The objects appear to ingest properly -- can check out the link for object I reference above [1]. i'm ingesting hundreds to thousands of files and there's the same error for each.

Any thoughts I how I could fix the error, and limit the size of my log files?

Thanks!!!

Ernie

[1] https://archives.berklee.edu/19870218-700pm-1a-our-thing-p01/40329

[Daniel Aitken]

Hey Ernie!

Afraid this one isn’t quite ‘fixable’, as far as I’ve been able to tell; had to dig into this a while back, and it seems to be a standards clash between libtiff and whatever was used to encode the original TIFF file; there’s a bit of info here: http://www.awaresystems.be/imaging/tiff/tifftags/iptc.html … but finding more info on this is a bit like pulling teeth. Basically, it’s grabbing tag information out of the TIFF, and finds a RichTIFFIPTC tag, and discovers that this tag has been given content using a data type that it doesn’t like (LONG instead of UNDEFINED or BYTE), and so it bails with a warning.

The best I can say is that either you could modify future TIFFs to have that specific tag stripped out - which is a massive pain - or you could lower the warning level for Apache, which is probably also not great? Or use a program to generate TIFFs that doesn’t incorrectly add RichTIFFIPTC tags using the LONG type, which, heaven knows how you’d even go about doing that.

The good news is that the error is pretty benign; it’s not going to affect anything, really. Just adds silly errors to the log.

- Something-or-other Dan

 

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
Visit this group at https://groups.google.com/group/islandora.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/e7347b9f-7401-41e9-8724-53c642f7f641%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ernie Gillis]

Good to know!

I'm not certain where to adjust this on the digitization workflow, yet. All the TIFFs were created via scanning into an iMac (scan app is specifically "ViewScan"). I may be able to tweak some settings in there -- as long as I make sure, for my own sanity, that it's adjusting metadata and not compression or quality.

Thank you for the feedback!!

Ernie

[Scott Henderson]

I have been perplexed by this issue for many years.  I work in the simulator industry, flight simulators and such, and I use photoshop to build the textures used in the 3D models on the simulator.  The "wrong data type 7 for RichTIFFIPTC" warning has been a thorn in my side for years.  As mentioned it is fairly benign but the warnings are obnoxious and in my case, critical warnings and/or errors can get lost in the mix if you're not paying close enough attention.  So today I decided to do some testing and get this issue resolved.  I have what for me is a good fix.

I won't bore you with the details but what I found is that if I take the offending tiff texture(s) and save them all out as .rgb format, which is the SGI format, and then save them back to tiff, the warning goes away on the new tiff files.

I have a Photoshop plugin that allows me to read and write .rgb files.  I think its fairly easy to find online.  My plugin asks if I want to compress the image when saving the rgb file.  My testing indicated that it doesn't matter but for mine I answered no to the question.  So far I not seen any image degradation from this process.

You could probably do the "conversion" of the images by recording the actions in Photoshop and running that action on your image directory.  I think the problem with that might be that the action recording function in Photoshop can't record mouse actions so whenever user input is required from the action you have to click the mouse.  That can get tedious if you are doing a lot images.

I have an application called "Hot Keyboard Pro" which is a macro recorder.  You just get the app recording, run through your repetitive task, mouse clicks and all, and save.  The recorded macro can the be run on whatever you want.  Using Hot Keyboard I was able to get it set up so that I could convert 250 images to rgb, then do the same thing writing them back to tiff all by itself.

 Now all of the nasty warnings are gone!!

My test case was set up to save every format available to photoshop.  When I ran the tests I did JPEG and BMP formats first and then I did the RGB format and it worked so I stopped.  There might be another image format that would work as well as RGB.

Hope this helps someone out there.

Scott

[Peter MacDonald]

We were getting the same error message ("wrong data type 7 for RichTIFFIPTC") in TIFF images coming back from a digitization agency we contractged with. They tracked down the problem to a utility they use "imagebuilder" that was writing a date/time stamp in a nonconformant way. They updated imagebuilder and the problem went away.

Peter MacDonald

Peter MacDonald
Library Information Systems Specialist
Hamilton College Library
315 859-4493
Skype: pmacdona-hamilton

--

For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
Visit this group at https://groups.google.com/group/islandora.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/88a8b159-91fc-4663-90ec-12ecda00d9ce%40googlegroups.com.

[Brad Spry]

The Apache Tika component within FITS decoded the Rich, proprietary metadata in our images and revealed huge amounts of color data. So much data was being output by Tika, it was ballooning our SOLR index (and annoying me). Such data is really obvious to see when inspecting your index documents within fedoragsearch. I ultimately disabled the Tika component within FITS due to this issue.

Brad

[p37]

We had a problem when ingesting jp2000's,  tika was filling our temp directory with tons of ocr and other data.  We disabled the tika component in fits and it stopped.

Also put a fits.log in and all other errors from fits stopped.  which was fine, but for some people who may not be used to a unix/linux command line where the command isn't actually finished until it comes back with a prompt, it caused some accidental interruption of ingests.  It looked done. :)

It would be kinda neat to have a "TECHMD was made on PID:xxx:nnn" message.  Disabling tika also sped up the fits part by several seconds.

Paul

UTK Digital Initiatives

On Thu, Sep 6, 2018 at 7:15 AM, Brad Spry <brad...@gmail.com> wrote:

The Apache Tika component within FITS decoded the Rich, proprietary metadata in our images and revealed huge amounts of color data. So much data was being output by Tika, it was ballooning our SOLR index (and annoying me). Such data is really obvious to see when inspecting your index documents within fedoragsearch. I ultimately disabled the Tika component within FITS due to this issue.

Brad

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.

To unsubscribe from this group and stop receiving emails from it, send an email to islandora+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/islandora.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/097bc95a-5912-4e57-94e9-ab41dd38c774%40googlegroups.com.