To try the thousands of add-ons available here, download Mozilla Firefox, a fast, free way to surf the Web!Close
Welcome to Firefox Add-ons.
Choose from thousands of extra features and styles to make Firefox your own.Close
Be careful with old versions!
These versions are displayed for reference and testing purposes. You should always use the latest version of an add-on.
- Fixed the same bug as in 0.4.8.1 which caused the FxIF Data context menu entry to be disabled if the URL doesn't contain jpg, jpeg or similar. Reason was the necessary recovery of an older backup, sigh.
- Some piece of software unfortunately leaves out the pascal string from the 8BIM header of binary IPTC data. By this the IPTC properties is shifted and confuses decoders (also the phantastic exiftool). FxIF now has an additional plausibility check and a mechanism to recover from the problem. Many thanks to Oleg V. Samsonov for reporting.
- There are images containing invalid offsets for branches to EXIF sub directories. In the case at hand it’s offset 0, but others are possible. Therefore I now added various checks in different places against something like that. Many thanks to Alice Cheung for reporting.
- Some images contain EXIF UserComments consisting purely of null bytes. And these comments have been displayed as such. Hm, I changed the handling of null bytes in strings for version 0.4.6. But for an other fix I implemented a similar function and accidentally used the new instead of the old in one place. Now the right function is used. Thanks again to Dennis van den Broek for reporting.
- At least one piece of software doesn’t write EXIF attributes in XMP format as specified but in full human readable form. E.g. for exif:FNumber not „35/10“ but „f/3,5“, for exif:ExposureProgram even „Zeitautomatik“ instead of „4“ . FxIF now checks the format the value is in. If it isn’t, the value won’t be interpreted but used 1:1 — but only if the property hasn’t been filed, e.g. from binary EXIF property. Many Thanks to Heino Tiedemann for reporting and the test image.
- The EXIF value DigitalZoomRation was never displayed when contained as XMP value although it should have been. It’s now displayed if > 1.
- A test to protect against reading an array does indeed work, but led to canceling the whole evaluation and reported a heavy error to the user. For there’s no sensible workaround, I lowered the severity of this error and it now simply ignore the value which would lead to reading outside the array. Many Thanks to Heino Tiedemann for reporting and the test image.
- Removed a workaround in the codebase which (as stated) “Fixes strange encoding on some older digicams.” and multiplies every ISO value below 50 by 200. This came from the jhead tool which FxIF was based on. The workaround was removed there with version 2.97. That bug was also reported as Issue 22.
- Fixed Issue 23: For Images in which the time of creation (field TimeCreated in the binary IPTC data) contains no time zone information no time information was output at all. This comes from tightly following the specification in which time zone information is mandatory. In the new version this information is optional. If it isn’t contained, the output contains a note. The same case has been fixed for time informations in the XMP data.
- "Fixed" Issue 19: Deactivated alerting the user on parse error of the XMP document. There is no workaround I know of as long as FxIF is using Mozillas DOM parser. And I don’t want to go implementing my own.
- Exception occured when there was an empty GpsImgRef field in EXIF or XMP or if it was other than M or T.
- Fixed Issue 17: Endless recursion if Exif Interoperability Offset or Exif Offset point to a directory that has been processed before. It’s similar but more complex to Issue 10 which has been fixed in FxIF 0.4.3.
- Fixed a bug that had the effect that the creator data (formerly photograph) wasn't shown anymore. I renamed a variable in one place instead all occurences. Many thanks to Oliver Theobald for finding the bug.
- In at least one image the ISO value isn’t contained as integer, as it's specified, but as string. FxIF nevertheless handled it as integer, bailed out and so the rest of the data wasn't evaluated. So for this and another field where this might happen too I added a workaround. Many thanks to Aaron Gullison for finding the bug.
- Evaluating the EXIF fields Aperture and MaxAperture was wrong – and that at least since version 0.2.3. I assume an error in porting the relevant code from Jhead (which is written in C). Different from the field FNumber the value isn’t used directly but computed using a formula which I don’t pretend to understand, neither the reason for using it, but ported correctly the result is the expected one. Many thanks to Babar de Saint Cyr for finding the bug.
- According to the EXIF 2 specification the EXIF field UserComment offers the posibility to encode the string in ASCI, JIS, UNICODE and self defined coding. Until now FxIF just interpreted everything as ASCII and only displayed the character code in case of other codings. Now FxIF understands ASCII and UNICODE for this field. In case of other codings the content will be displayed as ASCII string. Many thanks to Babar de Saint Cyr for finding the bug. That bug was also reported as Issue 20.
- Fixed a bug in interpreting Canon Maker Notes. FxIF used the byte order of the EXIF fields for it but it seems Canon Maker Notes are always in Intel byte order (Little-Endian).
- Fixed another bug in interpreting Canon Maker Notes. It seems there exists software which moves Maker Notes within the image file, modifying the pointers into that block, but not the offsets within the Maker Notes. Because of this FxIF now adjusts those offsets using the Maker Notes Footer. Thanks to Phil Harveys Image-Exif-Tools for this insight.
- Preferences used by FxIF are now added to the sync whitelist. That means the FxIF options now get synced using Firefox-Sync.
- FxIF now stops reading strings if encountering a null byte. Until now the given number of chars where read and a null byte just filtered. Thanks to Dennis van den Broek for providing the sample image that uncovered that bug.
- FxIF now interprets the direction the camera pointed if that information is present. Thanks to Dennis van den Broek for providing the sample images.
- Fixed a bug which caused the browser to hang hard. Thanks to Radek Docekal for notifying.
- Fixed a bug which displayed a FxIF Data window with all fields but without any data. It was triggered by images using a <map>. Thanks to Joop Nijenhuis for notifying.
- If the mapProvider pref isn’t set, a default is used but wasn’t filled in the corresponding input field in the options. This is now done.
- Among the fields evaluated for the designation of the software used for creating the photo is the XMP field CreatorTool. When present it overwrote the value in the EXIF field Software. But CreatorTool only contains (at least following the specification) the software used for originally creating the photo, not the last version (like it should in the EXIF field Software).<br/>
So now also the field softwareAgent (in the History list) is evaluated and its last list entry is used for displaying the software. Also the field CreatorTool is only used if the EXIF field Software isn’t present.
- More lens information are read from Canon Maker Notes.
- Reading of informations about lens (from binary Exif, XMP data has already been read in the past) and used software.
- Dropping Support for the old Mozilla Suite. It’s dead for quite some time and no one should use it for his or her own good anymore anyway.
- At least in Gecko 2 (Firefox 4, SeaMonkey 2.1) the XML parser became picky about non-ASCII characters not correctly encoded as UTF-8 or Unicode. Some images do contain such documents which violate XMP specification (and actually XML specification too). I inserted a workaround which makes a second try after converting non-ASCII characters. This can lead to wrong display of such chars in buggy files, but they’re at least parsable this way.
- Ctrl+W, resp. Accel+W now closes FxIF’s own dialogue (like Esc already does since version 0.4).
- FxIF’s own window now behaves like when the data is shown in the browsers own property window (resp. that of the Element-properties extension). I.e. it’s now possible to have multiple FxIF windows open in parallel instead reusing one.
- Improved IPTC date handling: If IPTC only contains either date or time, only use it if there’s no date already set.
- JFIF comments are now displayed
- Added new translation for Turkish thanks to contributor omrakin on BabelZilla and polish translation is included again.
- Fixed some reads which were to optimistic on the bytes contained in a JPEG marker which could lead to negative byte counts tried to be read (and causing the stream reader to bail out). Thanks to Jemini for reporting.
- Fixed a bug preventing to catch and report it the aforementioned bug correctly to the user.
- Fixed Issue 4: ”Copy“ button does not copy GPS coords.
- Fixed Issue 5: EXIF tag Orientation with unknown value caused FxIF to bail out.
- Fixed Issue 6: Dates from binary EXIFs where copied verbatim containing colons as separators. These are now replaced by hyphens to match the date formatting for binary IPTC and XMP dates (YYYY-MM-DD as recommended in ISO 8601).
- Also dates comming from binary EXIF don’t carry timezone informations. This is now mentioned.
- Fixed Issue 8: Support for Degrees Minutes (DegMin) GPS format.
- Reworked flash data evaluation and strings on basis off a patch by Max Pozdeev.
- Added new translations for Swedish by Jan Kardell (via BabelZilla.org) and for Finnish by Ilari Oras (fixing Issue 9).
- Polish translation is not contained since newly added strings weren’t translated.
- Fixed Issue 10: Endless recursion if Exif Interoperability Offset or Exif Offset point to its own start offset. That’s an error in the data.
- Flash data from XMP is now better evaluated (also as child values of the Flash tag instead only attributes of it). Thanks to Phil Lattimore for reporting.
- At least one software appends a null byte to the XMP document and the Mozilla XML parser doesn’t like this at all. I added a workaround for this case which shortens the document by one byte.
- Only use DateTime if no DateTimeOriginal or DateTimeDigitized are available.
- Relaxed detection of XMP data a bit to work around a bug in some photo software.
- Not existing flash information in XMP data doesn’t cause fail of XMP evaluation anymore.
- Made evaluation of following data not fail if some error occurs. Instead a note is placed in the window that evaluation stopped and data shown might be incomplete.
- Fixed a bug where "chr" was used as language if intl.accept_language was left at the default for the browser. (Thanks to Hector Zhao)
- Added new translation for Dutch thanks to markh van BabelZilla.org.
- Added interpretation of EXIF values that are contained in XMP format rather the old binary format. Added some fields mainly regarding the location of the subject. Internally more fields are inspected to fill the license field.
- Also rearranged the order of the field listing, fixed some bugs in the XMP interpreter, the binary EXIF reader.
- Own EXIF window is now closable with ESC and the Copy button has a Alt+C (Option+C on Mac) shortcut.
- Can now cope with images delivered compressed (e.g. "Content-Encoding: gzip")
- Enabled overlaying of the properties window that's being readded by Geoff Lankows Element properties
- Added new translation for Russian thanks to Max Pozdeev. All localizations have been overhauled, thanks to old and new contributors on BabelZilla.
Decoding of IPTC-NAA and XMP data
Decoding of creator, title, description and copyright
Ability to operate on images opened from mailbox, news and imap
Also works with Firefox >= 3 and SeaMonkey >= 2
Also works with images that aren't cached.
Also works with images from mailbox, news or imap addresses