libtiff gives us warning with some tags "unknown field with tag...... encountered". To solve this we have found through google way through adding tag definitions for the tags reported as unknown (http://libtiff.maptools.org/addingtags.html). It says include the tag in tiff.h and tif_dirinfo.c. We did that and the libtiff still report this warning. I have found out that three of the reported tags already were in tif.h and tif_dirinfo.c even before we started to change it. And still the libtiff report them.
They are mostly exif tags. I tried to insert to tif image by exiftool another exif tag, which is defined in tif.h and tif_dirinfo.c, just to check if the libtiff works well with other defined tags and this tag was o.k. with libtiff, without warning.
Could you please share if you have ever met this problem and how have you solved it? Or any suggestions?
The reported tags are 34858, 36867, 36868,37393, 37510, 40091,40092,40093,40094,40095,40961,65001.
Tags 368687,36868, 37510 and 40961 already have definitions there, but libtiff keeps reporting them as unknown.
Thank you
Related
I'm creating a project to mail merge a given .odt file and provide a .odt output. When i'm performing the mail merge operation it provides me this error
TinyButStrong Error in block's definition [CiviCRM.display_name...]: at least one tag corresponding to w:tr is not found. Check opening tags, closing tags and embedding levels.
Myfilecontent.odt
[CRM. display_name;block=w:tr]
Date: 2/3/2020
Dear [CRM.postal_greeting;block=w:tr],
Thank you for joining the event...
I have no idea how to resolve this. could someone help me to solve it?
Thanks in advance!
Update
After i replaced w:tr with tbs:row, still I'm receiving a similar error
TinyButStrong Error in block's definition [CRM.display_name...]: at
least one tag corresponding to tbs:row is not found. Check opening
tags, closing tags and embedding levels.
w:tr is an XML entity for Ms Word , not ODT.
You should use the alias block=tbs:row so that its is format independent.
I am trying to write a new value for a XMP tag using exiftool but for some reason the tag is not being recognized.
Reading the field works:
exiftool -PropertyId /Users/user/test.jpg
Property Id : 17934
But when trying to write a value for PropertyId tag, does not work.I did try also to use -xmp:PropertyId but I get the same result:
exiftool -PropertyId=12345 /Users/user/test.jpg
Warning: Tag 'PropertyId' is not defined
Nothing to do.
Exporting the metadata shows that the field is there: (I only copied the xmp section)
exiftool -xmp -b -a /Users/user/test.jpg > data.xmp
...
<rdf:Description rdf:about=''
xmlns:xmp='http://ns.adobe.com/xap/1.0/'>
<xmp:Brand>Brand Name</xmp:Brand>
<xmp:CreateDate>2015-07-08T11:45:21</xmp:CreateDate>
<xmp:CreatorTool>CreatorTool</xmp:CreatorTool>
<xmp:FacilityName>The Restaurant Name</xmp:FacilityName>
<xmp:MetadataDate>2015-09-14T13:12:51-06:00</xmp:MetadataDate>
<xmp:ModifyDate>2015-09-14T13:12:51-06:00</xmp:ModifyDate>
<xmp:PropertyId>00000</xmp:PropertyId>
<xmp:PropertyName>Property Name</xmp:PropertyName>
<xmp:ShootDate>2016-03-12</xmp:ShootDate>
</rdf:Description>...
I am missing something? Test file is here: test.jpg
Exiftool cannot edit metadata it does not have a definition for, as it is in this case. In fact, your example XMP shows a lot of tags which it says are part of the "xap" group but are not actually part of that (very old) standard, including Brand, FacilityName, PropertyName, and ShootDate. You'll find that none of those are directly editable by exiftool. Probably not by any other program except the one that originally wrote it.
If you want exiftool to be able to write those tags, you'll need to create definitions for those tags. See the ExifTool Example Config file for details.
Also take note, as I said, "xap" is a very old standard and has long since been replaced. Exiftool will update the tags it does know to the newer standards. For details see the XMP xmp tags entry.
I've been asked to look at C# code that's returning the following error:
Unable to cast object of type
'iTextSharp.text.html.simpleparser.IncCell' to type 'iTextSharp.text.Rectangle'.
at iTextSharp.text.pdf.PdfDocument.Add(IElement element)
at iTextSharp.text.Document.Add(IElement element)
It looks like they're using iTextSharp v5.0.2 and have not yet moved from HtmlWorker to XmlWorker.
Questions:
What is IncCell? I see it in the source docs but can't find any info about what it is - I'm assuming it's just for internal use.
Is this related to a cell in a table? A need for a Div or Paragraph within a cell?
What can they do to diagnose issues like this down to the HTML source that caused the error? I suspect this is an issue with not conforming to XHTML, but I can't verify that without knowing exactly what IElement that code was working on when it choked. It could be due to bad styling too, I have no idea at this time. Is there any kind of detail logging that will tell us what element is being processed at any given time? Should I just get them to load source and trace through it?
Is it probable that this will be fixed with an update to the latest version (currently 5.5.9), and a re-fit of XmlWorker?
Other recommendations?
Thanks!
In MATLAB I used to go:
info = imfinfo('image.jpg');
iso = info.DigitalCamera.ISOSpeedRatings;
And that's it. Octave has an imfinfo function that reads many parameters from the image header, but apparently not the ISO speed. That looks strange to me (why would it read dozens of params and let out ISO speed?).
Is there something I am missing?
Example image is here, shot with a DSLR (as you can see with imfinfo). With MATLAB, I can clearly see that imfinfo('image.jpg').DigitalCamera.ISOSpeedRatings is 200.
tl;dr
The value you want is under the field PhotographicSensitivity. Use:
iso = imfinfo ("image.jpg").DigitalCamera.PhotographicSensitivity;
See Octave bug #47706.
Octave only considers tags that follow Exif version 2.3.
Workaround
Old versions of the Octave image package had a function readexif (the function was deprecated in image package version 2.2.0 and removed in version 2.4.0) which may be able to read them. The last version to include that function was 2.2.2
Discussion
The details you are accessing are the EXIF values on your image file. Basically, there's a table on your file that maps tags, such as ExposureTime or FNumber, to their actual values. However, the tag names are not encoded in the file. Instead, each tag has an integer value e.g., ExposureTime or FNumber will appear as 33437 and 33434 respectively. It's the job of a program/library to map those integer values to the tag name.
The tag you are looking for, ISOSpeedRatings is not a valid EXIF tag per the EXIF specs version 2.3 (the latest specs, released in 2010). It was renamed to PhotographicSensitivity. If you read the specs under that tag, you will find this note:
Note that this tag was referred to as “ISOSpeedRatings” in versions of this standard up to Version 2.21.
If you read even more of the specs, you will find the following explanation on Annex G:
[...] the PhotographicSensitivity tag whose ID was 34855 was previously referred to as ISOSpeedRating, which, in reality, led to confused interpretations of sensitivity that resulted in many recordings that differed from ISO speed as defined under the ISO 12232 standard.
And if you read even more of the specs, you will notice that the meaning of the value with the tag 34855 was slightly changed when its name changed. This means that it's not only a tag name issue, its meaning is different if your camera follows a different version of the EXIF specs (assuming that your camera recorded it correctly, remember that the reason for the change was that cameras were recording the wrong thing).
I'm not sure what is the right technical answer. I'm guessing a program should check the recorded ExifVersion (which is the EXIF tag 36864) and change the tag names according to that.
Edit
Octave uses GraphicsMagick to read images, including its metadata. GraphicsMagick does not accept the EXIF tag numbers, programs need to query using the tag names. Octave then has a hardcoded list of tag names but only includes the tags for Exif specs 2.3. It seems that GraphicsMagick recognizes your file is an older version of Exif and names the tag old way which Octave does not ask for.
I did the following and can now use readexif from 2.2.2 in image 2.6.1:
Download Image 2.2.2 as suggested earlier in this thread
Add the readexif.m from Image 2.2.2 among image 2.6.1
Reload package pkg load image
Now you can call readexif. To get ISOSpeedRating:
readexif(JPGPath).Exif_IFD_Pointer.ISOSpeedRatings
What might cause
new Font(Font.HELVETICA, 11f, Font.BOLD)
or
BaseFont.createFont(BaseFont.HELVETICA, 'Cp1252', BaseFont.NOT_EMBEDDED)
to start returning the following??
com.itextpdf.text.DocumentException: No message found for 1.not.found.as.resource
itext 5.5.6 jar on Max OSX 10.10
It seems that you are not using the "pre-canned" jar, but that you have created your own jar. That self-made jar only contains the Java class files. It misses resources such as the language (.lng) and the Adobe Font Metrics (.afm) files.
If the above assumption is wrong, then at least this is right:
Instead of the actual error message, you get the key to an error message that is stored in a .lng file: 1.not.found.as.resource. This key is used to find the actual error message in the language of your OS (English, Dutch and Portuguese are supported; the default is English).
The actual error message (should en.lng be found) would have been: "Helvetica not found as a resource" (the 1 in 1.not.found.as.resource is a placeholder). This message tells you that the file Helvetica.afm can't be found. This file contains the metrics of every glyph in the font Helvetica (regular). Without those metrics, you can't create a proper PDF.
This explains what happens. Your question doesn't contain sufficient information to explain why it happens. All of this shouldn't be a problem when using the correct jar with a JDK that knows how to read resources from a jar. The fact that you write "What might cause ... to start returning the following" indicates that it has worked for you before. Think of what you have changed between the last time it worked and the first time it stopped working (e.g. changing the OS, changing the JVM,...). That will probably be the culprit.