Free metadata registry software for linux

SVG::Metadata is a Perl module to capture metadata info about an SVG file.

SYNOPSIS

use SVG::Metadata;

my $svgmeta = new SVG::Metadata;

$svgmeta->parse($filename)
or die "Could not parse $filename: " . $svgmeta->errormsg();
$svgmeta2->parse($filename2)
or die "Could not parse $filename: " . $svgmeta->errormsg();

# Do the files have the same metadata (author, title, license)?
if (! $svgmeta->compare($svgmeta2) ) {
print "$filename is different than $filename2n";
}

if ($svgmeta->title() eq ) {
$svgmeta->title(Unknown);
}

if ($svgmeta->author() eq ) {
$svgmeta->author(Unknown);
}

if ($svgmeta->license() eq ) {
$svgmeta->license(Unknown);
}

if (! $svgmeta->keywords()) {
$svgmeta->addKeyword(unsorted);
} elsif ($svgmeta->hasKeyword(unsorted) && $svgmeta->keywords()>1) {
$svgmeta->removeKeyword(unsorted);
}

print $svgmeta->to_text();

This module provides a way of extracting, browsing and using RDF metadata embedded in an SVG file.

The SVG spec itself does not provide any particular mechanisms for handling metadata, but instead relies on embedded, namespaced RDF sections, as per XML philosophy. Unfortunately, many SVG tools dont support the concept of RDF metadata; indeed many dont support the idea of embedded XML "islands" at all. Some will even ignore and drop the rdf data entirely when encountered.
The motivation for this module is twofold. First, it provides a mechanism for accessing this metadata from the SVG files. Second, it provides a means of validating SVG files to detect if they have the metadata.

The motivation for this script is primarily for the Open Clip Art Library (http://www.openclipart.org), as a way of filtering out submissions that lack metadata from being included in the official distributions. A secondary motivation is to serve as a testing tool for SVG editors like Inkscape (http://www.inkscape.org).

Image::MetaData::JPEG::TagLists contains a collection of tag tables for JPEG segments. Image::MetaData::JPEG::TagLists is an appendix to the main manual page of the Image::MetaData::JPEG module, which the reader should refer to for further details and the general scope.

Valid tags for Exif APP1 data

The Japan Electronics and Information Technology Industries Association (JEITA) set up a standard for an exchange format for digital still cameras pictures, known as Exif. This standard defines a structure for embedding meta-data in a JPEG picture, to be written in the APP1 segment. The generalities and the reference documents about this structure are introduced in the Structure appendix; this section and its subsections list the valid interoperability record tags as well as their format.

Canonical Exif 2.2 and TIFF 6.0 tags for IFD0 and IFD1

In general, IFD0 and IFD1 can host tags from the same set. These tags are divided in three categories: canonical, additional and registered to companies. The tags listed in the following table are to be considered canonical; they are described at length in the Exif standard document, and can be found both in the IFD0 and in the IFD1 (some of them, in fact, must be present in both directories).

The class column carries the tag class; possible values are: A (image data structure), B (offsets), C (image data characteristics), D (other tags) and P (pointers to other IFDs). The two following columns show tag hexadecimal codes and names. The type column specifies the (always unsigned) tag type: I (short or long), S (short), L (long), R (rational) and A (ASCII, always null terminated). The count column obviously carries the tag count (- for a variable count, either because it is a variable length string or because it depends on other tags).

The IFD0 and IFD1 columns specify the support level in the respective directory; each column comprises four letters, because both the primary image (IFD0) and the thumbnail (IFD1) can come in four varieties (uncompressed chunky, uncompressed planar, uncompressed YCC and JPEG compressed).

This module currently focuses only on JPEG pictures (not TIFF), so only the fourth letter of the IFD0 column is interesting, but note that the thumbnail of a JPEG image can be uncompressed. The support level codes stand for: M (mandatory), R (recommended), O (optional), N (not_recorded) and J (included in JPEG marker and so not recorded).

The thumbnail-only column shows a T for those records which cannot be set/changed by the user exception made during a thumbnail update action (and some of them are calculated automatically anyway). Note that, in some cases, it is possible to set a tag when its support level is N (e.g., the YCbCr stuff in IFD1): picture displaying programs should however simply ignore it. Some other tags, concerning offsets or thumbnail specific information, cannot be set by the module user (they are calculated automatically, more reliably): these are marked by calculated in the notes, or by a T in the thumbnail-only column.

Hexadecimal code count IFD0 IFD1 thumbnail-only
class | Tag name type | supp.supp.| notes
| | | | | | | | |
A 100 ImageWidth I 1 MMMJ MMMJ T (not JPEG) pixels/row
A 101 ImageLength I 1 MMMJ MMMJ T (not JPEG) num. rows
A 102 BitsPerSample S 3 MMMJ MMMJ T (not JPEG) 8,8,8
A 103 Compression S 1 MMMJ MMMM T 1(uncompr.) or 6(JPEG)
A 106 PhotometricInterpretation S 1 MMMN MMMJ 2(RGB) or 6(YCbCr)
D 10e ImageDescription A - RRRR OOOO (see note 1)
D 10f Make A - RRRR OOOO camera manufacturer
D 110 Model A - RRRR OOOO camera model
B 111 StripOffsets I - MMMN MMMN calculated
A 112 Orientation S 1 RRRR OOOO (see note 2)
A 115 SamplesPerPixel S 1 MMMJ MMMJ T (not JPEG) 3 compon.
B 116 RowsPerStrip I 1 MMMN MMMN T (not JPEG)
B 117 StripByteCounts I - MMMN MMMN T (not JPEG)
A 11a XResolution R 1 MMMM MMMM (see note 3)
A 11b YResolution R 1 MMMM MMMM (see note 3)
A 11c PlanarConfiguration S 1 OMOJ OMOJ (see note 4)
A 128 ResolutionUnit S 1 MMMM MMMM (see note 3)
C 12d TransferFunction S 768 RRRR OOOO (see note 5)
D 131 Software A - OOOO OOOO Exif software/firmware
D 132 DateTime A 20 RRRR OOOO (see note 6)
D 13b Artist A - OOOO OOOO owner/photogr./creator
C 13e WhitePoint R 2 OOOO OOOO (see note 5)
C 13f PrimaryChromaticities R 6 OOOO OOOO (see note 5)
B 201 JPEGInterchangeFormat L 1 NNNN NNNM calculated
B 202 JPEGInterchangeFormatLength L 1 NNNN NNNM T (only JPEG)
C 211 YCbCrCoefficients R 3 NNOO NNOO (see note 7)
A 212 YCbCrSubSampling S 2 NNMJ NNMJ (see note 7)
A 213 YCbCrPositioning S 1 NNMM NNOO (see note 7)
C 214 ReferenceBlackWhite R 6 OOOO OOOO (see note 8)
D 8298 Copyright A - OOOO OOOO of photogr./editor
P 8769 ExifOffset L 1 MMMM OOOO calculated
P 8825 GPSInfo L 1 OOOO OOOO calculated

Image::MetaData::JPEG::Structures is a Perl module that describes the structure of a JPEG file; it is an appendix to the main manual page of the Image::MetaData::JPEG module, which the reader should refer to for further details and the general scope.

THE STRUCTURE OF JPEG PICTURES

The JPEG (Joint Photographic Experts Group) ISO standard is a lossy image compression mechanism developed before 1990, designed for compressing colour or gray-scale photo-realistic images (it performs poorly on line-art drawings). The JPEG mechanism is designed to exploit known limitations of the human eye, in particular the fact that colour changes are perceived less accurately than changes in brightness.

Note that although the "baseline" JPEG format is patent-free, there are patents associated with some optional features, namely arithmetic coding and hierarchical storage. For this reason, these optional features are never used on the Web (good job, patent fans ...). JPEG refers only to a class of compression algorithms, not to a specific file format. In order to produce files with embedded JPEG streams, a number of file format (semi-)standards have been adapted or devised, some of which are listed in the format section. The structure of a well formed JPEG file can be described by the following pseudo production rules (for sake of simplicity, some additional constraints between tables and SOF segments are neglected).

JPEG --> (SOI)(misc)*(image)?(EOI)
(image) --> (hierarch.)|(non-hier.)
(hierarch.) --> (DHP)(frame)+
(frame) --> (misc)*(EXP)?(non-hier.)
(non-hier.) --> (SOF)(scan)+
(scan) --> (misc)*(SOS)(data)*(ECS)(DNL)?
(data) --> (ECS)(RST)
(misc) --> (DQT)|(DHT)|(DAC)|(DRI)|(COM)|(APP)

(SOI) = Start Of Image
(EOI) = End Of Image
(SOF) = Start Of Frame header (10 types)
(SOS) = Start Of Scan header
(ECS) = Entropy Coded Segment (row data, not a real segment)
(DNL) = Define Number of Lines segment
(DHP) = Define Hierarchical P??? segment
(EXP) = EXPansion segment
(RST) = ReSTart segment (8 types)
(DQT) = Define Quantisation Table
(DHT) = Define Huffman coding Table
(DAC) = Define Arithmetic coding Table
(DRI) = Define Restart Interval
(COM) = COMment segment
(APP) = APPlication segment

This package does not check that a JPEG file is really correct; it accepts a looser syntax, were segments and ECS blocks are just contiguous (basically, because it does not need to display the image!). All meta-data information is concentrated in the (COM*) and (APP) Segments, exception made for some records in the (SOF*) segment (e.g. image dimensions).

Reference: B< "Digital compression and coding of continuous-tone still
images: requirements and guidelines", CCITT recommend. T.81, 1992,
The International Telegraph and Telephone Consultative Committee,
standard ISO/IEC IS 10918-1 or ITU-T Recommendation T.81 >.
Also: B< "The JPEG still picture compression standard", G.K.Wallace,
1991, IEEE Transactions on Consumer Electronics >.

Registry J2SE is a library that provides lightweight registry functions for both Hibernate2 and Hibernate3 configurations.

WWW::Blog::Metadata::Microsummary is a Perl module to extract Microsummary URI from a page.

SYNOPSIS

use WWW::Blog::Metadata;
my $meta = WWW::Blog::Metadata->extract_from_uri($uri)
or die WWW::Blog::Metadata->errstr;

## or

my $meta = WWW::Blog::Metadata->extract_from_html($html, $base_uri)
or die WWW::Blog::Metadata->errstr;

my $microsummary_uri = $meta->microsummary_uri;

WWW::Blog::Metadata::Microsummary is a WWW::Blog::Metadata plugin to look for and extract a URI which idendifies where a microsummary or a microsummary generator of a page is located in.

Yet Another MetaData Injector (yamdi) is a metadata injector for FLV files. It adds the onMetaData event to your FLV files. yamdi should run under *BSD and Linux (tested with FreeBSD, MacOSX and Ubuntu) and is published under the BSD license.
Why?
For a current project I have to add metadata to quite large FLV files (over 1GB). The other known free tools (flvmdi and flvtool2) are not suitable for that job because they read the whole file into memory. Because Im not very familiar with ruby (in order to modify flvtool2) and flvmdi is not open source I took the FLV specs and implemented a metadata injector in C. yamdi uses less memory and is faster.
Yet Another MetaData Injector for FLV injects the following metadata into your FLV files:
- creator
- metadatacreator
- hasKeyframes
- hasVideo
- hasAudio
- hasMetaData
- canSeekToEnd
- duration
- datasize
- videosize
- videocodecid
- audiosize
- audiocodecid
- audiosamplerate
- audiosamplesize
- stereo
- filesize
- lasttimestamp
- lastkeyframetimestamp
- lastkeyframelocation
- keyframes (filepositions, times)
- width
- height
- framerate
- videodatarate
- audiodatarate
Installation:
Download the source code and extract it with tar:
tar xzf yamdi-1.0.tar.gz
Change into the yamdi directory and compile the source code with:
cd yamdi-1.0
gcc yamdi.c -o yamdi -O2 -Wall
yamdi accepts four paramters:
-i The source FLV file.
-o The resulting FLV file with the metatags. If the output file is - the FLV file will be written to stdout.
-c A string that will be written into the creator tag. This parameter is optional
-h Displays a description of the available parameters
Examples:
yamdi -i sample.flv -o sample_with_metadata.flv
yamdi -i sample.flv -o - > sample_with_metadata.flv
yamdi -i sample.flv -o sample_with_metadata.flv -c "John Doe"
Enhancements:
- [Fix] Width and height calculation of ScreenVideo stream was wrong
- [Add] onLastSecond event with option -l