summaryrefslogtreecommitdiffstats
path: root/krita/IMAGE_LIBRARIES
blob: 4b9bb2e1cadfa24d2c1b9ccd835b6a027302a164 (plain)
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
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
WARNING: OBSOLETE (Krita's internal code has become much better by now)

From time to time, people come up with the suggestion to use an
existing imaging library with Krita, to replace our own core. This
file contains a list of all libraries known to me, and a short
evaluation. 

Perhaps, one day, we will decide to either use an existing library, or
remodel our core after one of those. Of the libraries present, except
for our own Krita, Vigra look like it's the best bet from a technical
point of view, with Vips a good runner-up.


* Krita  (http://koffice.kde.org/krita)

Krita contains its own 2D image library, consisting of the tile
manager, the layer classes and KisPainter. We really should separate
this 2d lib from the interface code, and put it in a real lib with 
a well-defined interface.

Advantages:

	- Already works
	- Optimized for interactive work
	- Allows different colour models
	- Uses GraphicsMagick or ImageMagick for loading and saving.

Disadvantages:
	
	- Does not work well with different channel depths
	- Not integrated with CMS
	- TileManager complicated and slow for pixel reading and
	  writing.
	  
* Gimp (http://www.gimp.org)

The Gimp contains a complex core that allows interactive painting of
images with a channel depth of 8 bits.

Advantages:

	- Well tested, very complete
	- Optimized for interactive usage

Disadvantages:

	- Written in C.
	- Not readily available as a library.
	- Depends on glib and gtk
	- 8-bit only
	- No colour models
	- Has problems handling really large images

* Vigra (http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/)

Vigra is a C++ imaging library written by Ullrich Koetthe to
demonstrate his Phd thesis on flexible image algorithms.

Advantages:

	- Supports very large images
	- Supports colour models
	- Supports different bit depths through templating
	- C++
	- Relatively small
	- Relatively well-documented

Disadvantages:

	- License incompatible with GPL?
	- Not optimized for interactive use
	- Unsure about future development since this was a research
	  project.

* Vips (http://www.vips.ecs.soton.ac.uk/)

Vips is a C library with a C++ layer. It has been designed for
handling very large images, mainly in the context of research into
paintings in museums like the National Gallery. It comes with a gtk2
gui.

Advantages:

	- Handles very large images
	- Handles colour models
	- Handles different bit depths
	- C++ interface

Disadvantages:

	- Not optimized for paintbox type apps (even though it is
	  possible).
	- Very large.

* VXL (http://vxl.sourceforge.net/)

VXL is a collection of small libraries that are used for compution
vision and imaging purposes in an academic setting.

Advantages:

	- Handles very large images
	- C++

Disadvantages:

	- Not recently updated
	- Comes with its own core libraries that replace standard C++
	- Optimized for simple rgb images.
	- No license at all
	- Badly documented

* CImg (http://cimg.sourceforge.net/)

CImg is a very cool, very small library that offers some extremely
innovative image effects, like inpainting of damaged or noise images.

Advantages:
	
	- Small
	- GPL
	- Cool stuff

Disadvantages:

	- Everything, including GUI stuff, in one header file.
	- badly documented.


* Gegl (http://www.gegl.org/)

Gegl was intended to become the Gimp 2.0 core, but development had
stalled so much that the move to Gegl didn't happen before Gimp 2.0.
However, the Thawte millionaire whose name has escaped me, has
promised to support gegl development financially, freeing the
developer to work full-time on it. It is, more or less, an attempt to
write a templated library in C++ with the help of a custom language to
describe image operations.

Advantages:
	
	- It's got money behind it
	- Small
	- Optimized for interactive use

Disadvantages:

	- Not finished yet
	- C
	- Complex hack around the fact that C is a low-level language

* libart_lgpl (http://www.levien.com/libart/)

Libart isn't really an image library, but rather a canvas that can be
used to paint images on. It is optimized for vector graphics, and is
used by Karbon to render tqshapes before display.

Advantages:

	- Raph Levien is really good at this stuff, so libart is
	  quality

Disadvantages:

	- C
	- It isn't an image library, really


* java2D (http://java.sun.com/j2se/1.4.2/docs/guide/2d/index.html)


Java2D is more or less complete library to write a paint app around.
It offers image types, colour spaces, kernel convolutions and text.
It's in Java, of course, and the free re-implementation is not done
yet, and besides, is based around Cairo.

Advantages:
	
	- Neat OO design
	- Complete

Disadvantages:

	- Java
	- Not free
	- Has some legacy cruft.

* ImageMagick/GraphicsMagick (http://imagemagick.org/, http://www.graphicsmagick.org/)

GraphicsMagick is ImageMagick with a different license, and a
focus on API stability. GM and IM now also differ slightly in terms of
features offered. Krita used to be based around IM (which can still be
seen in many places in the code). The IM core was dropped in favour of
the present core because it turned out that IM was not re-entrant,
making it hard to use in an interactive application.

Advantages:

	- Mature
	- C++ interface
	- Full-featured
	- RGB and CMYK (but not more)
	- License compatible with Krita
	- Under active development

Disadvantages:

	- Bit-depth a compile-time option
	- Not re-entrant: not optimized for interactive use.

* Paintlib2 (http://www.paintlib.de/paintlib/)

A portable (windows/Linux) library for image loading, manipulation and
saving. The same kind of thing as IM/GM, but not quite as mature.

Advantages:

Disadvantages:
 	
	- No support for larger bit depths per channel
	- Windows (bmp) centric
	- Development seems to have stopped in 2000


* Antigrain (http://www.antigrain.com/)

Antigrain is a graphics lib that specializes in high-quality anti-aliasing. It can be 
useful to mine for algorithms, but is mainly a library to render vector data to bitmaps,
just like libart or cairo.

Advantages:

	- High quality algorithms
	- Completely free license.
	- Colour-space agnostic

Disadvantages:

	- Not a complete 2D library
	- self-admittedly complex and hard to use.
	- No support for greater bit-depths.

* The Visualization Toolkit (VTK, http://public.kitware.com/VTK/)

A very big C++ library for 2d and 3d image processing and visualisation. It's
too big to easily evaluate for me.

Advantages
	
	- It is used in other Qt applications, like Julius
	- Probably very good

Disadvantages

	- The book is very expensive
	- Uses its own make equivalent, CMake
	- Very large

* Java Advanced Imaging