Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 490 lines (373 sloc) 19.511 kb
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
1 Additional technical documentation about ImageWorsener
2 ======================================================
3
4 This file contains extra information about ImageWorsener. The main
5 documentation is in readme.txt.
6
7 Web site: <http://entropymine.com/imageworsener/>
8
9 Acknowledgments
10 ---------------
11
12 Some of the inspiration for this project came from these web pages:
13 "Gamma error in picture scaling"
14 http://www.4p8.com/eric.brasseur/gamma.html
15 "How to make a resampler that doesn't suck"
16 http://www.virtualdub.org/blog/pivot/entry.php?id=86
17
18 Information about resampling functions and other algorithms was gathered from
19 many sources, but ImageMagick's page on resizing was particularly helpful:
20 http://www.imagemagick.org/Usage/resize/
21
22 Alternatives
23 ------------
24
25 There are many applications and libraries that do image processing, but in the
26 free software world, the leader is ImageMagick (http://www.imagemagick.org/).
1315b9f @jsummers Typo fixes, etc.
authored
27 Or you might prefer ImageMagick's conservative alter-ego, GraphicsMagick
28 (http://www.graphicsmagick.org/).
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
29
73549dd @jsummers First try at supporting the GNU autotools build system.
authored
30 Installing / Building from source
31 ---------------------------------
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
32
632465b @jsummers Added a CMake script.
authored
33 Dependencies (optional):
4430c89 @jsummers Basic support for the WebP file format.
authored
34 libpng <http://www.libpng.org/pub/png/libpng.html>
35 zlib <http://zlib.net/>
36 libjpeg <http://www.ijg.org/>
37 libwebp
38 <http://www.webmproject.org/code/#libwebp_webp_image_decoder_library>
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
39
63e8042 @jsummers Minor cleanup of autotools stuff.
authored
40 Here are four possible ways to build ImageWorsener:
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
41
632465b @jsummers Added a CMake script.
authored
42 * Prebuilt Visual Studio 2008 project files
43
6a4f53a @jsummers Moved Visual Studio project files to "scripts" directory.
authored
44 Open the scripts/imagew2008.sln file in Visual Studio 2008 or newer.
632465b @jsummers Added a CMake script.
authored
45
46 To compile without libwebp: Edit the project settings to not link to
47 libwebp.lib, and change the line in src/imagew-config.h to
48 "#define IW_SUPPORT_WEBP 0".
49
50 * Generic Makefile
51
52 In a Unix-ish environment, try typing "make -C scripts". It should build an
53 executable file named "imagew" or "imagew.exe".
54
55 To compile without libwebp: Set the "IW_SUPPORT_WEBP" environment variable to
56 "0" (type "IW_SUPPORT_WEBP=0 make").
57
73549dd @jsummers First try at supporting the GNU autotools build system.
authored
58 * Using autotools
59
60 Official source releases contain a file named "configure". In simplest form,
63e8042 @jsummers Minor cleanup of autotools stuff.
authored
61 run
62 ./configure
63 then
64 make
73549dd @jsummers First try at supporting the GNU autotools build system.
authored
65
63e8042 @jsummers Minor cleanup of autotools stuff.
authored
66 Many options can be passed to the "configure" utility. For help, run
67 ./configure --help
68 Suggested options:
69 CFLAGS="-g -O3" ./configure --disable-shared
73549dd @jsummers First try at supporting the GNU autotools build system.
authored
70
71 If there is no "configure" file in the distribution you're using, you need to
63e8042 @jsummers Minor cleanup of autotools stuff.
authored
72 generate it by running
73 scripts/autogen.sh
74 You must have GNU autotools (autoconf, automake, libtool) installed. To clean
75 up the mess made by autogen.sh, run
76 scripts/autogen.sh clean
73549dd @jsummers First try at supporting the GNU autotools build system.
authored
77
78 * Using CMake (deprecated?)
632465b @jsummers Added a CMake script.
authored
79
80 CMake is a utility that generates Makefiles and project files.
81
82 If you don't have CMake installed, you can download it from
83 <http://www.cmake.org/>.
84
85 In a Unix-ish environment:
86
87 $ mkdir build
88 $ cd build
89 $ cmake ..
90 $ make
91
92 Using CMake from Windows is not recommended at this time, but you can try it
93 if you want.
94
95 First, set your environment variables correctly by running a command prompt
96 via Start -> All Programs -> Microsoft Visual [whatever] ->
97 Visual Studio Tools -> Visual Studio Command Prompt. If you can't find such
98 a utility, look for a script named VCVARS32.BAT and run that.
99
100 To build from the command line:
101
102 > cd <path_to_imagew>
103 > mkdir build
104 > cd build
105 > cmake ..
106 > nmake
107
108 To build from the IDE:
109
110 > cd <path_to_imagew>
111 > mkdir build
112 > cd build
113 > cmake -G "Visual Studio 9 2008" ..
114 Now open the imagew.sln file.
115
116 Instead of "Visual Studio 9 2008", you can name any "generator" supported by
117 CMake. Consult the CMake documentation. Here are some examples:
118
119 "Visual Studio 7 .NET 2003"
120 "Visual Studio 8 2005"
121 "Visual Studio 8 2005 Win64"
122 "Visual Studio 9 2008"
123 "Visual Studio 9 2008 Win64"
124 "Visual Studio 10"
125 "Visual Studio 10 Win64"
126
127 This is not meant to imply that IW is guaranteed to work with all of the
128 compilers listed above.
4430c89 @jsummers Basic support for the WebP file format.
authored
129
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
130 Philosophy
131 ----------
132
5cedd88 @jsummers Some updates to the technical notes.
authored
133 ImageWorsener attempts to have good defaults. The user should not have to know
134 anything about gamma correction, bit depths, filters, windowing functions,
135 etc., in order to get good results.
136
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
137 IW tries to be as accurate as possible. It never trades accuracy for speed.
138 Really, it goes too far, as nearly everyone would rather have a program that
139 works twice as fast and is imperceptibly less accurate. But there are lots
140 of utilities that are optimized for speed, and there would be no reason for
141 IW to exist if it worked the same as everything else.
142
166ae7f @jsummers Minor cleanup.
authored
143 I don't intend to add millions of options to IW. It is nearly feature complete
144 as it is. I want most of the options to have some practical purpose (which may
145 include the ability to imitate what other applications do). Admittedly, some
146 fairly useless options exist just for orthogonal completeness, or to scratch
147 some particular itch I had.
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
148
149 I've taken a lot of care to make sure the resizing algorithms are implemented
150 correctly. I won't add an algorithm until I'm sure that I understand it. This
151 isn't so easy. There's a lot of confusing and contradictory information out
152 there.
153
166ae7f @jsummers Minor cleanup.
authored
154 IW's command line should not be thought of as a sequence of image processing
155 commands. Instead, imagine you're describing the properties of a display
156 device, and IW will try to create the best image for that device. For example,
157 if you tell IW to dither an image and resize it, it knows that it should
158 resize the image first, then dither it, instead of doing it in the opposite
159 order.
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
160
d722d53 @jsummers Changed the default bitdepth to always be 8, instead of trying to mai…
authored
161 IW does not really care about the details of how an image is stored in a file;
162 it only cares about the essential image itself. For example, a 1-bit image is
8346f32 @jsummers Minor documentation update.
authored
163 treated the same as an 8-bit representation of the same image. If you resize a
164 bilevel image, you'll automatically get high quality grayscale image, not a
165 low quality bilevel image.
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
166
deac14e @jsummers Updated technical.txt.
authored
167 Architecture
168 ------------
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
169
170 IW has three components: The core library, the auxiliary library, and the
171 command-line utility.
172
173 The core library does the image processing, but does not do any file I/O. It
a235219 @jsummers Support for reading GIF images.
authored
174 knows almost nothing about specific file formats. It has access to the
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
175 internal data structures defined in imagew-internals.h. It does not make any
176 direct calls to the auxiliary library.
177
178 The auxiliary library consists of the file I/O code that is specific to file
179 formats like PNG and JPEG. It does not use the internal data structures from
180 imagew-internals.h.
181
182 The public interface is completely defined in the imagew.h file. It includes
183 declarations for both the core and auxiliary library.
184
185 The command-line utility is implemented in imagew-cmd.c. It uses both the core
186 library and the auxiliary library.
187
188 The core and auxiliary libraries are separated in order to break dependencies.
189 For example, if your application supports only PNG files, you can probably
190 (given how most linkers work) build it without linking to libjpeg.
191
8346f32 @jsummers Minor documentation update.
authored
192 Files in core library:
193 imagew-internals.h, imagew-main.c, imagew-resize.c, imagew-opt.c,
194 imagew-api.c, imagew-util.c
195
196 Files in auxiliary library:
197 imagew-png.c, imagew-jpeg.c, imagew-webp.c, imagew-gif.c, imagew-miff.c,
2f2c3d0 @jsummers Moved some code for reading/writing a file of any format the into the
authored
198 imagew-bmp.c, imagew-tiff.c, imagew-zlib.c, imagew-allfmts.c
8346f32 @jsummers Minor documentation update.
authored
199
200 Files in command-line utility:
201 imagew-cmd.c, imagew.rc, imagew.ico
202
203 Other files:
204 imagew.h (Public header file, Core, Aux., Command-line)
79accec @jsummers Minor cleanup.
authored
205 imagew-config.h (Core, Aux., Command-line)
8346f32 @jsummers Minor documentation update.
authored
206
65aae08 @jsummers Made it easier to compile using "float" instead of "double" as the da…
authored
207 Double-precision floating point?
208 --------------------------------
209
210 IW can be compiled to use any available floating point type for its internal
211 representation of samples. (Unfortunately, it's impractical to make this a
212 run-time option.) Its default is currently set to be "double", which is
213 usually an 8-byte floating-point number. This may seem like overkill, and I
8346f32 @jsummers Minor documentation update.
authored
214 admit, it probably is. Using double precision shouldn't have much effect on
215 performance, especially if it's compiled as a 64-bit application. But it will
216 use a lot more memory.
65aae08 @jsummers Made it easier to compile using "float" instead of "double" as the da…
authored
217
8346f32 @jsummers Minor documentation update.
authored
218 The real reason I haven't switched to single-precision is simply because I
219 haven't found any particular reason to do so. IW is intended to be used on
220 reasonably modern PCs, and it does not aim for low memory use or the highest
221 possible performance, so this might not be much of an issue.
65aae08 @jsummers Made it easier to compile using "float" instead of "double" as the da…
authored
222
8346f32 @jsummers Minor documentation update.
authored
223 For 8-bit target images, switching to 4-byte floating point affects very
224 roughly one pixel in every 50,000. For 16-bit target images, it's more like
225 one pixel in every few hundred. Not that that means anything -- the image
226 processing algorithms being used aren't even "correct" to that degree.
65aae08 @jsummers Made it easier to compile using "float" instead of "double" as the da…
authored
227
deac14e @jsummers Updated technical.txt.
authored
228 4-byte floating-point numbers give you about 7 significant digits, which in
65aae08 @jsummers Made it easier to compile using "float" instead of "double" as the da…
authored
229 extreme cases may not be quite enough. Particularly for 16-bit target images,
230 when working in a linear colorspace, bright samples are much, much brighter
1315b9f @jsummers Typo fixes, etc.
authored
231 than the dimmest samples. If IW has to add a huge number of dim pixels together
65aae08 @jsummers Made it easier to compile using "float" instead of "double" as the da…
authored
232 with just a few bright pixels, 7 significant digits might not be enough to
233 do the kind of accurate calculations it strives for.
234
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
235 Unicode
236 -------
237
7ed6377 @jsummers Added -encoding option, to allow more control over the character enco…
authored
238 Text files like this one notwithstanding, I've had enough of ASCII, and I want
239 to support Unicode even in an application like this that does very little with
240 text. IW supports Unicode filenames, and will try to use Unicode quotation
241 marks, arrows, etc., if possible. If IW does not correctly figure out the
242 encoding you want, you can explicitly set it using the "-encoding" option. In
243 a Unix environment, Unicode output can also probably be turned off with
244 environment variables, such as by setting "LANG=C".
245
246 The encoding setting does not affect the interpretation of the parameters on
247 the command line. This should not be a problem in Windows, because Windows can
248 translate them. But on a Unix system, they are always assumed to be UTF-8.
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
249
69b58dc @jsummers Made the library use only UTF-8 as its character encoding.
authored
250 All strings produced by the library (e.g. error messages) are encoded in UTF-8.
251 Applications must convert them if necessary.
252
429fbda @jsummers Changed the default downscaling filter to catrom.
authored
253 Rationale for the default resizing algorithm
254 --------------------------------------------
5cedd88 @jsummers Some updates to the technical notes.
authored
255
429fbda @jsummers Changed the default downscaling filter to catrom.
authored
256 By default, IW uses a Catmull-Rom ("catrom") filter for both upscaling and
257 downscaling. Why?
5cedd88 @jsummers Some updates to the technical notes.
authored
258
259 For one thing, I don't want to default to a filter that has any inherent
260 blurring. A casual user would expect that when you "resize" an image without
261 changing the size, it will not modify the image at all. This requirement
262 eliminates mitchell, gaussian, etc.
263
429fbda @jsummers Changed the default downscaling filter to catrom.
authored
264 The "echoes" produced by filters like lanczos(3) are too weird, I think; and
265 they can be too severe when using proper gamma correction.
266
5cedd88 @jsummers Some updates to the technical notes.
authored
267 When upscaling, hermite, triangle, and pixel mixing just don't have acceptable
429fbda @jsummers Changed the default downscaling filter to catrom.
authored
268 quality. That really only leaves catrom and lanczos2. I somewhat arbitrarily
269 chose catrom over lanczos2 (they are almost identical).
5cedd88 @jsummers Some updates to the technical notes.
authored
270
271 When downscaling, the differences between various algorithms are much more
429fbda @jsummers Changed the default downscaling filter to catrom.
authored
272 subtle. Hermite and pixel mixing are both reasonable candidates, and are nice
273 in that they have no ringing at all. But they're not quite as sharp as catrom,
274 and can do badly with images that have thin lines or repetetive details.
5cedd88 @jsummers Some updates to the technical notes.
authored
275
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
276 Colorspaces
277 -----------
278
279 Unless it has reason to believe otherwise, IW assumes that images use the sRGB
280 colorspace. This is the colorspace that standard computer monitors use, and
281 it's a reasonable assumption that most computer image files (whether by
282 accident or design) are intended to be directly displayable on computer
283 monitors.
284
ac84d3f @jsummers Minor formatting and spelling fixes.
authored
285 It does this even if the file format predates the invention of sRGB, and/or
8346f32 @jsummers Minor documentation update.
authored
286 the file format specification says that, by default, colors have a gamma of
287 2.2 (which is similar, but not identical, to sRGB).
288
289 IW does not support ICC color profiles. Full or partial support for them may
290 be added in a future version.
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
291
292 TIFF output support
293 -------------------
294
295 IW mainly sticks to the "baseline" TIFF v6 specification, but it will write
296 images with a sample depth of 16 bits, which is not part of the baseline spec.
297 It writes transparent images using unassociated alpha, which is probably less
298 common in TIFF files than associated alpha, and may not be supported as well
299 by TIFF viewers.
300
166ae7f @jsummers Minor cleanup.
authored
301 TIFF colorspaces
302 ----------------
303
34eb803 @jsummers Trivial cleanup.
authored
304 When writing TIFF files, IW uses the TransferFunction TIFF tag to describe the
166ae7f @jsummers Minor cleanup.
authored
305 colorspace that the output image uses. I doubt that many TIFF viewers read
34eb803 @jsummers Trivial cleanup.
authored
306 this tag, and actually, I don't even know how to test whether I'm using it
166ae7f @jsummers Minor cleanup.
authored
307 correctly. You can disable the TransferFunction tag by using the "-nocslabel"
308 option.
309
ffb445d @jsummers Fixes and improvements to the GIF decoder, to handle the rare case th…
authored
310 GIF screen size vs. image size
311 ------------------------------
312
166ae7f @jsummers Minor cleanup.
authored
313 Every GIF file has a global "screen size", and a sequence of one or more
314 images. Each image has its own size, and an offset to indicate its position on
315 the screen. By default, IW treats the screen size as the final image size, and
316 paints the GIF image (as selected by the -page option) onto the screen at the
317 appropriate position. Any area not covered by the image will be made
318 transparent.
ffb445d @jsummers Fixes and improvements to the GIF decoder, to handle the rare case th…
authored
319
166ae7f @jsummers Minor cleanup.
authored
320 If you use the -noincludescreen option, it will instead ignore the screen size
efe1634 @jsummers Added -noincludescreen option, to ignore the GIF "screen" when readin…
authored
321 and the image position, and extract just the selected image.
ffb445d @jsummers Fixes and improvements to the GIF decoder, to handle the rare case th…
authored
322
437098d @jsummers Added some documentation about support for MIFF files.
authored
323 MIFF support
324 ------------
325
326 IW can write to ImageMagick's MIFF image format, and can read back the small
327 subset of MIFF files that it writes. MIFF supports floating point samples, and
328 this is intended to be used to store intermediate images, in order to perform
329 multiple operations on an image with no loss of precision. MIFF support is
330 experimental and incomplete. Some features, such as dithering, may not be
331 supported with floating point output.
332
333 To use ImageMagick to write a MIFF file that IW can read, try:
334 $ convert <input-file> -define quantum:format=floating-point -depth 32 \
2737652 @jsummers Support for writing Zip-compressed MIFF files. Made Zip compression the
authored
335 -compress Zip <output-file.miff>
437098d @jsummers Added some documentation about support for MIFF files.
authored
336
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
337 Nonsquare pixels
338 ----------------
339
340 If you use one of the scaling options that doesn't change the aspect ratio, IW
341 always writes an image with square pixels. Example: Suppose the input image is
342 a fax with an X density of 204dpi and a Y density of 96dpi. It will scale the
343 Y dimension by a factor that's 204/96 times larger than the X dimension's
344 scaling factor.
345
346 "Color" of transparent pixels
347 -----------------------------
348
349 In image formats that use unassociated alpha values to indicate transparency,
350 pixels that are fully transparent still have "colors", but those colors are
351 irrelevant. IW will not attempt to retain such colors, and will make fully-
352 transparent pixels black in most cases. An exception is if the output image
353 uses color-keyed transparency, in which case it uses a different strategy.
354
f66f608 @jsummers Changed the box filter to have more predictable behavior.
authored
355 Box filter
356 ----------
357
358 It's not obvious how a box filter should behave when a source pixel falls
359 right on the boundary between two target pixels. There seem to be several
360 options:
361 1. "Clone" the source pixel, and put it into both "boxes" (target pixels).
362 2. "Split" the source pixel, and put it into both boxes, but with half the
363 usual weight.
364 3. Arbitrarily select one of the two boxes (which could be the left box, the
365 right box, or some other strategy like selecting the box nearest to the
366 center of the image).
367 4. Ignore the problem, in which case the algorithm may behave unpredictably,
368 due to the intricacies of floating point rounding. It may sometimes clone,
369 sometimes round, and sometimes skip over a pixel completely.
370
371 IW arbitrarily selects the left (or top) box. To make it select the right (or
372 bottom) box instead, you could translate the image by a very small amount;
373 e.g. "-translate 0.000001,0.000001". To use the "clone" strategy, use a very
374 small blur; e.g. "-blur 1.000001".
375
885ca8d @jsummers Clearly defined the behavior of the nearest-neighbor algorithm.
authored
376 Nearest neighbor
377 ----------------
378
379 When using the nearest neighbor algorithm, if a target pixel is equally close
380 to two source pixels, it will be given the color of the one to the right (or
381 bottom). This is the same tiebreaking logic as is used for the box filter. (It
382 may sound like it's the opposite, but it's not: image features are shifted to
383 the left in each case.) As with a box filter, you can change this by
384 translating the image by a very small amount.
385
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
386 PNG sBIT chunks
387 ---------------
388
389 If a PNG image contains the rarely-used sBIT chunk, IW will ignore any bits
390 that the sBIT chunk indicates are not significant.
391
392 Suppose you have an 8-bit grayscale image with an sBIT chunk that says 3 bits
393 are significant. If the app that wrote the file was not defective, there will
394 probably be only 8 colors in the image. The image might contain these colors:
395
396 00000000 = 0/255 = 0.00000000
397 00100100 = 36/255 = 0.14117647
398 01001001 = 73/255 = 0.28627450
399 01101101 = 109/255 = 0.42745098
400 10010010 = 146/255 = 0.57254901
401 10110110 = 182/255 = 0.71372549
402 11011011 = 219/255 = 0.85882352
403 11111111 = 255/255 = 1.00000000
404
405 IW, though, will see only the significant bits, and will interpret the image
406 like this:
407
408 000 = 0/7 = 0.00000000
409 001 = 1/7 = 0.14285714
410 010 = 2/7 = 0.28571428
411 011 = 3/7 = 0.42857142
412 100 = 4/7 = 0.57142857
413 101 = 5/7 = 0.71428571
414 110 = 6/7 = 0.85714285
415 111 = 7/7 = 1.00000000
416
417 So, the interpretation is slightly different (e.g. 0.14285714 instead of
418 0.14117647).
419
420 Ordered dithering + transparency
421 --------------------------------
422
423 Ordered (or halftone) dithering with IW can produce poor results when used
424 with images that have partial transparency. If you ordered-dither both the
425 colors and the alpha channel, you can have a situation where all the (say)
34eb803 @jsummers Trivial cleanup.
authored
426 darker pixels are made transparent, leaving only the lighter pixels visible,
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
427 and making the image much lighter than it should be. This happens because the
ac84d3f @jsummers Minor formatting and spelling fixes.
authored
428 same dither pattern is used for two purposes (color thresholding and
429 transparency thresholding).
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
430
70b1785 @jsummers By default, don't clamp alpha samples before using them to apply a
authored
431 Obscure details about clamping, backgrounds, and alpha channel resizing
432 -----------------------------------------------------------------------
433
434 "Clamping" is the restricting of sample values to the range that is
435 displayable on a computer monitor. This must be done when writing to any file
436 format other than MIFF. But if you use -intclamp, it will also be done at
437 other times. Essentially, it will be done as often as possible, after every
438 dimension of every resizing operation. If a background is applied after
439 resizing, clamping will be done individually to both the alpha channel and the
440 color channels, then the background will be applied.
441
442 If you don't use -intclamp, no clamping will be done, except as the very last
443 step. If IW applies a background after resizing the image, the alpha channel
444 will not be clamped first, so it could actually contain negative opacity
445 values. That's hard to envision, but the math works out, and you generally get
446 the same result as if you had applied the background before resizing.
447
448 Currently, the only time IW applies a background before resizing is when a
449 channel offset is being used. This means that using -offset can have
f763dfc @jsummers Removed the ability to use a different resize algorithm just for the …
authored
450 unexpected side effects if you also use -intclamp.
70b1785 @jsummers By default, don't clamp alpha samples before using them to apply a
authored
451
deac14e @jsummers Updated technical.txt.
authored
452 Cropping
453 --------
454
455 IW's -crop option crops the image before resizing it, completely ignoring any
456 pixels outside the region to crop. This is not quite ideal. Ideally, any pixel
457 that could have an effect on the pixels at the edge of the image should be kept
458 around until after the resize, then the crop should be completed. This is not
459 difficult in theory, but coding it would be messy enough that I haven't
460 attempted it.
461
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
462 To do
463 -----
464
465 Features I'm considering adding:
466
69d6996 @jsummers Support for specifying image sizes that are relative to the original …
authored
467 - More options for specifying the image size to use; e.g. "enlarge the image
468 only if it's smaller than a certain size".
469
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
470 - More options for aligning the input pixels with the output pixels.
471
5cedd88 @jsummers Some updates to the technical notes.
authored
472 - Support for reading BMP files.
473
8346f32 @jsummers Minor documentation update.
authored
474 - Ability to maintain PNG and GIF background colors.
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
475
8346f32 @jsummers Minor documentation update.
authored
476 - Hilbert curve dithering.
1315b9f @jsummers Typo fixes, etc.
authored
477
8346f32 @jsummers Minor documentation update.
authored
478 - Support for ICC color profiles.
716f7d1 @jsummers Added technical documentation file technical.txt.
authored
479
480 Contributing
481 ------------
482
483 I may accept code contributions, if they fit the spirit of the project. I will
484 probably not accept contributions on which you or someone else claims
485 copyright. At this stage, I want to retain the ability to change the licensing
486 terms unilaterally.
487
488 Of course, the license allows you to fork your own version of ImageWorsener if
489 you wish to.
Something went wrong with that request. Please try again.