Issue Tracker - ISSUES

0000601: Issue Tracker config issue: I can't select the exiv2 project for reporting a bug!

Sorry for reporting in this wrong project, but I just registered in http://dev.robotbattle.com [^] (user ariel) and i can't select the exiv2 project for reporting a bug! When logged off i can see 3 projects, when logged in "exiv2" is missing!

0000600: Upgrade XMP Toolkit to version 4.4.2

Changes between version 4.1.1 and 4.4.2 according to the overview document in the distribution:

* Handlers for additional file formats, including ASF (WMA, WMV), FLV; MPEG4; SWF; folder-based video formats AVCHD, P2, SonyHDV, and XDCAM; UCF (see XMP Specification Part 3, Storage in Files).
* Additional schemas to support document histories, composed documents, and temporal metadata (see XMP Specification Part 2, Standard Schemas).
* XCode projects work in XCode 3
* VS8 projects for Windows now include 64-bit build targets for Windows.
* Expanded, updated, and reorganized documentation. The XMP Toolkit SDK Programmer’s Guide has been renamed and updated for new features. The XMP Specification has been split into three parts; Part 1, Data and Serialization Models Part 2, Standard Schemas, and Part 3, Storage in Files.
* Additional and updated sample code. See “Sample code and tools” on page 3.

0000599: XMP packets split across multiple APP1 segments

It looks like Adobe has recently updated its XMP specification
to allow JPEG files to host large (> 65,502 bytes) XMP packets
by splitting them into multiple APP1 marker segments.

The gory details are explained in the "Extended XMP in JPEG"
section in this document:

<http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart3.pdf> [^]

Since there is now an official specification, are there any
plans to support extended XMP in exiv2?

Reported by Marco Piovanelli
http://uk.groups.yahoo.com/group/exiv2/message/1493 [^]

0000594: Modifying images on an NTFS file system fails (digiKam bug 178103)

chmod doesn't work as expected on NTFS.

0000593: The default type of Array element tags is incorrect

It defaults to Ascii, which doesn't work when writing to an image:

ahuggel@mowgli> ./exiv2 -v -M'set Exif.CanonCs.0x002b 255' exiv2-empty.jpg
File 1/1: exiv2-empty.jpg
Set Exif.CanonCs.0x002b "255" (Ascii)
Exiv2 exception in modify action for file exiv2-empty.jpg:
TIFF array element tag 43 has wrong type

See http://uk.groups.yahoo.com/group/exiv2/message/1472 [^] for a discussion in a larger context.

PS: The error message could be more useful too...

0000505: Ability to extract some very basic pieces of information from images

Hi,

I'd like to request a feature for a future version of exiv2:
the ability to extract some very basic pieces of information
about an image even from files that don't carry any metadata
(Exif, IPTC or XMP). I'm thinking about basic attributes like:

* pixel width
* pixel height
* image depth (bits per pixel)
* samples per pixel
* bits per sample

All of the above attributes can be extracted from the Exif metadata,
but not all image files have Exif metadata.

It could be argued that this goes beyond the scope of a *metadata*
library like libexiv2, and that extraction of the above information
could be easily (?) accomplished using a separate parser.

But for a file format like JPEG, this means doing some work twice,
namely, scanning the file for JPEG markers. A single-pass scan could
both locate APP1, APP13 and COM markers (for Exif/XMP/IPTC metadata
and comments) and the first SOFn marker (for width/height/depth).

Scanning the same file twice (once for libexiv2 and once for
extracting width/height/depth using a separate parser) may seem
like no big deal, but there are scenarios in which accessing the
image file can be expensive -- think of a file living on a remote
file system or on a HTTP server.

-- marco

0000439: The exiv2 library should be re-entrant

Exiv2 is currently not re-entrant. I'm aware of the following problems, but maybe there are more:
+ It uses the old versions of some C/Posix functions instead of the *_r version.
+ Construction of the Image and Makernote factories accesses static variables without any protection

0000556: timegm() function should work with Windows 64bit time_t

In timegm.h, it defines _USE_32BIT_TIME_T because the comments say that the 64 bit time_t does not work:

/* Visual Studio C++ 2005 (8.0) uses 64 bit time_t, which doesn't work */

#if defined _MSC_VER && _MSC_VER >= 1400

# define _USE_32BIT_TIME_T

#endif

However, when performing a 64 bit build in Visual Studio 2008, crtdefs.h says that _USE_32BIT_TIME_T is not valid with WIN64:

#ifdef _USE_32BIT_TIME_T

#ifdef _WIN64

#error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64

#undef _USE_32BIT_TIME_T

#endif

#endif

0000579: Implement memory mapping for Windows platforms

On Windows, there should be equivalent functions for mmap() and munmap() which can be used to implement memory mapping also for Windows in Exiv2::FileIo (basicio.cpp).

0000586: ValueType constructor makes assumptions of the endianness of the machine

If I use the following code on Intel (little endian) machines:

exifData["Exif.Image.XResolution"] = Exiv2::ShortValue(37);

I get an expected resolution of 37 in the final image. However on
PowerPC (big endian) the bytes are swapped and the resolution value is
a lot bigger.

Reported by Dimitri in http://uk.groups.yahoo.com/group/exiv2/message/1449 [^]

0000572: exiv2 tool: It should be possible to insert newlines in text strings.

Some people want line breaks in their strings. While it shouldn't be a problem with the C++ API, it is apparently not possible to do this with the exiv2 command line tool.

0000585: Unified metadata container

Instead of maintaining one metadata container and all its supporting infrastructure for each type of metadata, there should be one unified metadata container for all metadata.
This will make it easier for applications to deal with metadata independent of its type. On the other hand, there should be supporting functions (filters) for cases where only a specific type of metadata is needed.

0000581: Remove FindMetadatum* from API

These classes are only used internally. See class FindExifdatum in the anonymous namespace in tiffvisitor.cpp for a better place to have such misc stuff.

0000577: Convert relative makernote offsets to absolute offsets

Some makernotes use IFD offsets relative to the beginning of the makernote (or somewhere near the beginning of the makernote). This has certain advantages, but it complicates matters for users who would like to follow the offset (e.g., to access a preview image pointed to from a makernote tag of a TIFF image).

Thus relative offsets should be converted to absolute offsets.

0000536: Switch to a unified build system based on cmake [was: Time to switch to Visual C++ 2008 Express edition for win32 (Or to ma... ]

One set of CMake scripts can be used to create build files for a number of platforms and compilers, including those supported with the existing Makefiles and MSVC project files.

0000510: Use pimpl idiom where applicable

Increases stability of the interface
From Sutter, C++ Coding Standards:

class Map {

// ...

private:
struct Impl;
shared_ptr pimpl_;
};

0000576: 24x36 equivalent focal length

Suggested by Frédéric < frederic . mantegazza AT gbiloba DOT org >

it is very interesting to get the 24x36 equivalent focal length.
This focal length depends of the crop sensor, and vary from cameras
to cameras. Geeqie implemented this feature by
recomputing the sensor crop factor from several informations (see
attachement). But these information are not available on all cameras.
So, I suggested them to use this file:

http://www.autopano.net/wiki/action/view/Cameras.txt [^]

(note that the file on the wiki is not up-to-date; better use the one in
the latest APP release).

Geeqie developers answered me that such feature should be implemented at
a lower level, in exiv2. So I contact you.

Do you think it could be used in exiv2? The file is usable in GPL-project
only. As exiv2 has a double license, it may be a problem for the
commercial version. The solution could be to add the support of this
file in the free release, and lock it in the commercial one (unusual,
isn't it?).

0000457: Keys should be names rather than strings

Metadata keys are defined using a std::string, eg.

ExifKey key("Exif.Photo.UserComment");

This method has a number of backdraws:

- The compiler doesn't know the string, no compile-time check is possible,
eg, to catch typos
- Editors cannot help with auto-completion of the key string
- The strings use more memory than necessary

A better implementation would be to have a name (constant variable) for each tag, which the compiler could check and editors could auto-complete.

The information that is required for each tag is: metdata type, group, tag number, ie, 3 small integers

0000533: Support multiple APP13 Photoshop 3.0 segments in a JPEG

It appears there can be multiple APP13 Photoshop 3.0 segments in a JPEG. The payloads of these should be concatenated before processing and the other way around on write.

0000543: make exiv2 read the makernote offset
interpret makernote offset that Microsoft WIC tools introduce when it edits photos

is it possible to make exiv2 read the makernote offset
that Microsoft WIC tools introduce when it edits photos?

See this KB article for more detail
http://support.microsoft.com/kb/927527 [^]

When I use Vista Photo Gallery to edit my photos - it moves the
location of the makernotes (to make room for new metadata?) and
records the offset of where it put them...but now exiv2
says "Warning: Failed to read Makernote, rc = 6" since it doesn't
know about the offset.

Whether this is a misguided approach or not by Microsoft (no argument
here!) it would be nice if it isn't too much work to make exiv2
compatible with these offset makernotes.

ExifTool added compatibility in 6.75
(http://www.sno.phy.queensu.ca/~phil/exiftool/history.html) [^] although
the author notes it was "ill-conceived" by Microsoft even so - Vista
is getting onto more and more desktops and more and more users will
have photos with these shifted makernotes (including me!) so it would
be nice to support the offset.

0000574: Support "Adobe Makernote" in DNGPrivateData

From Gilles Caulier:

After playing and playing with Adobe DNG converter to tune my propers raw to DNG tool (http://www.digikam.org/drupal/node/373) [^] , i have discovered than Adobe do not use Exif.Photo.MakerNote tags to host makernote byte array, but a new DNG tag named DNGPrivateData Look this page:

http://www.barrypearson.co.uk/articles/dng/safety.htm [^]

...and this comment :

"The code change in ACR/DNG 3.1 that preserves private MakerNotes applies to all formats that store their private data using the Exif MakerNote format, which includes Pentax. These MakerNotes are often byte order or offset dependent, so what I'm doing to preserve this data safely is repackaging it into the DNGPrivateData tag. This repackaging stores the source file's byte order and the original file offset to the MakerNote, along with the MakerNote data itself. This allows an application that understands the MakerNote format for a particular camera to find the MakerNote data, along with the original byte order and file offset, and thus parse the MakerNote data correctly from the DNG file".

But the better is here :

http://www.barrypearson.co.uk/articles/dng/specification.htm [^]

With these informations how to store makernotes in DNGPrivateData:
Storage of Makernote in DNGPrivateData
...

The DNGPrivateData generated by the DNG Converter, hence containing the original EXIF Makeernote, is:

1. Six bytes containing the zero-terminated string "Adobe". (The DNG specification calls for the DNGPrivateData tag to start with an ASCII string identifying the creator/format).
2. 4 bytes: an ASCII string ("MakN" for a Makernote), indicating what sort of data is being stored here. Note that this is not zero-terminated.
3. A four-byte count (number of data bytes following); this is the length of the original MakerNote data. (This is always in "most significant byte first" format).
4. 2 bytes: the byte-order indicator from the original file (the usual 'MM'/4D4D or 'II'/4949).
5. 4 bytes: the original file offset for the MakerNote tag data (stored according to the byte order given above).
6. The contents of the MakerNote tag. This is a simple byte-for-byte copy, with no modification.

So, i will using this way in my converter to be fully compatible with Adobe tool.

This imply too that Exiv2 need to support this way to extract makernotes from DNG files...

0000571: Need to convert character set when writing XMP sidecar

When I try to extract a XMP sidecar file from a photo with umlauts in IPTC fields, i get the following error:

C:\Programme\exiv2>exiv2 -eX P1010062.tif
XMP Toolkit error 4: Invalid UTF-8 sequence length
Error: Failed to encode XMP metadata.

(Reported by Franz Buchinger)

0000569: Unable to write GPS data in ORF files with digikam

Exiv2 seems to be unable to write GPS data in the exif header in ORF files. Please enable this support. E. g. geotag (http://geotag.sourceforge.net/) [^] already has write support for GPS data in ORF files.

Here's the link to the digikam bug I filed before knowing better. ;)
http://bugs.kde.org/show_bug.cgi?id=170693 [^]

0000564: Need a way to get a list of all supported tags

In KPhotoAlbum, we have to invent an ugly way to parse strings because exiv2 didn't provide any way to get a list of all recognized tag names, see Info::standardKeys() at http://websvn.kde.org/trunk/extragear/graphics/kphotoalbum/Exif/Info.cpp?view=markup [^]

The exiv2 library already provides a way to get a list of "normal" tags, but I wasn't able to find any equivalent for MakerNotes, nor for IPTC data. Having to parse strings is really ugly (and I apologize for not bringing this to your attention before).

In addition, Exiv2::ExifTags::makerTaglist() got renamed to Exiv2::ExifTags::taglist() while you were fixing 0000550. Changing API in an incompatible way should be avoided whenever possible.

0000465: Support standalone JPEG APP1 segments as an Image format

JPEG parser should be able to read/write standalone JPEG APP1 segments, leave the code common in JpegImage.
An App1Image class derived from JpegBase will deal with the format recognition.