Can't import collection because of an error

[GoogleCodeExporter]

What steps will reproduce the problem?
1. add a folder to import
2. wait until the error dialog pops
3. see that nothing has been imported and that there isn't much you can do
about it.

What is the expected output? What do you see instead?
I'd like to have at least the name of the culprit. jBrout's way of
cancelling everything is already a PITA, but when jBrout doesn't even give
a clue to a solution, it is very difficult to bear!

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

Attachments:

• 2009-01-08_162024.png

[GoogleCodeExporter]

Sorry, I forgot the context: Windows XP Sp3, jBrout 0.3.145, previous versions 
of
jBrout completely removed before installing.

And it appears I was unfair: jBrout did not cancel everything, the user has to 
exit
and reload to see what has been accomplished (which is not very intuitive ;-) )

Original comment by davito...@gmail.com on 8 Jan 2009 at 3:35

[GoogleCodeExporter]

Please isolate the problematic picture ... and send me back (private mail)
so I could try to reproduce it here ... and correct the trouble

what is "culprit" ? what is "pita" ?

Original comment by manat...@gmail.com on 8 Jan 2009 at 4:43

• Changed state: New

[GoogleCodeExporter]

culprit: "coupable" in French. I was requesting that each times jBrout refuses 
to
import a file he displays the name of the file.

PITA: Pain In The Ass, which people often use when they are very annoyed but 
want to
believe they are still controlling their temper :-D In French, "casse-couilles" 
is a
good approximation.

As for sending the picture, this is precisely my main complaint. Is one of a 
folder
of 701 pictures. But I don't know which and finding that out is going to 
require a
little time :-(

Original comment by davito...@gmail.com on 8 Jan 2009 at 5:04

[GoogleCodeExporter]

Can't even import part of a folder. So I am going to have to create sub-folders 
and
move files in them and import them and so on until I find the one. This is 
definitely
going to take time.

Original comment by davito...@gmail.com on 8 Jan 2009 at 5:06

[GoogleCodeExporter]

Found one (but there are others) 

Original comment by davito...@gmail.com on 8 Jan 2009 at 5:25

Attachments:

• A151_IMG.JPG

[GoogleCodeExporter]

Here's one that fails for me.
Traceback (most recent call last):
   File "/usr/lib/jbrout/jbrout.py", line 2413, in on_btn_addFolder_clicked
    self.on_drop_folders_from_os(self.treeviewdb.get_model(),[folder])
   File "/usr/lib/jbrout/jbrout.py", line 1575, in on_drop_folders_from_os
    for nb in iterator:
   File "jbrout/jbrout/db.py", line 128, in add
   File "jbrout/jbrout/db.py", line 188, in __addPhoto
 Traceback (most recent call last):
  File "jbrout/jbrout/db.py", line 177, in __addPhoto
  File "jbrout/jbrout/tools.py", line 198, in __init__
  File "jbrout/jbrout/tools.py", line 556, in transform
  File "jbrout/jbrout/tools.py", line 264, in __refresh
UNKNow flash value : 4

It appears jbrout does not like the value of 4 for flash in the EXIF data.

(This used to happen all the time in 0.2 also, so I stopped using it.)

@davitofrg:  The error message gives me the name of the file (it didn't in 
0.2).  Or
maybe it's only certain errors?

Original comment by alexru...@gmail.com on 8 Jan 2009 at 5:39

Attachments:

• IMG_0785.JPG

[GoogleCodeExporter]

I agree often the error dialog displays the file name, but indeed in this case 
all I
have is the traceback.

Original comment by davito...@gmail.com on 8 Jan 2009 at 5:47

[GoogleCodeExporter]

should be corrected in rev 146

Original comment by manat...@gmail.com on 8 Jan 2009 at 5:56

• Changed state: Fixed

[GoogleCodeExporter]

I have checked, I have a nice collection of 45 more files where the issue 
appears,
and 60 more where it is probably present too.

Original comment by davito...@gmail.com on 8 Jan 2009 at 5:59

[GoogleCodeExporter]

nice!

Original comment by davito...@gmail.com on 8 Jan 2009 at 6:00

[GoogleCodeExporter]

I still experience this problem with v.148

/usr/lib/jbrout/jbrout/tools.py:271: DeprecationWarning: raising a string 
exception
is deprecated
  raise "UNKNow flash value : %d '%s'"%(v,self.__file.encode("utf_8"))
/usr/lib/jbrout/jbrout/db.py:188: DeprecationWarning: raising a string 
exception is
deprecated
  raise err+"\nPhoto has incorrect exif/iptc tags, can't be imported !!"
Traceback (most recent call last):
  File "/usr/lib/jbrout/jbrout.py", line 2439, in on_btn_addFolder_clicked
    self.on_drop_folders_from_os(self.treeviewdb.get_model(),[folder])
  File "/usr/lib/jbrout/jbrout.py", line 1601, in on_drop_folders_from_os
    for nb in iterator:
  File "jbrout/jbrout/db.py", line 128, in add
  File "jbrout/jbrout/db.py", line 188, in __addPhoto
Traceback (most recent call last):
  File "jbrout/jbrout/db.py", line 177, in __addPhoto
  File "jbrout/jbrout/tools.py", line 201, in __init__
  File "jbrout/jbrout/tools.py", line 564, in transform
  File "jbrout/jbrout/tools.py", line 271, in __refresh
UNKNow flash value : 88
'/home/gautier/Photos/2005/20050612_cricri_en_alaska/imgp0189.jpg'

Photo has incorrect exif/iptc tags, can't be imported !!

Original comment by gautier....@gmail.com on 9 Jan 2009 at 6:22

Attachments:

• imgp0189.jpg

[GoogleCodeExporter]

in fact, jbrout will crash for every unknow exif flash value
yesterday it was the 4 .. now it's the 88
THere is no fallback to default value ...

we must add value 88, and find if this 88 mean flash or not ...

Original comment by manat...@gmail.com on 9 Jan 2009 at 7:32

• Changed state: Accepted

[GoogleCodeExporter]

OK

The only thing really disappointing is that jbrout stops completly the 
import... I've
launch the import yesterday night, and today everything must be restarted! :(

Opening the picture with EOG, i have these informations : 
Flash did not fire, auto mode, red-eye reduction mode

Original comment by gautier....@gmail.com on 9 Jan 2009 at 7:50

[GoogleCodeExporter]

Take a look a that :

http://libexif.sourceforge.net/internals/exif-entry_8c-source.html

at 0h58 (88) -> Flash did not fire, auto mode, red-eye reduction mode

Original comment by gautier....@gmail.com on 9 Jan 2009 at 7:57

[GoogleCodeExporter]

oui, je cherche une liste exhaustive de ces codes
mais impossible à trouver

cependant, j'ai bien l'impression que quand le chiffre est pair : c sans flash
et impair avec flash ...

je rajoute 88 ce soir ...

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

[GoogleCodeExporter]

J'étais en train d'écrire le même message...

En fait, il y a une certaine logique, si on regarde, le red eye etc activé ou 
non
correspond toujours au même bit...

Mais après ce ne sont que des suppositions!

Original comment by gautier....@gmail.com on 9 Jan 2009 at 12:38

[GoogleCodeExporter]

switching back to english... 

I am not sure such a list exists. actually, manufacturers are known to create 
new
codes when they feel like it. So the only solution IMO is to handle gracefully 
an
unknown code, for example by displayihng it's hexadecimal value.

Original comment by davito...@gmail.com on 9 Jan 2009 at 12:51

[GoogleCodeExporter]

plus précisément, en binaire : 

00000000, "Flash did not fire."
00000001, "Flash fired."
00000101, "Strobe return light not detected."
00000111, "Strobe return light detected."
00001000  "Flash did not fire."
00001001, "Flash fired, compulsory flash mode."
00001101, "Flash fired, compulsory flash mode, return light not detected."
00001111, "Flash fired, compulsory flash mode, return light detected."
00010000, "Flash did not fire, compulsory flash mode."
00011000, "Flash did not fire, auto mode."
00011001, "Flash fired, auto mode."
00011101, "Flash fired, auto mode, return light not detected."
00011111, "Flash fired, auto mode, return light detected."
00100000  "No flash function."
01000001, "Flash fired, red-eye reduction mode."
01000101, "Flash fired, red-eye reduction mode, return light not detected."
01000111  "Flash fired, red-eye reduction mode, return light detected."
01001001  "Flash fired, compulsory flash mode, red-eye reduction mode."
01001101  "Flash fired, compulsory flash mode, red-eye reduction mode, return 
light
not detected."
01001111  "Flash fired, compulsory flash mode, red-eye reduction mode, return 
light
detected."
01011000  "Flash did not fire, auto mode, red-eye reduction mode."
01001001, "Flash fired, auto mode, red-eye reduction mode."
01001101  "Flash fired, auto mode, return light not detected,red-eye reduction 
mode."
01001111  "Flash fired, auto mode, return light detected,red-eye reduction 
mode."

Donc 
bit 1 : Flash (1-fired, 0-unfired)
bit 2 : Return light (1-detected, 0-not detected)
bit 3 : Strobe return light (1 detected, 0-not detected)
bit 4-5 : Compulsory flash mode/auto mode
bit 6 : No flash fonction (1)
bit 7 : red eye

Original comment by gautier....@gmail.com on 9 Jan 2009 at 12:53

[GoogleCodeExporter]

you don't trust : http://fr.wikipedia.org/wiki/M%C3%A9tadonn%C3%A9es_EXIF ?

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

[GoogleCodeExporter]

I thrust their good will. But I don't believe anybody has the power to enforce
anything. I mean, even if the IPTC creates rules, some manufacturers still 
market
APNs which use non-standard tags. Canon and Nikon were famous for this. 
Recently,
Canon has become more standard, but I don't know if Nikon has improved too. 
Anyhow,
if a manufacturer for example creates a new feature which was not in the 
standard,
what is he supposed to do? For example, the list you give says nothing about 
using an
internal or an external flash. I think this piece of information would be very
useful. So if a manufacturer wanted to say for example "external flash", he 
would
have to create a non-standard value and jBrout would crash again.

I suggest this list should be used, but if jBrout one day finds something which 
does
not fit (if someone raises bit 8), he should say something like "unknown value".

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

[GoogleCodeExporter]

I completly agree... But, even with new codes, I think (hope?) the meaning of 
the bit
1 won't change... and it's the only information used by jBrout no?

But I'm not familiar with Nikon and Canon... :)

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

[GoogleCodeExporter]

so ...

I will continue to use the current list to find flash or not
In case of an unknown value : I will test the bit 1 as gautier said, and it will
display a warning in the terminal output ...

no ?

Original comment by manat...@gmail.com on 9 Jan 2009 at 2:01

[GoogleCodeExporter]

Okay for me!

FYI, I've added the 88 value, and I've imported all my pictures (20000)... no 
errors...

Gautier

Original comment by gautier....@gmail.com on 9 Jan 2009 at 2:06

[GoogleCodeExporter]

You're doing it again :-D Can't you avoid dialogs? Ok, while developing or for 
your
own private usage dialogs may be fine. I developed an application which only 
does
heavy batch processing, a little like jBrout when importing, but not 
image-related.
When I run it in my IDE, I heavily rely on exceptions, breakpoints and dialogs 
for
alerting me of processing issues. But this application is run many times a day 
by
other users and at night too. Users would have laughed at me if unreadable 
dialogs
had sprung at their faces. And the system administrator would probably not have
thanked me if he had discovered that the night batches stopped at 01:12 AM 
because of
a still unreadable dialog. So I have a global flag which allows me to run my
application with dialogs or without dialogs. Without dialogs, my application 
just
writes the issue in a log file, skips the current element and resumes 
processing at
the next step.

"I will continue to use the current list to find flash or not" I don't know how
jBrout does this currently. Can you point me to the source where this done? 
Even if I
don't know python, I should be able to understand more or less... And who 
knows, it
may be the trigger which will finally (several years after my first intention) 
make
me bite the python bullet!

Original comment by davito...@gmail.com on 9 Jan 2009 at 2:16

[GoogleCodeExporter]

tools.py line 266

Mark said "display a warning in the terminal output"... There will be no dialog 
box
stopping the process!

Original comment by gautier....@gmail.com on 9 Jan 2009 at 2:23

[GoogleCodeExporter]

Ok. I keep forgetting that I'm speaking to GNU/Linux users! What will happen 
under
windows?

Original comment by davito...@gmail.com on 9 Jan 2009 at 2:26

[GoogleCodeExporter]

I've put these line, which should correct the issue

        try:
            v=int(self.__info["Exif.Photo.Flash"])
            # value taken from
http://209.85.129.132/search?q=cache:YYpAe4uzONgJ:gallery.menalto.com/node/55248
+exif+%22flash+value%22+95&hl=fr&ct=clnk&cd=3&gl=fr
            if v in (1,5,7,9,13,15,25,29,31,65,69,71,73,77,79,80,89,93,95):
                self.__isflash      = "Yes"
            elif v in (0,4,16,24,32,88):
                self.__isflash      = "No"
            else:
                if v%2: #impair
                    self.__isflash      = "Yes"
                else:
                    self.__isflash      = "No"
                print "UNKNow flash value : %d '%s', flash supposed fired :
%s"%(v,self.__file.encode("utf_8"),self.__isflash)
        except KeyError:
            self.__isflash    =""

Original comment by gautier....@gmail.com on 9 Jan 2009 at 2:29

[GoogleCodeExporter]

"tools.py line 266". Thanks. I did not understand everything, but at least I
understand why mantlan said "test the bit 1" :-D I agree this should be always 
work.

Original comment by davito...@gmail.com on 9 Jan 2009 at 2:37

[GoogleCodeExporter]

I have a big question!

Whats the use of self.__isflash?

Because if you set it to Yes or No, and looking to your picture in jbrout -> 
show
meta data, you can see the whole flash explanation

For example, you can see : Yes, Red-eye activated, auto even if you set isflash 
to "No"!

Original comment by gautier....@gmail.com on 9 Jan 2009 at 2:44

[GoogleCodeExporter]

Self._isflash is an attribut of a PhotoCmd instance. It's just to store the info
flash on/off.
All these photocmd attributs are stored in the db/xml (thru a photonode 
instance).
It's *JUST ONLY* for the "search system" to be able to search quickly if photo 
was
flashed or not.

"download plugin" use its own system (thru pyexiv2) to display REAL 
informations of
the picture !

Original comment by manat...@gmail.com on 9 Jan 2009 at 2:58

[GoogleCodeExporter]

fixed in r151

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

[GoogleCodeExporter]

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

• Changed state: Fixed