Closed mschnell1 closed 3 weeks ago
Do you have an example where 0.5.1 recognizes EXIF data but 0.6.0-beta1 doesn't?
OK.... ... searching...
Here you are... It works correctly with pre 0.6: No problem with ThumbsPlus seeing the old and new Exif Tags. With Beta.1, this does not create an error message when reading , but the written Exif is not recognized by ThumbsPlus. ThumbsPlus even does not recognize the oientation and shows the picture 90° turned. Picture and Exif Is correctly shown by Explorer "Detrails".
www.bitvibe.de/Upload/ds218351.jpg
And all you do is change the image description, i.e.
let mut data = Metadata::new_from_path(path).unwrap();
data.set_tag(
ExifTag::ImageDescription("Test".to_string())
);
data.write_to_file(&path);
?
Exactly:
let mut file_content = fs::read(&source_file_path).context(source_token.source.clone())?;
let mut metadata = Metadata::new_from_vec(&file_content, file_extension)?;
modifying ImageDescription
by
metadata.set_tag(ExifTag::ImageDescription(source_token.token.clone()));
metadata.write_to_vec(&mut file_content, file_extension)?;
write file by
fs::write(target_p, file_content)?;
unfortunately I need to do
let file_extension = get_file_type(&source_file_path).unwrap();
twice, as it can't be passed by reference. Does this might introduce a problem ?
Edit: I just saw that FileExtension now derives Clone. I updated my code, but I don't suppose that this does make a difference.
I have a new suspicion. This
ThumbsPlus even does not recognize the oientation and shows the picture 90° turned. Picture and Exif Is correctly shown
sounds like that the metadata (not just EXIF but all of the IFD stuff) has been corrupted in a way that ThumbsPlus is unable to read it, as this also includes things like the orientation. This can be caused by little_exif in case some tags require special care (e.g. they have additional offset data that doesn't get processed yet).
Going through the tags in your example file I found 0x0201 and 0x0202 - tags that are related to thumbnail image data, with 0x0201 being the offset to the thumbnail. Now, if the EXIF data gets changed in length (very likely in case of updating the image description), the offset to the thumbnail needs to be updated as well, which I haven't accounted for previously.
The new 0.6.0-beta2 should fix this. Please let me know if this has any effect on your example image and the way it's oriented in ThumbsPlus.
The "assertion" panic I described before does not happen any more ! Great.
But, Sorry, I don't see a difference regarding ThumbsPlus here. ThumbsPlus does not see the EXIF in many files (more than with 0.5.1.), and even (other than with 0.5.1shows some picture side-wise)
I understand that this mainly happens when LittExif claims it does not understand the Exif information and goes e.g.:
Error during decoding: Custom { kind: Other, error: "No EXIF data found!" }
WARNING: Can't read metadata - Create new & empty struct
Hence the resulting metadata don't contain anything inherited.
Seemingly ThumbsPlus does not like the Medatata that only contain a single ImageDestription
tag.
Of course I did test what happens if I have Lutte_Exif create more tags, but no change.
But e.g. ds218351 which did keep the original EXIF tags and is decoded correctly by Thumbsplus after being written by 0.5.1, is not decoded by ThumbsPlus and shown side-wise after being written by 6.0-beta.2, even if little_exif does not complain and the other Exif tags seem to be in place.
The "assertion" panic I described before does not happen any more ! Great.
Good to hear.
I understand that this mainly happens when LittExif claims it does not understand the Exif information and goes e.g.:
Error during decoding: Custom { kind: Other, error: "No EXIF data found!" } WARNING: Can't read metadata - Create new & empty struct
Do you have an example where 0.5.1 is able to detect the Exif information and 0.6.0-beta.2 can't?
But e.g. ds218351 which did keep the original EXIF tags and is decoded correctly by Thumbsplus after being written by 0.5.1, is not decoded by ThumbsPlus and shown side-wise after being written by 6.0-beta.2, even if little_exif does not complain and the other Exif tags seem to be in place.
So, just to clarify: The result of processing ds218351 with 0.5.1 is perfectly fine (upright), but using 0.6.0-beta.1 or .2 produces an image that ThumbsPlus displays sideways? Strange.
Based on another idea (that is related to the order of writing IFDs to the file) I updated the encoder again in 0.6.0-beta.3. If this has any effect on picture orientation please let me know.
Also, what version of ThumbsPlus are you using? Then I can try to install that locally for these testing purposes.
Do you have an example where 0.5.1 is able to detect the Exif information and 0.6.0-beta.2 can't?
I believe I have many. I'll do a search ASAP.
So, just to clarify: The result of processing ds218351 with 0.5.1 is perfectly fine (upright), but using 0.6.0-beta.1 or .2 produces an image that ThumbsPlus displays sideways? Strange.
Yep
I'll upload the results...
Also, what version of ThumbsPlus are you using? Then I can try to install that locally for these testing purposes.
Unfortunately the company "Cerious" does not exist any more. I suppose I have an installation file...
AFAIR, same provides a 30 day trial.
www.bitvibe.de/Upload/8890_ds218351_beta.jpg www.bitvibe.de/Upload/8890_ds218351.jpg
Do you have an example where 0.5.1 is able to detect the Exif information and 0.6.0-beta.2 can't?
Sorry that seems to be a wrong impression of mine.
Do you have an example where 0.5.1 is able to detect the Exif information and 0.6.0-beta.2 can't?
I believe I have many. I'll do a search ASAP.
Sorry that seems to be a wrong impression of mine.
Ok, then I'll assume that 0.5.1 and 0.6.0 detect the same Exif information for now until a counter-example comes up.
So, just to clarify: The result of processing ds218351 with 0.5.1 is perfectly fine (upright), but using 0.6.0-beta.1 or .2 produces an image that ThumbsPlus displays sideways? Strange.
Yep
I'll upload the results...
Okay, and what about beta3? The uploaded image seems to be the result of beta1 or beta2.
Also, what version of ThumbsPlus are you using? Then I can try to install that locally for these testing purposes.
Unfortunately the company "Cerious" does not exist any more. I suppose I have an installation file...
Let that be my problem. Just want to know if it's version 7, 8, 10, ...?
I'll try Beta 3 ASAP (some hours...) I'm using Tnumbs Plus v 10. supposedly the latest that had been released.
Suggestion for a possible cause of problems (e.g with thumbsPlus) :
ImageDescription
of the original file contains one or more newline ("\n") characters. Suggestion for a possible cause of problems (e.g with thumbsPlus) :
- The Exif data contain a thumbnail and hence is huge
- the
ImageDescription
of the original file contains one or more newline ("\n") characters.
How did you come up with these two suggestions? Are they based on your collection of images and how "working" images differ from "non-working" ones?
Something you could try for both of these cases (assuming you haven't tried this already) is to simply read in the exif information from a file and immediately writing it back to the file without changing e.g. the ImageDescription.
With Beta.3 no Error Message by Little_Exif with www.bitvibe.de/Upload/2017_aachen_abendhimmel_emilio.jpg
but with www.bitvibe.de/Upload/2017_isernhagen_sorento_1.jpg
I still get
Error during decoding: Error { kind: UnexpectedEof, message: "failed to fill whole buffer" }
How did you come up with these two suggestions? Are they based on your collection of images and how "working" images differ from "non-working" ones?
Not really, there are some 100 from some 1000 that don't "work". The ones that do fail and that I did check seem to have the said properties.
Something you could try for both of these cases (assuming you haven't tried this already) is to simply read in the exif information from a file and immediately writing it back to the file without changing e.g. the ImageDescription.
I'll try to find out ASAP....
WOW !!!!! With Beta.3 no obvious problems regarding ThumbsPlus any more. It always sees the ÌmageDescription` written by GREAT_Exif.
I'll check if the files Litte_Exif refuses to decode really don't feature EXIF information ASAP ....
One weird thing:
some pictures (supposedly all from the same original source/Camera) show a Comment
(AKA "Annotation") as three exclamation marks
in ThumbsPlus. Explorer Details shows the correct 'Image Descriptionas
title`(and no exclamation marks whatsoever.
In the file there indeed is a "!!!" string somewhere. The original file does not contain such a string.
I did check my software but did not find any hint of three exclamation marks.
I tested that several files reporting Error during decoding: Custom { kind: Other, error: "No EXIF data found!" }
do feature exif information, at least ThumbsPlus reports a comment
and Explorer Details a Titel
moreover with some files, I get
Error during decoding: Error { kind: UnexpectedEof, message: "failed to fill whole buffer" }
and a huge lot if times:
Illegal endian information!
(new with beta.3 ? )
also with some files:
Could not decode SubIFD GPS:
Illegal format for known tag! Tag: GPSAltitudeRef("") Expected: STRING Got: INT8U
Should I do dedicated issues for these - even if it's a Beta right now ? Let me know for which issue you need more examples.
With Beta.3 no obvious problems regarding ThumbsPlus any more.
That is great to hear :-)
Should I do dedicated issues for these - even if it's a Beta right now ? Let me know fro which issue you need more examples.
I'll create issues based on your comments with what information is required for further investigation.
I get e.g. this messages by Little_Exif:
Error during decoding: Custom { kind: Other, error: "No EXIF data found!" }
I did provide several files that showed that behavior
But with Beta.1 it seems than many more files are affected.