-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TIF metadata field count #65
Comments
@ben-manes I don't know the details regarding how icafe is used in your case: did you generate tiff with icafe? manipulate it with icafe or other. The specific tiff field with name DateTime is a ASCII field and the count is expected to be 20 with the format specified by the specification. When reading the tiff field, icafe will follow the field type and count without any assumption. So if the field for DateTime with a length different than 20, it will read to the length. In this case, if the discrepancy is only for the DateTime field, it will not propagate to other field thus ruin all the other fields. In your case, if after the DateTime field, the process still can read correct tiff field instead of garbage, it is an indicator that the DateTime field itself is a bit off track and no big deal for the other part of the image, otherwise, something could be wrong with the whole image/the reader. Hope this explains something. By the way, I didn't see any part icafe will write this field to the tiff create by it but very probably it will copy the same field to some kind of output image when it is used in other ways than generate tiff itself - like split, merge, etc. Wen |
I think that you write it in TIFFWriter.java#L487. The image is fine and wasn't a problem. In our case we have to create multi-page TIFFs for integrations with legacy products that our customers own. Our usage is very simple, but they are finicky given they are often using mainframe or similarly aged products. The source images are downscaled JPEGs that were originally taken on a mobile phone (jpeg), sent as webp to reduce the byte size, transformed (cropped, white balanced, etc) and converted back to jpeg for browser compatibility. Most of those transformations are done using opencv Java bindings. When sending to external systems, they often require TIFFs and we use icafe for that step.
|
@ben-manes you know icafe more than me now! I vaguely remember wrote that somewhere and did a search this morning but didn't find it! Interesting. I will take a look at that part and related things to see if I need to enforce something. Great find. Thank you. By the way, which part of the application code logged that warning? I guess it's not icafe. |
I have no idea. The partner sent that screenshot and mentioned poor quality
due to the group4 conversation they require. I just forwarded this along in
case it helped you somehow.
…On Tue, Jan 9, 2018 at 10:23 AM dragon66 ***@***.***> wrote:
@ben-manes <https://github.com/ben-manes> you know icafe more than me
now! I vaguely remember wrote that somewhere and did a search this morning
but didn't find it!
Interesting. I will take a look at that part and related things to see if
I need to enforce something.
Great find. Thank you.
By the way, which part of the application code logged that warning? I
guess it's not icafe.
Wen
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#65 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXG9rvAbbltSh1tylQOQMmNT8YGhBXQks5tI66cgaJpZM4RXNDs>
.
|
I took a look at the DateTime formatting in TIFFWriter and checked with the tag format requirement, looks like I added a time zone there which does make sense but that caused the field length to become 24 instead of 20. I have checked in the fix. |
Thanks a bunch for all your hard work and quick responses on this library :) |
An integration partner shared this screenshot of warnings. I don't think its blocking, as the issue was regarding increasing our default DPI setting, but thought you should know in case there is an offset mistake somewhere.
The text was updated successfully, but these errors were encountered: