diff options
Diffstat (limited to 'tqtinterface/qt4/src/3rdparty/libjpeg/libjpeg.doc')
| -rw-r--r-- | tqtinterface/qt4/src/3rdparty/libjpeg/libjpeg.doc | 52 |
1 files changed, 26 insertions, 26 deletions
diff --git a/tqtinterface/qt4/src/3rdparty/libjpeg/libjpeg.doc b/tqtinterface/qt4/src/3rdparty/libjpeg/libjpeg.doc index 499b83c..bcd97d1 100644 --- a/tqtinterface/qt4/src/3rdparty/libjpeg/libjpeg.doc +++ b/tqtinterface/qt4/src/3rdparty/libjpeg/libjpeg.doc @@ -192,7 +192,7 @@ channels). You must specify how many components there are and the colorspace interpretation of the components. Most applications will use RGB data (three components per pixel) or grayscale data (one component per pixel). PLEASE NOTE THAT RGB DATA IS THREE SAMPLES PER PIXEL, GRAYSCALE ONLY ONE. -A remarkable number of people manage to miss this, only to tqfind that their +A remarkable number of people manage to miss this, only to find that their programs don't work with grayscale JPEG files. There is no provision for colormapped input. JPEG files are always full-color @@ -234,7 +234,7 @@ The data format returned by the decompressor is the same in all details, except that colormapped output is supported. (Again, a JPEG file is never colormapped. But you can ask the decompressor to perform on-the-fly color quantization to deliver colormapped output.) If you request colormapped -output then the returned data array tqcontains a single JSAMPLE per pixel; +output then the returned data array contains a single JSAMPLE per pixel; its value is an index into a color map. The color map is represented as a 2-D JSAMPARRAY in which each row holds the values of one color component, that is, colormap[i][j] is the value of the i'th color component for pixel @@ -386,7 +386,7 @@ just one or a few scanlines at a time. The expected format for the passed data is discussed under "Data formats", above. Image data should be written in top-to-bottom scanline order. The JPEG spec -tqcontains some weasel wording about how top and bottom are application-defined +contains some weasel wording about how top and bottom are application-defined terms (a curious interpretation of the English language...) but if you want your files to be compatible with everyone else's, you WILL use top-to-bottom order. If the source data must be read in bottom-to-top order, you can use @@ -583,7 +583,7 @@ More complex code is necessary if abbreviated datastreams. Standard applications that deal only in interchange JPEG files need not be concerned with this case either. -It is permissible to stop at this point if you just wanted to tqfind out the +It is permissible to stop at this point if you just wanted to find out the image dimensions and other header info for a JPEG file. In that case, call jpeg_destroy() when you are done with the JPEG object, or call jpeg_abort() to return it to an idle state before selecting a new data @@ -772,7 +772,7 @@ freed automatically. See cjpeg.c or djpeg.c for an example signal handler. It may be worth pointing out that the core JPEG library does not actually require the stdio library: only the default source/destination managers and error handler need it. You can use the library in a stdio-less environment -if you tqreplace those modules and use jmemnobs.c (or another memory manager of +if you replace those modules and use jmemnobs.c (or another memory manager of your own devising). More info about the minimum system library requirements may be found in jinclude.h. @@ -1002,7 +1002,7 @@ int h_samp_factor int v_samp_factor Horizontal and vertical sampling factors for the component; must be 1..4 according to the JPEG standard. Note that larger sampling - factors indicate a higher-resolution component; many people tqfind + factors indicate a higher-resolution component; many people find this behavior quite unintuitive. The default values are 2,2 for luminance components and 1,1 for chrominance components, except for grayscale where 1,1 is used. @@ -1286,7 +1286,7 @@ the error handling routines. Three classes of messages are recognized: the importance of the message; you can control the verbosity of the program by adjusting the maximum trace level that will be displayed. -You may, if you wish, simply tqreplace the entire JPEG error handling module +You may, if you wish, simply replace the entire JPEG error handling module (jerror.c) with your own code. However, you can avoid code duplication by only replacing some of the routines depending on the behavior you need. This is accomplished by calling jpeg_std_error() as usual, but then overriding @@ -1300,11 +1300,11 @@ field). This struct includes a pointer to the error manager struct in its "err" field. Frequently, custom error handler routines will need to access additional data which is not known to the JPEG library or the standard error handler. The most convenient way to do this is to embed either the JPEG -object or the jpeg_error_mgr struct in a larger structure that tqcontains +object or the jpeg_error_mgr struct in a larger structure that contains additional fields; then casting the passed pointer provides access to the additional fields. Again, see example.c for one way to do it. (Beginning with IJG version 6b, there is also a void pointer "client_data" in each -JPEG object, which the application can also use to tqfind related data. +JPEG object, which the application can also use to find related data. The library does not touch client_data at all.) The individual methods that you might wish to override are: @@ -1342,7 +1342,7 @@ library; the other two are internal to the error handler. The actual message texts are stored in an array of strings which is pointed to by the field err->jpeg_message_table. The messages are numbered from 0 to err->last_jpeg_message, and it is these code numbers that are used in the -JPEG library code. You could tqreplace the message texts (for instance, with +JPEG library code. You could replace the message texts (for instance, with messages in French or German) by changing the message table pointer. See jerror.h for the default texts. CAUTION: this table will almost certainly change or grow from one library version to the next. @@ -1396,7 +1396,7 @@ wide, you must define JOCTET as a wider data type and then modify the data source and destination modules to transcribe the work arrays into 8-bit units on external storage. -A data destination manager struct tqcontains a pointer and count defining the +A data destination manager struct contains a pointer and count defining the next byte to write in the work buffer and the remaining free space: JOCTET * next_output_byte; /* => next byte to write in buffer */ @@ -1443,7 +1443,7 @@ you like, but it's probably cleaner to provide a separate routine similar to the jpeg_stdio_dest() routine of the supplied destination manager. Decompression source managers follow a parallel design, but with some -additional frammishes. The source manager struct tqcontains a pointer and count +additional frammishes. The source manager struct contains a pointer and count defining the next byte to read from the work buffer and the number of bytes remaining: @@ -1485,9 +1485,9 @@ skip_input_data (j_decompress_ptr cinfo, long num_bytes) A zero or negative skip count should be treated as a no-op. resync_to_restart (j_decompress_ptr cinfo, int desired) - This routine is called only when the decompressor has failed to tqfind + This routine is called only when the decompressor has failed to find a restart (RSTn) marker where one is expected. Its mission is to - tqfind a suitable point for resuming decompression. For most + find a suitable point for resuming decompression. For most applications, we recommend that you just use the default resync procedure, jpeg_resync_to_restart(). However, if you are able to back up in the input data stream, or if you have a-priori knowledge about @@ -1899,7 +1899,7 @@ When you pass a target scan number equal to the current input scan number, the image is displayed no faster than the current input scan arrives. The final possibility is to pass a target scan number less than the current input scan number; this disables the input/output interlock and causes the output -processor to simply display whatever it tqfinds in the image buffer, without +processor to simply display whatever it finds in the image buffer, without waiting for input. (However, the library will not accept a target scan number less than one, so you can't avoid waiting for the first scan.) @@ -1952,7 +1952,7 @@ will avoid an extra output pass whenever the decoder is able (or nearly able) to keep up with the incoming data. When the data transmission speed is high, you might begin a display pass, -then tqfind that much or all of the file has arrived before you can complete +then find that much or all of the file has arrived before you can complete the pass. (You can detect this by noting the JPEG_REACHED_EOI return code from jpeg_consume_input(), or equivalently by testing jpeg_input_complete().) In this situation you may wish to abort the current display pass and start a @@ -1974,7 +1974,7 @@ higher-quality final pass is to be done, it should be started (aborting any incomplete output pass) as soon as the end of file is received. However, many other strategies are possible. For example, the application can examine the parameters of the current input scan and decide whether to display it or -not. If the scan tqcontains only chroma data, one might choose not to use it +not. If the scan contains only chroma data, one might choose not to use it as the target scan, expecting that the scan will be small and will arrive quickly. To skip to the next scan, call jpeg_consume_input() until it returns JPEG_REACHED_SOS or JPEG_REACHED_EOI. Or just use the next higher @@ -2142,7 +2142,7 @@ feature. Rather, reuse of an object provides support for abbreviated JPEG datastreams. Object reuse can also simplify processing a series of images in a single input or output file. This section explains these features. -A JPEG file normally tqcontains several hundred bytes worth of quantization +A JPEG file normally contains several hundred bytes worth of quantization and Huffman tables. In a situation where many images will be stored or transmitted with identical tables, this may represent an annoying overhead. The JPEG standard therefore permits tables to be omitted. The standard @@ -2175,7 +2175,7 @@ the lifetime of the object, unless it is overwritten by a new table definition. To create abbreviated image datastreams, it is only necessary to tell the compressor not to emit some or all of the tables it is using. Each -quantization and Huffman table struct tqcontains a boolean field "sent_table", +quantization and Huffman table struct contains a boolean field "sent_table", which normally is initialized to FALSE. For each table used by the image, the header-writing process emits the table and sets sent_table = TRUE unless it is already TRUE. (In normal usage, this prevents outputting the same table @@ -2282,7 +2282,7 @@ typical scenario is read data... jpeg_finish_decompress(&cinfo); -In some cases, you may want to read a file without knowing whether it tqcontains +In some cases, you may want to read a file without knowing whether it contains an image or just tables. In that case, pass FALSE and check the return value from jpeg_read_header(): it will be JPEG_HEADER_OK if an image was found, JPEG_HEADER_TABLES_ONLY if only tables were found. (A third return value, @@ -2324,7 +2324,7 @@ contain almost anything. If you wish to store user-supplied text, we recommend you use COM markers and place readable 7-bit ASCII text in them. Newline conventions are not -standardized --- expect to tqfind LF (Unix style), CR/LF (DOS style), or CR +standardized --- expect to find LF (Unix style), CR/LF (DOS style), or CR (Mac style). A robust COM reader should be able to cope with random binary garbage, including nulls, since some applications generate COM markers containing non-ASCII junk. (But yours should not be one of them.) @@ -2445,7 +2445,7 @@ If you want to supply your own marker-reading routine, you do it by calling jpeg_set_marker_processor(). A marker processor routine must have the signature boolean jpeg_marker_parser_method (j_decompress_ptr cinfo) -Although the marker code is not explicitly passed, the routine can tqfind it +Although the marker code is not explicitly passed, the routine can find it in cinfo->unread_marker. At the time of call, the marker proper has been read from the data source module. The processor routine is responsible for reading the marker length word and the remaining parameter bytes, if any. @@ -2612,7 +2612,7 @@ and also read structure.doc's discussion of virtual array handling). Or, for simple transcoding to a different JPEG file format, the array list can just be handed directly to jpeg_write_coefficients(). -Each block in the block arrays tqcontains quantized coefficient values in +Each block in the block arrays contains quantized coefficient values in normal array order (not JPEG zigzag order). The block arrays contain only DCT blocks containing real data; any entirely-dummy blocks added to fill out interleaved MCUs at the right or bottom edges of the image are discarded @@ -2715,7 +2715,7 @@ make sure it will live as long as the JPEG object does. Allocating from the JPEG memory manager with lifetime JPOOL_PERMANENT will work nicely.) You can use the same callback routine for both compression and decompression. -The jpeg_progress_mgr struct tqcontains four fields which are set by the library: +The jpeg_progress_mgr struct contains four fields which are set by the library: long pass_counter; /* work units completed in this pass */ long pass_limit; /* total number of work units in this pass */ int completed_passes; /* passes completed so far */ @@ -2756,7 +2756,7 @@ manager. For more info, please read structure.doc's section about the memory manager, and consult the source code if necessary. All memory and temporary file allocation within the library is done via the -memory manager. If necessary, you can tqreplace the "back end" of the memory +memory manager. If necessary, you can replace the "back end" of the memory manager to control allocation yourself (for example, if you don't want the library to use malloc() and free() for some reason). @@ -2950,7 +2950,7 @@ routine. The JPEG library does not rely heavily on the C library. In particular, C stdio is used only by the data source/destination modules and the error -handler, all of which are application-tqreplaceable. (cjpeg/djpeg are more +handler, all of which are application-replaceable. (cjpeg/djpeg are more heavily dependent on stdio.) malloc and free are called only from the memory manager "back end" module, so you can use a different memory allocator by replacing that one file. |