File: README.beyondgif

package info (click to toggle)
xjig 2.4-14.1
  • links: PTS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 892 kB
  • sloc: cpp: 10,177; makefile: 1,142; perl: 23
file content (52 lines) | stat: -rw-r--r-- 2,728 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Notes in random order:

The internal data format for xjig's images shows its GIF heritage: it uses an
8-bit palette. To support non-paletted images, there are 3 ways to go:
  1. Convert the image to an 8-bit palette while loading it. This implies a
  loss of quality if the image contains more than 256 distinct colors.
  2. Make xjig use a non-paletted internal representation. This requires
  touching a lot of code that has nothing to do with the image file loader,
  so it would be more work. And then palettized images would have to be
  converted to truecolor while loading.
  3. Make xjig capable of using either pseudocolor or truecolor as its
  internal representation, and let the image file loader choose which one is
  appropriate. This would be a LOT more work.
So I'm doing it the easy way.

Actually converting an image with lots of colors to a 256-color palette is
not "easy" if you want it to look good afterward, but that's not important
right now. A good quantize() routine should be integrated into xjig. It would
even be useful for GIFs, if the display doesn't have a lot of empty slots in
its default colormap.

If there is a *serious* shortage of empty slots in the default colormap,
using a private colormap would be good, regardless of image format.

The following things are no longer GIF-specific and should be renamed:
  gif_cols

In GIFs, xjig looks for command line options and other xjig-specific
extensions embedded in the image file. This seems crazy. I'll leave open the
possibility of implementing it in other formats, but don't hold your breath.

I hate C++, so any code that I've touched will probably end up looking more
C-like than before. This is not an accident.

ppm was the first new image format I supported, because libppm (libnetpbm)
was very easy to use. jpeg came next because libjpeg has its own quantizer,
which is a big help. I wish I could call that quantizer independently from
the rest of libjpeg... it would be useful for improving the ppm loader. Oh
well, I guess #include "ppmquant.c" shouldn't be too hard to pull off. PNG
should be the next format to be supported, but libpng's documentation is
frightening.

Autodetection of image format would be a good thing to have, but choosing a
loader based on filename suffix is a little bit easier so I'll do it that way
first. In any case there should be a command line option to force the use of
a specific loader.

Although I'm working with Debian's patched source, everything I'm doing
should be applicable upstream. Slight problem: I don't know if there is a
surviving upstream. I might be it. For better usability outside Debian, there
should be configuration options to omit image types whose libraries are not
present.