| I'm using a new feature (ie. V3.1) of C-Lab's Notator sequencer - the
image dump print facility. Notator dumps notation pages to diskfile in
".IMG" format , which is readable by 1st-Word, Calamus,...
However, I want to take these files elsewhere (eg. VaxStation,
PC, Mac,...), and so I have to convert them into something readable
by the 'other' system, such as Postsript, GIF, Mac, etc.
Does anyone know:
(1) A utility to convert these files ?
Many convertors seem to limit the bounds of conversion to the
screen resolution. This is no good - such a page of notation at
300 DPI is HUGE.
(2) The format of them ?
If it is a standard bit-image pixel dump format, then it should
be easy enough to convert this to a PostScript 'image' entity.
I'll do this if I can get some info on the .IMG file format.
Any helpers ?
Jim Burke
|
| Jeff,
Thanks for the pointer & offer. Unfortunately, I can't upload an
image until next week. However, try Touch-up with the ".IMG" files
distributed with 1st-Word (ie. the clipboard directory). If it can
handle them, then it should handle the (much larger) notation images.
The reason I ask you to try this, is that I got a few utilities (AIM ?)
which claim image-to-postscript conversion. However, this did not work
correctly with the 1st-Word images. There was something there in the
converted image OK, but whatever it was, it was garbled. It may have
been something to do with colour/mono (I use mono). Perhaps it expects
a different type of 'image' ?
I've never heard of "Touch-up". Is this available in the UK ?
Regards,
Jim
|
|
I remember that I looked over an article one or two years ago
that described the graphic formats of the Atari. I have no idea
how formats on a workstation looks like, so I can only give you
the information that I read in the magazine. Maybe with these
informations it's possible to write a convertor for our workstations.
It would open up completely new dimensions for writing documentations
at home and then transport them to a Station to print them out on
a LN or LPS. Here is what I found:
DOODLE: (*.DOO)
======================
Screenformat: 32,000 Bytes Picturedata, Bytes 1-32,000
no color range
Resolution: Low/medium/high
Filesize: 32,000 Bytes
DEGAS (normal) (*.PIx)
======================
Screenformat: 32,000 Bytes Picturedata, Bytes 35-32,034
32 Bytes color range, Bytes 3-34
(32 Bytes color animation data, Bytes 32,035-32,066)
Resolution: Low/medium/high
Filesize: 32,034 or 32,066 Bytes
ID: Byte 1: 00
Byte 2: resolution (0=low, 1=med, 2=high)
NEOCHROM (*.NEO)
======================
Screenformat: 32,000 Bytes Picturedata, Bytes 129-32,128
32 Bytes color range, Bytes 5-36
Resolution: low only
Filesize: 32,128 Bytes
ART Director (*.ART)
======================
Screenformat: 32,000 Bytes Picturedata, Bytes 1-32,000
32 Bytes color range, Bytes 32,001-32,032
another 15 color ranges for animations in
Bytes 32,033-32,512
Resolution: low only
Filesize: 32,512 Bytes
PACKED FORMATS:
---------------
IFF-Format (used in Amiga's DELUXE PAINT and Atari's DEGAS ELITE)
uses some blocks called CHUNK. The IFF-format also is available
for other things than graphic (music, text a.s.o.). The first
block in a IFF-file is the FORM-CHUNK that describes the kind of
file (lenght 8 Bytes).
Available are: 8SVX for 8 bit sample voice, SMUS for simple music
score, FTXT for formatted text and ILBM for interleaved bitmap.
Following the name of the CHUNK is it's lenght without the name (ID).
The next CHUNK is BMHD which means Bitmap Header. It contains
general information about the picture. The CMAP-CHUNK describes the
color range, 3 Bytes for every color. CRNG-Chunk contains data about
color rotation and shading (mostly available 4 times). The BODY-CHUNK
is the graphics part of the picture. In the following table the
letters mean: B=Byte, W=Word, L=Longword
FORM Chunk BMHD Chunk CMAP Chunk CRMG Chunk BODY Chunk
-------------------------------------------------------------------
total-lenght chunklenght chunklenght chunklenght chunklenght
(8 Byte) (L) (L) (L) (L) (L)
IFF-graphic width color 0 red zero picture data
(4B) (W) (B) (W) (B)
hight color 0 green speed a.s.o.
(W) (B) (W)
x-position color 0 blue active
(W) (B) (W)
y-position color 1 red lower color
(W) (B) (B)
bitplanes color 1 green upper color
(B) (B) (B)
masking color 1 blue
(B) (B)
compressing color 2 red
(B) (B)
zero color 2 green
(B) (B)
trancparency color 2 blue
(W) (B)
x-aspect color 3 red
(B) (B)
y-aspect color 3 green
(B) (B)
page width color 3 blue
(W) (B)
page hight a.s.o.
(W)
with a disk monitor these chunks are easily seen on a IFF-file.
Compressed DEGAS ELITE (*.PCx)
================================
Screenformat: with IFF compressed picture data starting at
Byte 35-xxx
color range: 32 Bytes, with IFF-standard starting at
Bytes 3-34
color animation: 32 Bytes, starting after picture data
resolution: low/medium/high
file-lenght: variable, depending on picture size
ID: Byte 1: 80
Byte 2: resolution (0=low, 1=med, 3=high)
remark: according to IFF-standard only with the
compression. Definition-Chunk of IFF is
not existing!
IMAGE-Format: (*.IMG), no color range!!!
-------------
developed by Digital Research to find a format that is
interchangeable between GEM-Computers. This is the format which is
used with Wordplus and the SNAPSHOT utility. An image-file looks
like described below.
Header, a certain amount of picturelines (some of them might be
double), in the lines a certain amount of Bytes (that might also
be double). That means, double-lines and double-bytes can be packed
together. A row of bytes cannot reach beyond the line border.
Header: (with variable lenght)
-------
ver_num: Version number of file (optional, can be anything)
head_len: Lenght of header
plane_num: Number of used planes (to determine color res.)
(1st plane = lowest bit of color)
pat_len: lenght of used patterns (mostly 2 Bytes)
pix_wid: width of pixels of the used device in micrometer
pix_hght: hight of pixels of the used device in micrometer
(this information enables a programm to calculate
the output correctly for e.g. printers...)
pix_num: pixels per screen line (width of actual picture)
scan_num: number of screen lines per picture (hight of picture)
every entry is two bytes. The appearance is as follows:
Line-Header: Four Bytes, first three bytes is the ID, the fourth
byte contains how many times the line repeats
( 00 00 FF nn )
Plane-Header: Every line consists of multiple planes (one in mono),
that can be compressed in themselves
line not compressed: 80 nn (nn = number of following bytes)
line with optional pattern: 00 nn (nn = number of pattern repetitions)
line with empty or full pattern: Bit 7 set = full pattern
Bit 7 reset = empty pattern
Bits 0-6 = Repetitions
Now the compressed picture data is following. From the header we know
how many lines and planes the picture has. Every line has it's header
that is also called vertical repetition factor (VRF) and is defined
like
this: constant Bytes 0,0,$FF, then number of repetitions. E.g. if the
picture is ten lines in hight, and all lines are identical, the VRF
would look like 0,0,$FF,$A plus the plane description. All planes must
be repeated, that means all identical lines with different colors must
be defined in different line descriptions.
How to distinguish between the planes: in the header of the image file,
Byte 7, is the lenght of line in pixel. Recalculate that into Bytes and
count them during decoding. Then the appearance of the next plane is
obvious. With the optional width in pixel the last bits might be
skipped (e.g. width = 65 pixel, that's 9 Bytes with the last one only
one bit used). Equal lines may be repeated, but also within a plane
a compression is possible. There are three possibilities:
1. plane-line has no equal patterns and is used original
2. plane-line has patterns with the width that is described in the
header
3. Special of 2: repeated bytes that have either all bits set or reset
These 3 possibilities are described in another header that is in front
of each line of a plane. If a programm can't compress according to
one of the three possibilities, so the line is used in the original
format. Then in front of the line there's a header like 80 nn with
nn = number of following bytes.
Bernd
|