Free noc 3.01 software for linux

Image::MetaData::JPEG::MakerNotes contains random information and details on MakerNotes.

Pieces of information available after parsing the MakerNote

The result of the process of parsing the maker note is stored in a directory in the internal data structure for the APP1 Segment, whose path is "IFD@SubIFD@MakerNoteData_$format", where $format is the specific note format; the MakerNote entry in IFD0@SubIFD is then removed. This translation happens always, because there is a catch-all unknown rule for a binary makernote with very broad acceptance rules. The maker note directory contains, in addition, a special subdir with some fields reporting about the parsing process.

key content
-------- -------
ORIGINAL the raw content of the maker note (unparsed)
SIGNATURE the first few bytes which allowed the format to be chosen
ENDIANNESS the byte order chosen during parsing
FORMAT the maker note format chosen during parsing
ERROR [optional] error details, in case of failure while parsing

Supported MakerNote formats

Maker note formats are specified in a special internal hash, with a key for each format (including the unknown format). Each format entry corresponds to an anonymous hash containing information for parsing the MakerNote; the "normal" format is considered to be an IFD-like MakerNote with a next_link pointer, offsets counted from the global TIFF header and no MakerNote internal TIFF header.

key meaning or effect
--------- -----------------
signature the MakerNote signature (a regular expression)
maker the Maker signature (i.e., its name, no regex)
tags a reference to a hash for tag translations
(A) mkntstart if set, offsets are counted from the maker note start
(B) mkntTIFF if set, offsets are counted from the internal TIFF header
(C) ignore if set, the format is to be ignored
(D) nonext if set, the maker note IFD does not have a next_link
(E) endianness if set, the byte order is fixed to this value
(F) nonIFD if set, the maker note is not IFD-like

Currently, "supported" formats are described in the following table; authoritative data is indeed kept in Tables_makernotes.pl, to which the reader should refer for tag definitions and translations. Remember that both the signature and the maker fields are regular expressions matching at the beginning (the real signature corresponds to $1).

A B C D E F Maker Signature
----------- --------- -----------------
Agfa AGFA (AGFA 00 01)
Canon Canon ()
Casio_1 CASIO ()[^Q]
Casio_2 CASIO (QVC 00{3})
Epson EPSON (EPSON 00 01 00)
Foveon FOVEON (FOVEON 00{2} 01 00)
Fujifilm x FUJIFILM (FUJIFILM 14 00{3})
HPackard x Hewlett-Packard (HP)
Kyocera x x KYOCERA (KYOCERA {12} 00{3})
Kodak B x KODAK (KDK INFO[a-zA-Z0-9]* )
Minolta_1 MINOLTA ().{10}MLT0
Minolta_2 Minolta ().{10}MLT0
Konica x Minolta|KONICA ((MLY|KC|(+M){4})| 01 00{5} 04)
Nikon_1 NIKON (Nikon 00 01 00)
Nikon_2 NIKON ()[^N]
Nikon_3 x NIKON (Nikon 00 02[ 20 00] 00{2})
Olympus OLYMPUS (OLYMP 00[ 01 02] 00)
Panasonic_1 x Panasonic (Panasonic 00{3})
Panasonic_2 x x Panasonic (MKED)
Pentax_1 x Asahi ()[^A]
Pentax_2 x x Asahi (AOC 00..)
Ricoh_1 x RICOH (Rv|Rev)
Ricoh_2 x RICOH ( 00)
Ricoh_3 RICOH ((Ricoh|RICOH) 00{3})
Sanyo SANYO (SANYO 00 01 00)
Sigma SIGMA (SIGMA 00{3} 01 00)
Sony x SONY (SONY (CAM|DSC) 00{3})
Toshiba x TOSHIBA ()
unknown x . ()

References

MakerNote format details are not usually released by vendors (well, this is an euphemism: no vendor ever, to my knowledge, released any detail on its format, exception made for Sigma/Foveon). All information used for this package was collected on the Internet (and its reliability is therefore limited) or through personal tests. Some interesting sites are (not an exhaustive list at all):

General: home.arcor.de/ahuggel/exiv2/makernote.html
.....: www.ozhiker.com/electronics/pjmt/jpeg_info/makernotes.html

Agfa: www.ozhiker.com/electronics/pjmt/jpeg_info/agfa_mn.html
Canon: www.burren.cx/david/canon.html
Casio: park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html
...: www.dicasoft.de/casiomn.htm
Epson: www.ozhiker.com/electronics/pjmt/jpeg_info/epson_mn.html
Foveon: Foveon is the same as Sigma, see Sigma
Fujifilm: park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html
......: www.ozhiker.com/electronics/pjmt/jpeg_info/fujifilm_mn.html
Kyocera: www.ozhiker.com/electronics/pjmt/jpeg_info/kyocera_mn.html
Kodak: my personal tests with my Kodak DX3900 (not IFD-like)
Minolta: www.dalibor.cz/minolta/makernote.htm
.....: www.ozhiker.com/electronics/pjmt/jpeg_info/minolta_mn.html
Nikon: park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html
...: www.tawbaware.com/990exif.htm
...: www.ozhiker.com/electronics/pjmt/jpeg_info/nikon_mn.html
Olympus: park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html
.....: www.ozhiker.com/electronics/pjmt/jpeg_info/olympus_mn.html
Panasonic: www.compton.nu/panasonic.html
Pentax: www.ozhiker.com/electronics/pjmt/jpeg_info/pentax_mn.html
Ricoh: www.ozhiker.com/electronics/pjmt/jpeg_info/ricoh_mn.html
Sanyo: www.exif.org/makernotes/SanyoMakerNote.html
Sigma: www.x3f.info/technotes/FileDocs/MakerNoteDoc.html
Sony: www.ozhiker.com/electronics/pjmt/jpeg_info/sony_mn.html

DX3900 MakerNote format

Kodak MakerNotes are written in a proprietary binary format, which is not IFD-like. So, there is no way to detect the beginning, end and type of a field; everything here was inferred through a careful comparison of the content of a set of Kodak JPEG files and their shot parameters. Fields seems to be aligned on four bytes boundaries. For the DX3900 model the endianness is always fixed to big endian. The signature regular expression is "^(KDK INFO[a-zA-Z0-9]* )", the maker is KODAK. The meaning of the tags is as follows:

BYTE ??? firmware version? This is always 3
BYTE Compression 1 = normal, 2 = 2160x1440 high compression
BYTE BurstMode 0 = off, 1 = on
BYTE MacroMode 0 = normal, 1 = close-up
SHORT PixelXDimension allowed 2160x1440, 1800x1200,
SHORT PixelYDimension / values: 1536x1024, 1080x720
SHORT Year the year value, with four digits
BYTE Month the month value (in [1,12])
BYTE Day the day value (in [1,31])
BYTE Hour the hour value (in [0,23])
BYTE Minute the minute value (in [0,59])
BYTE Second the second value (in [0,59])
BYTE SubSecond (in 130th of seconds?)
SHORT ??? ???
BYTE ??? ???
BYTE ShutterMode 0 = auto, 32 = manual
BYTE MeteringMode 0 = multi-pattern, 1=centre weight., 2=centre spot
BYTE BurstSequenceIndex index in [1,8], 0 if burst mode off
SHORT FNumber 100 times the Exif F-number
LONG ExposureTime in 10^-5 seconds
SSHORT ExposureBiasValue 1000 times the exposure bias in [-2,+2 step .5]
SHORT ??? ???
LONG ???
LONG ??? is this an estimate of the subject
LONG ??? / distance? If so, it is very rough.
LONG ??? /
BYTE FocusMode 0 = auto, 2 = close, 3 = infinity
BYTE ??? always 2
SHORT ??? ???
SSHORT PanoramaMode 0 = normal, -1 = focus at infinity
SHORT SubjectDistance (x-28)*2.54+7 looks like the distance in cm
BYTE WhiteBalance 0 = normal, 1 = fluor., 2 = tungsten, 3 = daylight
(27 bytes with unknown meaning here)
BYTE FlashMode 0 = auto, 1 = on, 2 = off, 3 = red-eyes
BYTE FlashFired 0 = yes, 1 = no
SHORT ISOSpeedMode the requested speed in {100,200,400} or zero
SHORT ??? ???
SHORT TotalZoomFactor 100 times the zoom factor in [+1,+6 step 0.1]
SHORT DateTimeStampMode 0 = none, [1,6] = the six modes
SHORT ColourMode 1 = black & white, 2 = sepia, 32 = colour
SHORT DigitalZoomFactor 100 times the zoom factor in [+1,+3 step 0.1]
BYTE ??? always zero
SBYTE Sharpness 0 = standard, 1 = sharp, -1 = soft
(808 bytes with unknown meaning here, maybe a thumbnail?)

Text::Roman is a Perl module that converts roman algarism in integer numbers and the contrary, recognize algarisms.

SYNOPSIS

use Text::Roman;

print roman(123);

Text::Roman::roman() is a very simple algarism converter. It converts a single integer (in arabic algarisms) at a time to its roman correspondent. The conventional roman numbers goes from 1 up to 3999. MROMANS (milhar romans) range is 1 up to 3999*1000+3999=4002999.

Up to these number we will found symbols as:??????but they do not concern this specific package. There is no concern for mix cases, like Xv, XiiI, as legal roman algarism numbers.

roman($int): return string containing the roman corresponding to the given integer, or if the integer is out of domain...

roman2int($str): return if $str is not roman or return integer if it is.

isroman($str): verify whether the given string is a conventional roman number, if it is return 1; if it is not return 0...

Quite same follows for mroman2int($str) and ismroman($str), except that these functions treat milhar romans.

Xnee is a suite of programs that can record, replay and distribute user actions under the X11 environment. Think of GNU Xnee as a robot that can imitate the job you just did.
Xnee can be used to:
- Automate tests e.g nightly automatic regression tests
- Demonstrate programs e.g record and replay a user interaction with your system
- Distribute actions e.g teachers actions can be sent to all students desktops
- Record and replay macro e.g Tie a key modifier combination (e.g using xkeymouse) to replay a recorded session. The macro is WM- and program independent.
- Retype a file e.g When testing an editor, Xnee can type in the content of a file. This can be compared with the original and thereby
Xnee consists of a library and two applications:
- cnees not an event amulator Command line program
- gnees not an emulator either Graphical User Interface (GUI) program
- libxnee is basically xnee Library used by cnee and gnee
All Xnee applications (gnee and cnee) receives X11 protocol data (e g XEvents) from an X server using the libxnee and prints them to a file. This file is used later on when replaying.
Events directly generated by the user (e.g KeyPress) can be replayed or faked. Requests, replies, errors and events not directly generated by the user (e.g MapNotify) can be recorded as well. By using these data Xnee applications can replay with synchronisation. This is not only useful but essential.
In order to verify that a program does the job its supposed to do, certain tests have to be made. These tests are, IMHO, perhaps the most boring things a programmer can do. To release the programmer from this burdon Xnee is made.
Xnee started out as a commad line program. During the development phase the main functionality was broken out to a library, called libxnee. The command line program changed its name to cnee. The thought behind making the library was to enable the writing of other clients than just a command line. Today there is a GUI program, gnee that uses the library.
With Xnee testcase(s) can be recorded and later on replayed. Xnee can also distribute events (both when recording and replaying) to other displays.
Xnee uses X Windows System.
Enhancements:
- doc/Makefile.in was missing and has been added. gnee->About->Close and pnee->About->Close were faulty and have been fixed.

Netscape::HistoryURL is a URI::URL subclass with Netscape history information.

SYNOPSIS

use Netscape::HistoryURL;

$url = new Netscape::HistoryURL(http://foobar.com/,
LAST, FIRST, COUNT, EXPIRE, TITLE);

The Netscape::HistoryURL module subclasses URI::URL to provide a URL class with methods for accessing the information which is stored in Netscapes history database.

The history database is used to keep track of all URLs you have visited. This is used to color previously visited URLs different, for example. The information stored in the history database depends on the version of Netscape being used.

MIME::Lite is a low-calorie MIME generator Perl module.

SYNOPSIS

use MIME::Lite;
Create a single-part message:
### Create a new single-part message, to send a GIF file:
$msg = MIME::Lite->new(
From =>me@myhost.com,
To =>you@yourhost.com,
Cc =>some@other.com, some@more.com,
Subject =>Helloooooo, nurse!,
Type =>image/gif,
Encoding =>base64,
Path =>hellonurse.gif
);
Create a multipart message (i.e., one with attachments):
### Create a new multipart message:
$msg = MIME::Lite->new(
From =>me@myhost.com,
To =>you@yourhost.com,
Cc =>some@other.com, some@more.com,
Subject =>A message with 2 parts...,
Type =>multipart/mixed
);

### Add parts (each "attach" has same arguments as "new"):
$msg->attach(Type =>TEXT,
Data =>"Heres the GIF file you wanted"
);
$msg->attach(Type =>image/gif,
Path =>aaa000123.gif,
Filename =>logo.gif,
Disposition => attachment
);
Output a message:
### Format as a string:
$str = $msg->as_string;

### Print to a filehandle (say, a "sendmail" stream):
$msg->print(*SENDMAIL);
Send a message:
### Send in the "best" way (the default is to use "sendmail"):
$msg->send;

In the never-ending quest for great taste with fewer calories, we proudly present: MIME::Lite.

MIME::Lite is intended as a simple, standalone module for generating (not parsing!) MIME messages... specifically, it allows you to output a simple, decent single- or multi-part message with text or binary attachments. It does not require that you have the Mail:: or MIME:: modules installed.

You can specify each message part as either the literal data itself (in a scalar or array), or as a string which can be given to open() to get a readable filehandle (e.g., "
You dont need to worry about encoding your message data: this module will do that for you. It handles the 5 standard MIME encodings.

If you need more sophisticated behavior, please get the MIME-tools package instead. I will be more likely to add stuff to that toolkit over this one.

HTTP::MobileAgent::EZweb is a EZweb implementation.

SYNOPSIS

use HTTP::MobileAgent;

local $ENV{HTTP_USER_AGENT} = "UP.Browser/3.01-HI02 UP.Link/3.2.1.2";
my $agent = HTTP::MobileAgent->new;

printf "Name: %sn", $agent->name; # "UP.Browser"
printf "Version: %sn", $agent->version; # 3.01
printf "DevieID: %sn", $agent->device_id; # HI02
printf "Server: %sn", $agent->server; # "UP.Link/3.2.1.2"

# e.g.) UP.Browser/3.01-HI02 UP.Link/3.2.1.2 (Google WAP Proxy/1.0)
printf "Comment: %sn", $agent->comment; # "Google WAP Proxy/1.0"

# e.g.) KDDI-TS21 UP.Browser/6.0.2.276 (GUI) MMP/1.1
print "XHTML compiant!n" if $agent->xhtml_compliant; # true

HTTP::MobileAgent::EZweb is a subclass of HTTP::MobileAgent, which implements EZweb (WAP1.0/2.0) user agents.