EXIF reading problems should be handled gracefully

[GoogleCodeExporter]

What steps will reproduce the problem?
1. import or refresh a picture with an exif problem such as described in
issue 22

What is the expected output? What do you see instead?
1 - I expect the picture's thumbnail to be replaced with a symbol telling
me there was something wrong 
2 - I expect the import or refresh to continue
3 - I expect a user-friendly way to have more informations about what the
problem is.

Instead, I get an error dialog (most up-to-date systems refrain from
displaying dialogs during batch operations) and the operation is aborted.

What version of the product are you using? On what operating system?
0.3.145 / Win XP SP3

Original issue reported on code.google.com by davito...@gmail.com on 9 Jan 2009 at 8:45

[GoogleCodeExporter]

I furthermore suggest that it would be nice to have a way to filter the "bad"
pictures, as they are often randomly placed acrose several albums and the only 
way to
find them currently is to browse the albums, which is of course quite slow.

Original comment by davito...@gmail.com on 9 Jan 2009 at 8:49

[GoogleCodeExporter]

It's a long/odd problem/feature too ;-)

Since 0.3, this trouble is minimized ...
because the use of exiv2 : there shouldn't have trouble about reading iptc tag 
anymore
since recently : there shouldn't have trouble about reading a bad utf8 comment
(always decode with replaing bad chars)
the only trouble which can come is the "exif flash value" ... because I can't 
find a
full list of values (vendors put what they want here ;-( ), and because we 
haven't
any fallback (except perhaps : even number -> flash off, odd number -> flash on 
...
but we must be sure of that)
so, in the near future (when we have got a fallback or a full list) : import 
troubles
should gone ... every pictures should be imported well in jbrout (and since 0.3 
: all
pictures with no exif work too !!!)

so 2 solutions :
- continue to fill our list of valid exif flash value (but can be hard/long)
- find a fallback for unknowns exif flash value

but in the future : import should always be fine ! so no need to "filter bad", 
or
implement a "continue dialog"

Original comment by manat...@gmail.com on 9 Jan 2009 at 12:40

[GoogleCodeExporter]

ok, good news. But I have dozens of pictures which jBrout imported without 
saying
anything but which show a zigzag or a cross instead of a thumbnail. I can't 
tell you
how many I have since precisely I don't have any way to sort them out. A few of 
them
can be corrected by asking for a thumbnail regeneration, but most of the times 
this
does not work. So I'd like to have a way to extract all the pictures jBrout 
considers
wrong and see if there is something I can do about them.

BTW, I doubt the flash tag update will solve my issue, 99.9% of my pictures were
taken without any flash. The one I sent you (A151_IMG.jpg) was taken without 
flash.
1/1000s at 100 ISO, I didn't need one ;-)

Original comment by davito...@gmail.com on 9 Jan 2009 at 1:00

[GoogleCodeExporter]

Maybe the solution is that Jbrout automatically add an IPTC tag (Invalid_exif 
for
example) to these incorrect pictures?

It will be really easy to implement and very useful (for me too, there was a 
lot of
pictures with cross and zigzag when i've load my pictures with v. 0.2). It was 
really
boring to select all these pictures and to reload thumbnail

Original comment by gautier....@gmail.com on 9 Jan 2009 at 1:11

[GoogleCodeExporter]

To davitofrg : The flash tag update issue happen even if pictures are taken 
without 
flash... Some combinations of flash/red eye/strobes etc... are not known by 
jbrout
and it cause the bug... This of course include combinations with no flash!

Original comment by gautier....@gmail.com on 9 Jan 2009 at 1:20

[GoogleCodeExporter]

fixed in r151

Original comment by manat...@gmail.com on 9 Jan 2009 at 4:00

• Changed state: Fixed