@DATABASE akJFIF_Documentation @WIDTH 80 ## ## For reading this file you may use : ## ## Program-Name available at ## ## - AmigaGuide (various Packages) ## - MultiView (Workbench) ## - PowerGuide (Aminet CDs) ## @NODE MAIN "akJFIF : Documentation" akJFIF.datatype V45.5 - FREEWARE - © 2002 by Dipl.-Ing. Andreas Kleinert. All rights reserved. A PerSuaSiVe SoftWorX PRODUCT. Needs Kickstart V3.x Release Date : 25.10.2002 @{i}Please consider registration - usually less than 1% of the users of a program do register. That's not much.@{ui} @{i}@{ui} @{"BTW: What is SViewIV ?" LINK Commercial_1/Main 0 } @{i}@{ui} @{"Copyright" LINK Copyright} @{"Disclaimer" LINK Disclaimer} @{"Distribution" LINK Distribution} @{"Usage and Notes" LINK Usage} @{"Datatype FAQ" LINK Probs} @{"Prefs" LINK Prefs} @{"Correspondence" LINK Correspondence} @{"Version-History" LINK History} @{fg highlight} _ // Only \\X/ Amiga makes it possible! @{fg text} Please visit: WWW Support Site @{"http://www.ar-kleinert.de" SYSTEM "AWeb-II:AWeb-II URL http://www.ar-kleinert.de"} (AWeb-II) The CHAOS theory: @{i}"Like finding that bloody butterfly whose flapping wings cause all these storms we've been having lately and getting it to stop."@{ui} (see "Witches Abroad" by Terry Pratchett) Ahm...well: @{i}...and thanks for all the fish.@{ui} @ENDNODE @NODE "Copyright" The akJFIF.datatype in this version and its documentation files are (C)opyright 1996-2002 by Andreas R. Kleinert. All rights reserved. This software is based in part on the work of the Independent JPEG Group. akDT_Installer by Robert C. Reiswig ©1996-2001. If you wish to use any part of this installer you must ask. May not be integrated/placed into any other package! Changes, suggestions or problems: akDatatype@vgr.com Prefs GUI design improved by Georg Rottlaender under use of a 'NewIcon' graphics by Philip Vedovatti - included with kind permission by the 'Team NewIcons' The patch files were created using the scompare SAS Binary File Compare Program V6.50 which is copyright © 1992-1993 SAS Institute, Inc. The spatch SAS Binary File Patcher V6.50 is copyright © 1992 SAS Institute, Inc. Some of the mentioned names or products within this or other documents may be copyrighted by companies or trademarks of companies or persons. Should any of the listed terms and clauses within this document not be valid in conjunction with the law of certain countries this does not affect the validity of the other clauses. @ENDNODE @NODE "Disclaimer" The author takes no responsibility for any results of the use of this program. This software is provided "AS IS" and there is no warranty of any kind, so that you use this software at your own risk. The author reserves the right to discontinue development of the program. @ENDNODE @NODE "Distribution" The akJFIF.datatype in this version is freely distributable (FREEWARE). You may copy it, if the copyright notice is left intact and all of its parts are included in the distribution. This program may only be included in commercial packages or commercial program collections with my written permission - ask for it. This program may be put on public domain disks or included in public domain disk libraries - when being distributed that way, it is allowed to take a nominal fee including the costs for copying, without considering that as "commercial" in the above mentioned sense. This program may also be distributed via electronic mail and may be put into mailboxes as long as the redistribution conditions are respected in all points. By using or distributing this program you automatically agree to all of the above conditions and terms. @ENDNODE @NODE Usage "Usage and so on" Installation and Usage ---------------------- Just install the datatype files to their appropriate directories, and copy the akJFIFPrefs command to SYS:Prefs/Datatypes (optionally). Please make sure, that there is a directory available, where temporary data can be stored. There must be an assignment called "VMEM:" to this directory (just like with SuperViewLibrary and akPNG-dt). The assignment originally would have been "JPEGTMP:" for the JFIF sources, but the memory manager has been strongly modified and enhanced - on a system with many RAM available you will perhaps never actually encounter usage of that directory. Do not assign it to "T:" if it is somewhere on a Ram-Disk (that's why T: is not used by default) - just create a safe place for it. Program information ------------------- akJFIF.datatype is a JPEG datatype, which is based on the latest IJG JFIF sources V6b. So it does support progressive JPEG and all the other things introduced with V6a (note: it reads progressive JPEG, but DataTypes cannot display images progressively - instead only as a single chunk). With V39-V42 picture.datatype it produces 256 color palette-based (with either none, floyd-steinberg or ordered dithering) or HAM6/8 output, with picture.datatype V43-45 well 24 Bit may be exported unmodified. akJFIF makes use of memory pools where applicable and also automatically utilizes asyncio.library (V39+) when available. You must use the included preferences program for best configuration - of course you can also use one of the alternative prefs programs from Aminet, which should deliver the same functionality (but please remember not to send any corresponding bug reports to my address). akJFIF.datatype is @{"FREEWARE" LINK "Copyright"}. @ENDNODE @NODE Probs "Datatype FAQ" OS 3.5/3.9 problems ------------------- Programs, that let picture.datatype V44 do on-screen dithering, will face the "problem", that 24 bit images even will be dithered when being displayed on 15/16 bit screens. According to the OS 3.5 developer team, this should result in "better image quality". However, when analyzing this statement, one will discover, that most graphic cards based on PC-chips only allow for 6 bit color lookup tables (LUTs) (that is, 6 bit for each out of red, green and blue - thus only a range of 0..63 instead of 0..255) which in fact isn't much better than the 5:5:5 or 5:6:5 ratio of 15/16 bit high color modes. However, 16 bit high color allows for 65536 distinct colors on screen, while a 6 bit LUT only will allow for 256 out of 262144 colors. However, these new V44 dithering options can be changed via the datatypes preferences - global default settings then locally will be overridden. What's the relationship between JFIF and LJPG ? ----------------------------------------------- The answer is simple: on file format level, there actually is none (*), thus neither one of the two datatypes does replace the other one and you would need to install both to get the functionality of both - but akJFIF perhaps is the more important one. (*) well, there *is* a relationship, but it only does concern the file format construction and does not actually build a base for real upward/sideward compatibility No write support ? ------------------ Sorry, there won't be write support (DTM_WRITE method), since I think, that datatypes are mainly a system for data exchange and not to do the job of existing conversion utilities. To explain it even further: The datatype mechanism certainly is a system to HIDE implementation and data format details. If one does offer too much choices for destination file formats, this would - in my opinion - completely be against this concept. The ideal way of keeping the datatypes' concept cleanly OOP would be to internally handle everything in an amiga-unique IFF format - which BTW is quite essential for clipboard data exchange as well. Unfortunately IFF-ILBM isn't very suitable for color depths greater than 8 bit. Maybe IFF-RGFX could be a good choice, here. Why are "progressive" image files not displayed progressively ? -------------------------------------------------------------- Because picture.datatype's API (upto V45) relies on complete bitmaps to be returned by a datatype of subclass "picture". Unfortunately the datatype cannot: - supply many small bitmaps, one for each line - give control back to picture.datatype during reading a file - write into an existing, given bitmap (to just supply some possible considerations how to solve this problem), so there currently is no way of displaying images progressively. Nevertheless the support of "progressive JPEG" is a noticeable feature, since (speaking of the JFIF file format) it is not backward-compatible with common JPEG and readers need to take special care for these files (JFIF V6a extensions). Ramlib Crashes -------------- If you get "ramlib" gurus with this or any other program, then try installing Aminet:util/sys/StackAid.lha Unknown datatypes (V43-45) -------------------------- If your datatypes stop working (unknown file format), please don't blame me, but at first check, whether you've still installed an already expired beta version of picture.datatype V43... An other reason may be, that you did not delete all of the old (obsolete) "competing" JFIF descriptors from DEVS:Datatypes - in general, there should only remain JPEG/JFIF descriptor files that are shipped with the CURRENT release of this datatype. And make sure, that you don't use picdtpatch (v39.2) from the Hypertext.datatype archive by Stefan Ruppert. Then, there are people who save images fromout a popular tool called Ph*t*sh*p (V4/5) as TIFF, give these the extension .jpg and wonder why these are not recognized as JPEG (whether these can or cannot be loaded by akTIFF, is a different story ;) @ENDNODE @NODE "Correspondence" ** General PerSuaSiVe SoftWorX WWW Support Site is http://www.ar-kleinert.de ** _________________________________________________________ | You may reach me the following way. | | Send bug-reports, money or whatever to: | |---------------------------------------------------------| | * SuperView Development & Registration * | | * DRAFU Development & Registration * | | * Image Engineer Registration Site Europe * | | | | | | PerSuaSiVe SoftWorX | | | | Andreas R. Kleinert | | Montanusstr. 5 | | D-51065 Köln | | Germany, Europe | | | | +49-221-2973442 | | (also FAX + AM) | | | | Weekdays after 18.00h. | | | | When calling via phone you may leave a message, | | if I'm not available - but don't expect me | | calling back to USA, Australia, ... since | | german phone rates are HIGHLY expensive. | |_________________________________________________________| EMail: Please ask before sending binaries! And please think twice before asking - my postbox is not unlimited in size. - Usenet >>> info@ar-kleinert.de Andreas_Kleinert@gmx.de Andreas_Kleinert@t-online.de @ENDNODE @NODE "Prefs" akJFIFPrefs ----------- akJFIFPrefs is the Preferences Program for akJFIF.datatype. GUI has been designed with StormWizard 2.0, so this program needs "wizard.library" V37+ (you can find a copy on Aminet under "biz/haage/WizardLibrary.lha" or even never versions under ftp.haage-partner.com). Icon by Bert Bosma (based on NewIcons). An alternative MUI prefs program replacement by Alvaro Thompson (originally) and Achim Stegemann (later) is now available as util/dtype/akMUIPrefs.lha - there also are various other replacements. Task (process) specific settings also can be done - either using the preferences program (which allows to select the corresponding process from a list as long as it actually is running at the same time) or by hand, following the scheme below: OPTIONAL ---------------- task specific settings files ----------------------- Settings specific to different caller programs may be created by copying the global settings from "Datatypes/akJFIF.prefs" to an optional task-related prefs file called "Datatypes/akJFIF.prefs_Tasks/TaSkNaMe" where "TaSkNaMe" means the name of the program as e.g. shown by a system monitor (for obvious reasons, this does work best with workbench programs, which don't require name patterns as some CLI programs might do, like for example "CLI(3):Work:Browsers/XWebber"). So, with AWeb for example, you would just edit your global settings file and then do the following: MakeDir ENV:Datatypes/akJFIF.prefs_Tasks Copy ENV:Datatypes/akJFIF.prefs ENV:Datatypes/akJFIF.prefs_Tasks/AWebIP" [... and the same for ENVARC: ...] After that, AWeb will ignore the global settings and fetch its own from the given file. --------------------------------------------------------------------- You can do the following settings: DECODE_METHOD=(FAST_INTEGER|SLOW_INTEGER|FLOATING_POINT) DITHERMODE=(NO_DITHERING|DITHER_FLOYD-STEINBERG|DITHER_ORDERED| HAM_OUTPUT) V44_DITHER=(0..2) V43MODE=(256|24BIT) V40_DEPTH=(3..8) V40_COLORSPACE=(COLOR|GRAY) HAM_MODE=(HAM6|HAM8) COLOR_QUANTIZING=(SLOW|FAST) UPSAMPLING=(ON|OFF) SCALE_DENOM=(0..3) INTERLEAVED_BM8=(ON|OFF) DISPLAYABLE_BM8=(ON|OFF) CUSTOM_MODES NOASPECT DEBUG That's mostly self-explaining, but as an example, here are the default settings and a short explanation: V44_DITHER=1 DECODE_METHOD=FAST_INTEGER DITHERMODE=DITHER_ORDERED V43_MODE=24BIT V40_DEPTH=8 V40_COLORSPACE=COLOR HAM_MODE=HAM6 COLOR_QUANTIZING=FAST UPSAMPLING=OFF SCALE_DENOM=0 INTERLEAVED_BM8=ON DISPLAYABLE_BM8=OFF General Explanation of Options ============================== DECODE_METHOD ------------- SLOW_INTEGER: slow, but accurate integer algorithm FAST_INTEGER: faster, but less accurate integer algorithm FLOATING_POINT: floating point algorithm DITHERMODE ------------- NO_DITHERING: no dithering, best pen selection DITHER_FLOYD-STEINBERG: slow, high quality, floyd-steinberg dithering DITHER_ORDERED: ordered dithering to fixed palette HAM_OUTPUT: generate HAM output from 24 Bit data The datatype will only output 24 Bit data, when DITHERMODE=NO_DITHERING _and_ V43_MODE=24BIT are set. Otherwise even with V43 picture.datatype the data will be dithered, HAM-converted or best-pen colormapped. Thus DITHERMODE=NO_DITHERING activates the V43_MODE switch for picture.datatype V43+ V43_MODE (only with "NO_DITHERING" and picture.datatype V43+) -------- 256: disable 24 Bit output even for V43 picture.datatype 24BIT: do raw 24 Bit output with V43 picture.datatype The datatype will only output 24 Bit data, when DITHERMODE=NO_DITHERING _and_ V43_MODE=24BIT are set. Otherwise even with V43 picture.datatype the data will be dithered, HAM-converted or best-pen colormapped. Thus V43_MODE will only act as a switch, when DITHERMODE=NO_DITHERING has been set and picture.datatype V43 is running. V40_DEPTH --------- When dithering to a palette (so: when in V40 mode) the number of palette colors, which is 256 by default, may be reduced here (e.g. on ECS systems). Valid depth values are 3..8 (which results in 16..256 colors, easily calculated by 2^depth). V40_COLORSPACE -------------- Whether you want to get 16..256 colors or 16..256 grayscales when requesting V40_DEPTH. HAM_MODE (only with "HAM_OUTPUT") -------- HAM6: generate HAM6 output (max. 4096 different colors on screen) HAM8: generate HAM8 output (262144+ different colors on screen) When in HAM8 mode, gray images will be exported as 256 color gray images nevertheless (they do look ugly in HAM8 and AGA machines CAN handle 256 colors). Note, that HAM8 is native to AGA machines and thus may cause difficulties with graphic boards and won't work with OCS/ECS Amigas. With HAM6 and graphic boards also problems may occur. COLOR_QUANTIZING (with "DITHER_FLOYD-STEINBERG" only) ---------------- FAST: high speed color quantization SLOW: high quality color quantization UPSAMPLING ---------- ON: do careful upsampling of chroma components OFF: do faster, but sloppier upsampling of chroma components (often very small visual impact) SCALE_DENOM ----------- 0..3: use a scale factor of either 1/1 (none), 1/2, 1/4 or 1/8 for graphics reading. For reasons of better failure safety checks, this is specified as an exponent value between 0 and 3 (2^0=1, 2^1=2, 2^2=4, 2^3=8). INTERLEAVED_BM8 --------------- ON: will output interleaved bitmaps upto 256 colors OFF: will output normal bitmaps (BMF_CLEAR and maybe BMF_DISPLAYABLE only) - you may switch interleaved mode off for specific programs, which cannot handle it, or when AllocBitmap() has been patched for chunky modes by a graphics card software or e.g. EGSPlus DISPLAYABLE_BM8 --------------- ON: will output displayable bitmaps upto 256 colors OFF: will output normal bitmaps (BMF_CLEAR and maybe BMF_INTERLEAVED) - you may turn displayable mode on for specific programs, which want to use datatype generated bitmaps directly as screen bitmap. If they are enabled to do this, this may save some memory (for another bitmap). This is recommended for systems without graphics card and only few chip memory. CUSTOM_MODES (hidden option) ------------------------------ When the keyword CUSTOM_MODES is set, only viewmodes out of the standard set will be generated: - LowRes ( 320x200/256) - HighRes ( 640x200/256) - SuperHighRes (1280x200/256) - LowRes Lace ( 320x400/512) - HighRes Lace ( 640x400/512) - SuperHighRes Lace (1280x400/512) When CUSTOM_MODES=0x######## (e.g. CUSTOM_MODES=0x00000000) is set, the specified hexadecimal viewmode ID will be used always - alternatively, you can specify the viewmode name as plain text, for example "CUSTOM_MODES=PAL:HighRes". Note, that spelling is very critical here. For HAM output, this is only true, if the mode ID actually is capable of HAM (this usually is indicated by OR'ing it with HAM_KEY), otherwise a different ID will be computed. NOASPECT (hidden option) ------------------------------ If x/y aspect generation produces buggy results, e.g. with PictIcon, this option may be used to always force 1:1 to be returned. DEBUG (hidden option) ------------------------------ Not implemented yet. Will enable debugging output, i.e. info requesters. Explanation of settings ======================= Please note, that it does not suffice to simply specify the prefered options. Some also do react as switches. Here are some examples how to manage specific configurations: HAM Output (V40/V43): DECODE_METHOD=FAST_INTEGER *1 DITHERMODE=HAM_OUTPUT V43_MODE=256 x1 HAM_MODE=HAM8 *1 UPSAMPLING=OFF *1 Dithered Output (V40/V43): DECODE_METHOD=FAST_INTEGER *1 DITHERMODE=DITHER_ORDERED *2 V43_MODE=256 x1 COLOR_QUANTIZING=FAST *1 UPSAMPLING=OFF *1 256 Colors (V40/V43): DECODE_METHOD=FAST_INTEGER *1 (Best Pen selection) DITHERMODE=NO_DITHERING V43_MODE=256 x2 COLOR_QUANTIZING=FAST *1 UPSAMPLING=OFF *1 24 Bit (V43): DECODE_METHOD=FAST_INTEGER *1 DITHERMODE=NO_DITHERING V43_MODE=24BIT x2 UPSAMPLING=OFF *1 x1 here: always ignored (because DECODE_METHOD not equal NO_DITHERING) x2 here: acts as a switch between V40 and V43 mode, when running picture.datatype V43 (because DECODE_METHOD=NO_DITHERING) *1 may be changed as prefered *2 may be changed to: DITHER_FLOYD-STEINBERG (side-effects described by "x1" and "x2") @ENDNODE @NODE "History" Known Bugs: - some people reported problems with the installation scripts in the past. If you encounter any problems or bugs, please report these directly to the script author Robert C. Reiswig - please use at least V41.101 of wizard.library. You should find a copy coming with demo versions of various programs under ftp.haage-partner.com - viewmode selection may not always be 'perfect' History ======= V45.5 (25.10.2002): - increased memory consumption for better speed, fallback to slower code when memory is low (V43, 24 bit only) V45.1 (29.6.2002): - added further 68k and Amithlon/UAE optimizations V44.140 (28.6.2002): - removed PPC support; added Amithlon/UAE optimizations V44.131 (15.12.2001):- Prefs program and docs updated V44.122 (21.8.2001): - speedup (changed behaviour on unreg. version) V44.121 (21.8.2001): - speedup V44.120 (21.8.2001): - history cleaned up @ENDNODE