bytorbrynden/jpegmetaextractor

An extractor, built to extract metadata from JPEG files.

Hello world, I'm bytorbrynden!

Automotive & Tech Enthusiast

Greetings from the intersection of code and horsepower! I'm Brynden, a 20-something year old with an insatiable curiosity for all things automotive and a deep fascination for the ever-evolving realm of technology.

As I embark on my journey back into the realms of software and web development, my commitment is to foster a collaborative and transparent community. I firmly believe in the power of open-source development, and my goal is to contribute as much as possible to this collective knowledge pool. By keeping my work open-source, I aim to not only share my creations but also invite collaboration, feedback, and improvement from the wider community.

Let's Connect

If you have any interest in seeing more from me outside of GitHub, feel free to connect with me on any of the platforms listed below!

• Twitter
• Instagram
• LinkedIn

jpegmetaextractor's Issues

Core won't compile on Windows due to use of GCC extensions

Adding to a void * is a GCC extension. The more-correct way of doing this involves casting to some type (unsigned char *?), and then performing the pointer arithmetic.

Attribute values are treated as if only a single value will exist...

...which isn't always the case. Take, for example, the GPSLatitude attribute. It's value should contain 3 rationals, but we only capture one.

Image file is never closed

I'm obviously an idiot. I forgot to close the image file after opening it...

Add attribute searching to CLI

Library-ify the extractor

While having an executable program is nice, I need to compile the extractor into a static-library that I can use in my other projects.

processTag is incapable of dealing with value offsets

From the Exif 2.2 specification:

Value Offset
This tag records the offset from the start of the TIFF header to the position where the value itself is recorded. In
cases where the value fits in 4 bytes, the value itself is recorded. If the value is smaller than 4 bytes, the value is
stored in the 4-byte area starting from the left, i.e., from the lower end of the byte offset area. For example, in big
endian format, if the type is SHORT and the value is 1, it is recorded as 00010000.H.

Note that field Interoperability shall be recorded in sequence starting from the smallest tag number. There is no
stipulation regarding the order or position of tag value (Value) recording.

Currently, the processTag function doesn't know where the TIFF header is, thus it cannot (easily) handle these value offsets.

Come up with a better name for the project

The current name ("JPEG Meta Extractor"), to those whom aren't familiar with Exif, may suggest that this extractor only works with JPEG files, which isn't true.

In reality, this extractor is designed to work with any form of Exif files, such as JPEG and TIFF. Eventually, however, this project may be expanded to work with various other file-formats, therefore it needs a new name.

Figure out how to access Exif and GPS IFDs

The Exif 2.2 specification states that at the end of the 0th IFD, there are 2 private-tag-offset attributes, one of which specifies an offset to the Exif IFD, and the other specifies the offset to the GPS IFD.

Both offsets, as usual, are relative to the start of the TIFF header.

Access GPS IFD, and capture/store some basic attributes

All of the following attributes, are located within the GPS IFD, which is pointed to by an offset from the TIFF header. The offset can be found in the 0th IFD, under an attribute with the tag 0x8825.

• "GPSLatitudeRef" attribute (0x01)
  • Is captured
  • Is available in attribute container
• "GPSLatitude" attribute (0x02)
  • Is captured
  • Is available in attribute container
• "GPSLongitudeRef" attribute (0x03)
  • Is captured
  • Is available in attribute container
• "GPSLongitude" attribute (0x04)
  • Is captured
  • Is available in attribute container
• "GPSAltitude" attribute (0x06)
  • Is captured
  • Is available in attribute container

Share attribute container throughout metadata extractor

Capture some basic attributes, and make them available in the attribute container

• "Make" attribute (0x010F)
  • Is captured
  • Is available in attribute container
• "Model" attribute (0x0110)
  • Is captured
  • Is available in attribute container
• "Software" attribute (0x0131)
  • Is captured
  • Is available in attribute container

All of the above, are TIFF attributes, and can be found in the very first IFD that gets read.

Don't log messages in the core

Logging messages from within the core is a bit annoying, and should be avoided.

Don't register any attributes when allocating the attribute container

Currently, when the allocateMetadataAttributesContainer function is called, we register a few attributes.

Seeing as the core is designed to be used alongside other applications, users might want to be able to pick and choose which attributes are pulled from their input file(s).

To make this change, the extractMetadata function would need to be reworked to accept a(n) MetadataAttributesContainer pointer that was allocated by the user (which they would register arguments with).

GPSLatitude and GPSLongitude values don't appear to be correct

The values for the GPSLatitude and GPSLongitude attributes, don't seem valid.

The values for both of attributes are expressed in the form of "deg min sec", each of which is a rational.

The deg value for both appears to be correct, however, the min and sec values are giving me a 6-digit number, over 0 (e.g. 111111/0).

Add support for storing of attribute values to attribute container

Currently, the attribute container doesn't have the ability to store values for attributes. This is a necessity.

If we can't store the values, this entire project is useless.

Replicate Exif data-types in C code

The following types are used in Exif, and need to have C representations. Descriptions of the types taken from the Exif 2.2 specification.

• BYTE: An 8-bit unsigned integer.
• ASCII: An 8-bit byte containing one 7-bit ASCII code. The final byte is terminated with NULL.
• SHORT: A 16-bit (2-byte) unsigned integer.
• LONG: A 32-bit (4-byte) unsigned integer.
• RATIONAL: Two LONGs. The first LONG is the numerator and the second LONG expresses the denominator.
• UNDEFINED: An 8-bit byte that can take any value depending on the field definition.
• SLONG: A 32-bit (4-byte) signed integer (2's complement notation).
• SRATIONAL: Two SLONGs. The first SLONG is the numerator and the second SLONG is the denominator.

Only print normal attributes

The printAttribute function should only print attributes that have a specialty of ATTRIBUTE_SPECIALTY_NORMAL.

Attribute values become invalid immediately after they're captured

The values are becoming invalid, because they're getting free'd too soon (here, to be exact).

The reason I'm saying that free occurs too soon, is because, at that point, the value has just been captured, therefore we're not sure whether or not the "user" is done with the value yet.

Really, the attribute values should be free'd as part of the deallocateMetadataAttributesContainer function, which is only called by the "user".

printAttribute function tries to access invalid memory sometimes

Discovered because of this: WebFreak001/code-debug#61

Reflect the project's new name, in the source-code

getAttributeValue function leaks memory

The getAttributeValue function, has a memory leak.

I haven't dug into this yet, but I assume the memory leak is caused because the pValue member of the MetadataAttribute structure, isn't free'd.