kc3-lang/libjpeg-turbo/java/doc/index-all.html
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
64567381 | 2024-08-31 17:31:02 | Merge branch 'main' into dev | |
|
8d76e4e5 | 2024-08-31 15:33:55 | Doc: "EXIF" = "Exif" | |
|
8456d2b9 | 2024-08-30 10:50:13 | Doc: "MCU block" = "iMCU" or "MCU" The JPEG-1 spec never uses the term "MCU block". That term is rarely used in other literature to describe the equivalent of an MCU in an interleaved JPEG image, but the libjpeg documentation uses "iMCU" to describe the same thing. "iMCU" is a better term, since the equivalent of an interleaved MCU can contain multiple DCT blocks (or samples in lossless mode) that are only grouped together if the image is interleaved. In the case of restart markers, "MCU block" was used in the libjpeg documentation instead of "MCU", but "MCU" is more accurate and less confusing. (The restart interval is literally in MCUs, where one MCU is one data unit in a non-interleaved JPEG image and multiple data units in a multi-component interleaved JPEG image.) In the case of 9b704f96b2dccc54363ad7a2fe8e378fc1a2893b, the issue was actually with progressive JPEG images exactly two DCT blocks wide, not two MCU blocks wide. This commit also defines "MCU" and "MCU row" in the description of the various restart marker options/parameters. Although an MCU row is technically always a row of samples in lossless mode, "sample row" was confusing, since it is used in other places to describe a row of samples for a single component (whereas an MCU row in a typical lossless JPEG image consists of a row of interleaved samples for all components.) | |
|
fd9b21b6 | 2024-08-28 18:58:21 | Merge branch 'main' into dev | |
|
5cf79606 | 2024-08-28 18:36:37 | Undocument TJ*PARAM_RESTARTBLOCKS for lossless TJ*PARAM_RESTARTBLOCKS technically works with lossless compression, but it is not useful, since the value must be equal to the number of samples in a row. (In other words, it is no different than TJ*PARAM_RESTARTINROWS, except that it requires the user to do more math.) | |
|
79b8d65f | 2024-08-22 13:50:32 | Java: Add official packed-pixel image I/O methods | |
|
07378442 | 2024-08-19 14:13:03 | Java: Remove deprecated constants and methods | |
|
26d978b6 | 2024-08-16 11:58:02 | Merge branch 'main' into dev | |
|
0c23b0ad | 2024-08-14 09:21:54 | Various doc tweaks - "Optimized baseline entropy coding" = "Huffman table optimization" "Optimized baseline entropy coding" was meant to emphasize that the feature is only useful when generating baseline (single-scan lossy 8-bit-per-sample Huffman-coded) JPEG images, because it is automatically enabled when generating Huffman-coded progressive (multi-scan), 12-bit-per-sample, and lossless JPEG images. However, Huffman table optimization isn't actually an integral part of those non-baseline modes. You can forego Huffman table optimization with 12-bit data precision if you supply your own Huffman tables. The spec doesn't require it with progressive or lossless mode, either, although our implementation does. Furthermore, "baseline" describes more than just the type of entropy coding used. It was incorrect to say that optimized "baseline" entropy coding is automatically enabled for Huffman-coded progressive, 12-bit-per-sample, and lossless JPEG images, since those are clearly not baseline images. - "Progressive entropy coding" = "Progressive JPEG" "Progressive" describes more than just the type of entropy coding used. (In fact, both Huffman-coded and arithmetic-coded images can be progressive.) - Mention that TJPARAM_OPTIMIZE/TJ.PARAM_OPTIMIZE can be used with lossless transformation as well. - General wordsmithing - Formatting tweaks | |
|
6ec8e41f | 2024-06-13 11:52:13 | Handle lossless JPEG images w/2-15 bits per sample Closes #768 Closes #769 |