[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6648":3},{"id":4,"name":5,"fullName":6,"owner":5,"repo":5,"description":7,"homepage":8,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":15,"starSnapshotCount":15,"syncStatus":28,"lastSyncTime":29,"discoverSource":30},6648,"libjpeg-turbo","libjpeg-turbo\u002Flibjpeg-turbo","Main libjpeg-turbo repository","https:\u002F\u002Flibjpeg-turbo.org",null,"C",4330,1157,128,14,0,3,5,27,11,31.19,"Other",false,"main",[],"2026-06-12 02:01:27","Background\n==========\n\nlibjpeg-turbo is a JPEG image codec that uses SIMD instructions to accelerate\nbaseline and progressive JPEG compression and decompression on systems with\ncommon CPU architectures.  On such systems, libjpeg-turbo is generally 2-6x as\nfast as libjpeg, all else being equal.  On other types of systems,\nlibjpeg-turbo can still outperform libjpeg by a significant amount, by virtue\nof its highly-optimized Huffman coding routines.  In many cases, the\nperformance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.\n\nlibjpeg-turbo implements both the traditional libjpeg API as well as the less\npowerful but more straightforward TurboJPEG API.  libjpeg-turbo also features\ncolorspace extensions that allow it to compress from\u002Fdecompress to 32-bit and\nbig-endian pixel buffers (RGBX, XBGR, etc.)\n\nlibjpeg-turbo was originally based on libjpeg\u002FSIMD, an MMX-accelerated\nderivative of libjpeg v6b developed by Miyasaka Masaru.  The TigerVNC and\nVirtualGL projects made numerous enhancements to the codec in 2009, and in\nearly 2010, libjpeg-turbo spun off into an independent project, with the goal\nof making high-speed JPEG compression\u002Fdecompression technology available to a\nbroader range of users and developers.  libjpeg-turbo is an ISO\u002FIEC and ITU-T\nreference implementation of the JPEG standard.\n\nMore information about libjpeg-turbo can be found at\n\u003Chttps:\u002F\u002Flibjpeg-turbo.org>.\n\n\nFunding\n=======\n\nlibjpeg-turbo is an independent open source project, but we rely on patronage\nand funded development in order to maintain that independence.  The easiest way\nto ensure that libjpeg-turbo remains community-focused and free of any one\norganization's agenda is to\n[sponsor our project through GitHub](https:\u002F\u002Fgithub.com\u002Fsponsors\u002Flibjpeg-turbo).\nAll sponsorship money goes directly toward funding the labor necessary to\nmaintain libjpeg-turbo, support the user community, and implement bug fixes and\nstrategically important features.\n\n[![Sponsor libjpeg-turbo](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fsponsors\u002Flibjpeg-turbo?label=Sponsor&logo=GitHub)](https:\u002F\u002Fgithub.com\u002Fsponsors\u002Flibjpeg-turbo)\n\n\nLicense\n=======\n\nlibjpeg-turbo is covered by three compatible BSD-style open source licenses.\nRefer to [LICENSE.md](LICENSE.md) for a roll-up of license terms.\n\n\nBuilding libjpeg-turbo\n======================\n\nRefer to [BUILDING.md](BUILDING.md) for complete instructions.\n\n\nUsing libjpeg-turbo\n===================\n\nlibjpeg-turbo includes two APIs that can be used to compress and decompress\nJPEG images:\n\n- **TurboJPEG API**\u003Cbr>\n  This API provides an easy-to-use interface for compressing and decompressing\n  JPEG images in memory.  It also provides some functionality that would not be\n  straightforward to achieve using the underlying libjpeg API, such as\n  generating planar YUV images and performing multiple simultaneous lossless\n  transforms on an image.  The TurboJPEG API is recommended for first-time\n  users of libjpeg-turbo.  Refer to [tjcomp.c](src\u002Ftjcomp.c),\n  [tjdecomp.c](src\u002Ftjdecomp.c), [tjtran.c](src\u002Ftjtran.c),\n  [TJComp.java](jna\u002FTJComp.java), [TJDecomp.java](jna\u002FTJDecomp.java), and\n  [TJTran.java](jna\u002FTJTran.java) for examples of its usage and to\n  \u003Chttps:\u002F\u002Flibjpeg-turbo.org\u002FDocumentation\u002FDocumentation> for API\n  documentation.\n\n- **libjpeg API**\u003Cbr>\n  This is the de facto industry-standard API for compressing and decompressing\n  JPEG images.  It is more difficult to use than the TurboJPEG API but also\n  more powerful.  The libjpeg API implementation in libjpeg-turbo is both\n  API\u002FABI-compatible and mathematically compatible with libjpeg v6b.  It can\n  also optionally be configured to be API\u002FABI-compatible with libjpeg v7 and v8\n  (see below.)  Refer to [cjpeg.c](src\u002Fcjpeg.c) and [djpeg.c](src\u002Fdjpeg.c) for\n  examples of its usage and to [libjpeg.txt](doc\u002Flibjpeg.txt) for API\n  documentation.\n\nThere is no significant performance advantage to either API when both are used\nto perform similar operations.\n\nColorspace Extensions\n---------------------\n\nlibjpeg-turbo includes extensions that allow JPEG images to be compressed\ndirectly from (and decompressed directly to) buffers that use BGR, BGRX,\nRGBX, XBGR, and XRGB pixel ordering.  This is implemented with ten new\ncolorspace constants:\n\n    JCS_EXT_RGB   \u002F* red\u002Fgreen\u002Fblue *\u002F\n    JCS_EXT_RGBX  \u002F* red\u002Fgreen\u002Fblue\u002Fx *\u002F\n    JCS_EXT_BGR   \u002F* blue\u002Fgreen\u002Fred *\u002F\n    JCS_EXT_BGRX  \u002F* blue\u002Fgreen\u002Fred\u002Fx *\u002F\n    JCS_EXT_XBGR  \u002F* x\u002Fblue\u002Fgreen\u002Fred *\u002F\n    JCS_EXT_XRGB  \u002F* x\u002Fred\u002Fgreen\u002Fblue *\u002F\n    JCS_EXT_RGBA  \u002F* red\u002Fgreen\u002Fblue\u002Falpha *\u002F\n    JCS_EXT_BGRA  \u002F* blue\u002Fgreen\u002Fred\u002Falpha *\u002F\n    JCS_EXT_ABGR  \u002F* alpha\u002Fblue\u002Fgreen\u002Fred *\u002F\n    JCS_EXT_ARGB  \u002F* alpha\u002Fred\u002Fgreen\u002Fblue *\u002F\n\nSetting `cinfo.in_color_space` (compression) or `cinfo.out_color_space`\n(decompression) to one of these values will cause libjpeg-turbo to read the\nred, green, and blue values from (or write them to) the appropriate position in\nthe pixel when compressing from\u002Fdecompressing to an RGB buffer.\n\nYour application can check for the existence of these extensions at compile\ntime with:\n\n    #ifdef JCS_EXTENSIONS\n\nAt run time, attempting to use these extensions with a libjpeg implementation\nthat does not support them will result in a \"Bogus input colorspace\" error.\nApplications can trap this error in order to test whether run-time support is\navailable for the colorspace extensions.\n\nWhen using the RGBX, BGRX, XBGR, and XRGB colorspaces during decompression, the\nX byte is undefined, and in order to ensure the best performance, libjpeg-turbo\ncan set that byte to whatever value it wishes.  If an application expects the X\nbyte to be used as an alpha channel, then it should specify `JCS_EXT_RGBA`,\n`JCS_EXT_BGRA`, `JCS_EXT_ABGR`, or `JCS_EXT_ARGB`.  When these colorspace\nconstants are used, the X byte is guaranteed to be 0xFF, which is interpreted\nas opaque.\n\nYour application can check for the existence of the alpha channel colorspace\nextensions at compile time with:\n\n    #ifdef JCS_ALPHA_EXTENSIONS\n\n[jcstest.c](src\u002Fjcstest.c), located in the libjpeg-turbo source tree,\ndemonstrates how to check for the existence of the colorspace extensions at\ncompile time and run time.\n\nlibjpeg v7 and v8 API\u002FABI Emulation\n-----------------------------------\n\nWith libjpeg v7 and v8, new features were added that necessitated extending the\ncompression and decompression structures.  Unfortunately, due to the exposed\nnature of those structures, extending them also necessitated breaking backward\nABI compatibility with previous libjpeg releases.  Thus, programs that were\nbuilt to use libjpeg v7 or v8 did not work with libjpeg-turbo, since it is\nbased on the libjpeg v6b code base.  Although libjpeg v7 and v8 are not\nas widely used as v6b, enough programs (including a few Linux distros) made\nthe switch that there was a demand to emulate the libjpeg v7 and v8 ABIs\nin libjpeg-turbo.  It should be noted, however, that this feature was added\nprimarily so that applications that had already been compiled to use libjpeg\nv7+ could take advantage of accelerated baseline JPEG encoding\u002Fdecoding\nwithout recompiling.  libjpeg-turbo does not claim to support all of the\nlibjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all\ncases (see below.)\n\nBy passing an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you\ncan build a version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so\nthat programs that are built against libjpeg v7 or v8 can be run with\nlibjpeg-turbo.  The following section describes which libjpeg v7+ features are\nsupported and which aren't.\n\n### Support for libjpeg v7 and v8 Features\n\n#### Fully supported\n\n- **libjpeg API: IDCT scaling extensions in decompressor**\u003Cbr>\n  libjpeg-turbo supports IDCT scaling with scaling factors of 1\u002F8, 1\u002F4, 3\u002F8,\n  1\u002F2, 5\u002F8, 3\u002F4, 7\u002F8, 9\u002F8, 5\u002F4, 11\u002F8, 3\u002F2, 13\u002F8, 7\u002F4, 15\u002F8, and 2\u002F1 (only 1\u002F4\n  and 1\u002F2 are SIMD-accelerated.)\n\n- **libjpeg API: Arithmetic coding**\n\n- **libjpeg API: In-memory source and destination managers**\u003Cbr>\n  See notes below.\n\n- **cjpeg: Separate quality settings for luminance and chrominance**\u003Cbr>\n  Note that the libpjeg v7+ API was extended to accommodate this feature only\n  for convenience purposes.  It has always been possible to implement this\n  feature with libjpeg v6b (see rdswitch.c for an example.)\n\n- **cjpeg: 32-bit BMP support**\n\n- **cjpeg: `-rgb` option**\n\n- **jpegtran: Lossless cropping**\n\n- **jpegtran: `-perfect` option**\n\n- **jpegtran: Forcing width\u002Fheight when performing lossless crop**\n\n- **rdjpgcom: `-raw` option**\n\n- **rdjpgcom: Locale awareness**\n\n\n#### Not supported\n\nNOTE:  As of this writing, extensive research has been conducted into the\nusefulness of DCT scaling as a means of data reduction and SmartScale as a\nmeans of quality improvement.  Readers are invited to peruse the research at\n\u003Chttps:\u002F\u002Flibjpeg-turbo.org\u002FAbout\u002FSmartScale> and draw their own conclusions,\nbut it is the general belief of our project that these features have not\ndemonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.\n\n- **libjpeg API: DCT scaling in compressor**\u003Cbr>\n  `cinfo.scale_num` and `cinfo.scale_denom` are silently ignored.\n  There is no technical reason why DCT scaling could not be supported when\n  emulating the libjpeg v7+ API\u002FABI, but without the SmartScale extension (see\n  below), only scaling factors of 1\u002F2, 8\u002F15, 4\u002F7, 8\u002F13, 2\u002F3, 8\u002F11, 4\u002F5, and\n  8\u002F9 would be available, which is of limited usefulness.\n\n- **libjpeg API: SmartScale**\u003Cbr>\n  `cinfo.block_size` is silently ignored.\n  SmartScale is an extension to the JPEG format that allows for DCT block\n  sizes other than 8x8.  Providing support for this new format would be\n  feasible (particularly without full acceleration.)  However, until\u002Funless\n  the format becomes either an official industry standard or, at minimum, an\n  accepted solution in the community, we are hesitant to implement it, as\n  there is no sense of whether or how it might change in the future.  It is\n  our belief that SmartScale has not demonstrated sufficient usefulness as a\n  lossless format nor as a means of quality enhancement, and thus our primary\n  interest in providing this feature would be as a means of supporting\n  additional DCT scaling factors.\n\n- **libjpeg API: Fancy downsampling in compressor**\u003Cbr>\n  `cinfo.do_fancy_downsampling` is silently ignored.\n  This requires the DCT scaling feature, which is not supported.\n\n- **jpegtran: Scaling**\u003Cbr>\n  This requires both the DCT scaling and SmartScale features, which are not\n  supported.\n\n- **Lossless RGB JPEG files**\u003Cbr>\n  This requires the SmartScale feature, which is not supported.\n\n### What About libjpeg v9?\n\nlibjpeg v9 introduced yet another field to the JPEG compression structure\n(`color_transform`), thus making the ABI backward incompatible with that of\nlibjpeg v8.  This new field was introduced solely for the purpose of supporting\nlossless SmartScale encoding.  Furthermore, there was actually no reason to\nextend the API in this manner, as the color transform could have just as easily\nbeen activated by way of a new JPEG colorspace constant, thus preserving\nbackward ABI compatibility.\n\nOur research (see link above) has shown that lossless SmartScale does not\ngenerally accomplish anything that can't already be accomplished better with\nexisting, standard lossless formats.  Therefore, at this time it is our belief\nthat there is not sufficient technical justification for software projects to\nupgrade from libjpeg v8 to libjpeg v9, and thus there is not sufficient\ntechnical justification for us to emulate the libjpeg v9 ABI.\n\nIn-Memory Source\u002FDestination Managers\n-------------------------------------\n\nBy default, libjpeg-turbo 1.3 and later includes the `jpeg_mem_src()` and\n`jpeg_mem_dest()` functions, even when not emulating the libjpeg v8 API\u002FABI.\nPreviously, it was necessary to build libjpeg-turbo from source with libjpeg v8\nAPI\u002FABI emulation in order to use the in-memory source\u002Fdestination managers,\nbut several projects requested that those functions be included when emulating\nthe libjpeg v6b API\u002FABI as well.  This allows the use of those functions by\nprograms that need them, without breaking ABI compatibility for programs that\ndon't, and it allows those functions to be provided in the \"official\"\nlibjpeg-turbo binaries.\n\nNote that, on most Un*x systems, the dynamic linker will not look for a\nfunction in a library until that function is actually used.  Thus, if a program\nis built against libjpeg-turbo 1.3+ and uses `jpeg_mem_src()` or\n`jpeg_mem_dest()`, that program will not fail if run against an older version\nof libjpeg-turbo or against libjpeg v7- until the program actually tries to\ncall `jpeg_mem_src()` or `jpeg_mem_dest()`.  Such is not the case on Windows.\nIf a program is built against the libjpeg-turbo 1.3+ DLL and uses\n`jpeg_mem_src()` or `jpeg_mem_dest()`, then it must use the libjpeg-turbo 1.3+\nDLL at run time.\n\nBoth cjpeg and djpeg have been extended to allow testing the in-memory\nsource\u002Fdestination manager functions.  See their respective man pages for more\ndetails.\n\n\nMathematical Compatibility\n==========================\n\nFor the most part, libjpeg-turbo should produce identical output to libjpeg\nv6b.  There are two exceptions:\n\n1. When decompressing a JPEG image that uses 4:4:0 chrominance subsampling, the\noutputs of libjpeg v6b and libjpeg-turbo can differ because libjpeg-turbo\nimplements a \"fancy\" (smooth) 4:4:0 upsampling algorithm and libjpeg did not.\n\n2. When using the floating point DCT\u002FIDCT, the outputs of libjpeg v6b and\nlibjpeg-turbo can differ for the following reasons:\n\n    - The SSE\u002FSSE2 floating point DCT implementation in libjpeg-turbo is ever\n      so slightly more accurate than the implementation in libjpeg v6b, but not\n      by any amount perceptible to human vision (generally in the range of 0.01\n      to 0.08 dB gain in PNSR.)\n\n    - When not using the SIMD extensions, libjpeg-turbo uses the more accurate\n      (and slightly faster) floating point IDCT algorithm introduced in libjpeg\n      v8a as opposed to the algorithm used in libjpeg v6b.  It should be noted,\n      however, that this algorithm basically brings the accuracy of the\n      floating point IDCT in line with the accuracy of the accurate integer\n      IDCT.  The floating point DCT\u002FIDCT algorithms are mainly a legacy\n      feature, and they do not produce significantly more accuracy than the\n      accurate integer algorithms.  (To put numbers on this, the typical\n      difference in PNSR between the two algorithms is less than 0.10 dB,\n      whereas changing the quality level by 1 in the upper range of the quality\n      scale is typically more like a 1.0 dB difference.)\n\n    - If the floating point algorithms in libjpeg-turbo are not implemented\n      using SIMD instructions on a particular platform, then the accuracy of\n      the floating point DCT\u002FIDCT can depend on the compiler settings.\n\nWhile libjpeg-turbo does emulate the libjpeg v8 API\u002FABI, under the hood it is\nstill using the same algorithms as libjpeg v6b, so there are several specific\ncases in which libjpeg-turbo cannot be expected to produce the same output as\nlibjpeg v8:\n\n- When decompressing using scaling factors of 1\u002F2 and 1\u002F4, because libjpeg v8\n  implements those scaling algorithms differently than libjpeg v6b does, and\n  libjpeg-turbo's SIMD extensions are based on the libjpeg v6b behavior.\n\n- When using chrominance subsampling, because libjpeg v8 implements this\n  with its DCT\u002FIDCT scaling algorithms rather than with a separate\n  downsampling\u002Fupsampling algorithm.  In our testing, the subsampled\u002Fupsampled\n  output of libjpeg v8 is less accurate than that of libjpeg v6b for this\n  reason.\n\n- When decompressing using a scaling factor > 1 and merged (AKA \"non-fancy\" or\n  \"non-smooth\") chrominance upsampling, because libjpeg v8 does not support\n  merged upsampling with scaling factors > 1.\n\n\nPerformance Pitfalls\n====================\n\nRestart Markers\n---------------\n\nThe optimized Huffman decoder in libjpeg-turbo does not handle restart markers\nin a way that makes the rest of the libjpeg infrastructure happy, so it is\nnecessary to use the slow Huffman decoder when decompressing a JPEG image that\nhas restart markers.  This can cause the decompression performance to drop by\nas much as 20%, but the performance will still be much greater than that of\nlibjpeg.  Many consumer packages, such as Photoshop, use restart markers when\ngenerating JPEG images, so images generated by those programs will experience\nthis issue.\n\nFast Integer Forward DCT at High Quality Levels\n-----------------------------------------------\n\nThe algorithm used by the SIMD-accelerated quantization function cannot produce\ncorrect results whenever the fast integer forward DCT is used along with a JPEG\nquality of 98-100.  Thus, libjpeg-turbo must use the non-SIMD quantization\nfunction in those cases.  This causes performance to drop by as much as 40%.\nIt is therefore strongly advised that you use the accurate integer forward DCT\nwhenever encoding images with a JPEG quality of 98 or higher.\n\n\nMemory Debugger Pitfalls\n========================\n\nValgrind and Memory Sanitizer (MSan) can generate false positives\n(specifically, incorrect reports of uninitialized memory accesses) when used\nwith libjpeg-turbo's SIMD extensions.  There are two ways to work around this\nwhen testing libjpeg-turbo with Valgrind, MSan, or other memory debuggers:\n\n1. Disable the SIMD extensions, either by passing an argument of\n   `-DWITH_SIMD=0` to `cmake` when configuring the build or by setting the\n   environment variable `JSIMD_FORCENONE` to `1` at run time.\n2. Define the `ZERO_BUFFERS` preprocessor macro (for instance, by adding\n   `-DZERO_BUFFERS=1` to `CMAKE_C_FLAGS`.)\n","libjpeg-turbo 是一个用于加速JPEG图像编解码的库，利用SIMD指令在常见CPU架构上实现基线和渐进式JPEG压缩与解压缩。其核心功能包括比传统libjpeg快2-6倍的处理速度、优化的哈夫曼编码例程以及支持32位和大端字节序像素缓冲区的颜色空间扩展。该项目提供了传统的libjpeg API和更简洁易用的TurboJPEG API两种接口选择。libjpeg-turbo适用于需要高性能JPEG图像处理的各种场景，如视频流传输、图片编辑软件等，特别适合对性能有高要求的应用环境。",2,"2026-06-11 03:08:05","top_language"]