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

rapsli’s picture

Status: Active » Closed (duplicate)
asb’s picture

Status: Closed (duplicate) » Active

No, 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

rapsli’s picture

oky. 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.

asb’s picture

Version: 6.x-1.2 » 6.x-1.x-dev
Priority: Normal » Critical

I 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:

Fatal error: Cannot unset string offsets in /var/www/drupal/sites/all/modules/cck/content.module on line 1248

Message logged in watchdog log:

Warning: htmlspecialchars() expects parameter 1 to be string, array given in check_plain() (line 1152 of /var/www/drupal/includes/bootstrap.inc).

So 'something' is expecting something else than integer.

According to the EXIF specification v2.2, it has to be an integer:

WhiteBalance
This tag indicates the white balance mode set when the image was shot.

Tag = 41987 (A403.H)
Type = SHORT
Count = 1
Default = none
0 = Auto white balance
1 = Manual white balance
Other = reserved

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)

0 = unknown
1 = Daylight
2 = Fluorescent
3 = Tungsten (incandescent light)
4 = Flash
9 = Fine weather
10 = Cloudy weather
11 = Shade
12 = Daylight fluorescent (D 5700 – 7100K)
13 = Day white fluorescent (N 4600 – 5400K)
14 = Cool white fluorescent (W 3900 – 4500K)
15 = White fluorescent (WW 3200 – 3700K)
17 = Standard light A
18 = Standard light B
19 = Standard light C
20 = D55
21 = D65
22 = D75
23 = D50
24 = ISO studio tungsten
255 = other light 
jphautin’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)

Drupal 6 EOL