1[Sat Jan 10 14:15:04 EST 1998] 2Version 1.01 -- 3 Fixed bug which caused SIGSEGV during batch mode operation. This was due 4 to a source code mix up... sorry everyone. I guess I should be using RCS. 5 6[Sat Jun 12 13:27:06 EDT 1999] 7Version 1.02 -- 8 Due to a heads-up from Terry Mackintosh: 9 Added the compile-time -DOLD_SONY_DIGICAM option so that jpgtn can 10 recognize data produced by a Sony MVC-FD7 digital camera. I don't know if 11 other similar problems exist with other digicams. I do know that the 12 MVC-FD71 does produce JFIF images. If you have information on other 13 digicams which don't produce JFIF, please send me email with the make and 14 model of the camera, and, if possible, some pictures taken with it. My 15 email address is: jdmadea@cs.millersv.edu 16 17[Sun Jun 13 11:47:36 EDT 1999] 18Version 1.03 -- 19 Due to a suggestion by Terry Mackintosh: 20 Added -H and -W options to allow resizing on one dimension letting the 21 other one to float. Eg. Assuming foo.jpg is 480x640, the command: 22 23 bash$ jpgtn -H -s 48 foo.jpg 24 25 will produce a thumbnail that is 64x48, and the command: 26 27 bash$ jpgtn -W -s 48 foo.jpg 28 29 will produce a thumbnail that is 48x36. The default (no -H or -W option) 30 results in the original behavior, i.e. the image is resized to fit in 31 an NxN box where N is the argument to the -s switch. Basically, the default 32 just chooses -H if the height is the longer dimension and -W if the width 33 is. 34 35[Sun Jun 13 17:12:43 EDT 1999] 36Version 1.04 -- 37 Changed MINSIZE (in jpgtn.h) to be 24 instead of 50. I often need small 38 thumbnails for myself, and changed this long ago in my personal copy... 39 I just couldn't see any reason not to change it in the distribution. 40 41[Mon Jun 10 18:57:46 PDT 2002] 42 Wow. three years later and I finally get around to doing some much needed 43 maintenance. Talk about slacking. :-) Cleaned a lot up. Fixed the issue 44 with not being able to recognize some jpeg formats (hopefully for good) 45 by removing the whole imagetype.c source file. It was left over from 46 gtnpic which handled more than one image format. jpgtn just works with 47 jpegs so it wasn't at all helpful anyway; even worse, it was buggy. This 48 was the proper fix for that old problem with sony digicams. 49 50[Tue Jun 11 15:52:57 PDT 2002] 51 Fixed poor filename handling semantics. Now we ignore all path information 52 on input files when constructing output files. All output files either get 53 dumped into the current directory or the directory specified with the -d 54 switch. Previously, something like "jpgtn ./foo.jpg" would result in an 55 error because it tried to prepend the default prefix to the whole path as 56 supplied and "./tn_./foo.jpg" would fail in the absence of a directory name "tn_.". 57 58[Wed Jun 12 12:00:04 PDT 2002] 59Version 2.00 -- 60 Changed minimum size to 2 pixels. I don't know what the use of that 61 would be but I didn't see the point of an arbitrary minimum of 24 pixels. 62 I would have changed it to 1 pixel but doing so results in an error. I'll 63 look into that later. Changed maximum size to 2048 pixels. Such an image 64 size could hardly be called a thumbnail but, again, I didn't see the point 65 of an arbitrary maximum of 256 pixels. Now I can use jpgtn to convert all 66 of my 2048x1536 images to 640x480. 67 68[Thu Jun 13 19:39:32 PDT 2002] 69 Added -f flag which is now required in order to overwrite existing files. 70 Changed the version flag to be -V instead of -v which is now used for... 71 Added -v flag which may be used more than once for increasing levels of 72 verbosity. Removed warning that used to be written when no prefix or 73 directory was supplied. Removed the prepending of "./" onto files when no 74 directory was supplied. Kludged around rare 0 value for width or height. 75 76[Fri Jun 14 17:01:58 PDT 2002] 77 Renamed usage() and version() to print_usage() and print_version() 78 respectively. Cleaned up several non-source files including the man 79 page. Released to sunsite.unc.edu. 80 81 82[Sun Jun 23 12:25:01 PDT 2002] 83 Fixed a bug whereby I was neglecting to initialize the variable holding 84 the output filename. 85