According to the documentation at ./admin/settings/exif/general, the EXIF key "flash" is supposed to return a value like "9" (= integer). This is nonsense since "9" is not a valid value for the EXIF tag "Flash" (Code: 37385 (hex 0x9209)). When I'm extracting the "exif_flash" value into an text field, I'm getting something like "16" which is also nonsense because it should return a hex value.
According to the documentation, the returned values consist of 6 bits where
- Values for bit 0 indicating whether the flash fired;
- values for bits 1 and 2 indicating the status of returned light;
- values for bits 3 and 4 indicating the camera's flash mode;
- values for bit 5 indicating the presence of a flash function; and
- values for bit 6 indicating the camera's red-eye mode.
Examples: "Flash did not fire" should be "0000", "Flash fired" should be "0001". "0059" would be "Flash fired, auto mode, red-eye reduction mode", and "0019" would be "Flash fired, auto mode".
Greetings, -asb
Comments
Comment #1
rapsli commentedhttp://drupal.org/node/668688
Comment #2
asb commentedNo, this is not a duplicate, and I'm not sure if it's even related to #668688: Dates extracted are incorrect.
This issue is about data that seems to be not read correctly from the image file without interpreting it (extracting into a CCK text field).
Issue #668688: Dates extracted are incorrect is about a date value from the EXIF data, that doesn't go correctly into a CCK date field. This is by far more complex, other modules have major problems of getting data into date fields, also (e.g. #374346: Can't import date values into Date module fields). And - at least some - EXIF dates are written correctly into a CCK text field, so it might be a problem of parsing the date data correctly.
Greetings, -asb
Comment #3
rapsli commentedoky. I agree.
Well, I had a look at it. read_exif_data returns an integer value 9. Maybe this value needs some transformation. Maybe there's something wrong with read_exif_data ... Feel free to further dig into it. I'm willing to assist.
Comment #4
asb commentedI just hit the wall again with this. Just added a CCK field for "White Balance" (field_exif_whitebalance). According to
./admin/settings/exif/general, the return value is "0", an integer.What actually happens when saving a node with this new field: Node can not be saved because of fatal error:
Message logged in watchdog log:
So 'something' is expecting something else than integer.
According to the EXIF specification v2.2, it has to be an integer:
Very simple. it can be either "0" or "1". But 'exif' module can't use an integer field but breaks the site insted. Not cool :-(
It is even worse since several other EXIF values are broken the same way. I could reproduce this with, for example, with "LightSource" as well. It expects, according to the specification, integer values, and again kill Drupal when using a CCK integer field.
LightSource - Tag = 37384 (9208.H)
Comment #5
jphautin commentedDrupal 6 EOL