kmx git

Commit	Date	Message
e69dd40c	2024-01-23T13:26:41	Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226
3d1d68cf	2023-10-04T13:20:38	README.md: Mention 4:4:0 math. incomp. vs. jpeg-6b libjpeg-turbo implements 4:4:0 "fancy" (smooth) upsampling, which is enabled by default when decompressing JPEG images that use 4:4:0 chrominance subsampling. libjpeg did not and does not implement fancy 4:4:0 upsampling.
926f1f3d	2023-07-05T12:41:32	README.md: Include GitHub Sponsors link/button Closes #706
762f8b4f	2023-07-05T10:55:07	Doc: Mention that we are a JPEG ref implementation
6b9e3b04	2023-06-19T11:11:16	README.md: Include link to project home page (for compliance with SignPath's Code of Conduct for Open Source projects)
6c2bc901	2022-11-03T14:39:19	Don't allow disabling in-memory src/dest managers By default, libjpeg-turbo 1.3.x and later have enabled the in-memory source/destination manager functions from libjpeg v8 when emulating the libjpeg v6b or v7 API/ABI, which has allowed operating system distributors to provide those functions without adopting the backward-incompatible libjpeg v8 API/ABI. Prior to libjpeg-turbo 1.5.x, it made sense to allow users to disable the in-memory source/destination manager functions at build time and thus retain both backward and forward API/ABI compatibility relative to libjpeg v6b or v7. Since then, however, we have introduced several new libjpeg API functions that break forward API/ABI compatibility, so it no longer makes sense to allow the in-memory source/destination managers to be disabled. libjpeg-turbo only claims to be backward-API/ABI-compatible, i.e. to allow applications built against libjpeg or an older version of libjpeg-turbo to work properly with the current version of libjpeg-turbo.
240ba417	2020-01-07T16:40:32	Neon: Intrinsics impl. of prog. Huffman encoding The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance. There was no previous AArch32 GAS implementation.
7c1a1789	2020-11-05T16:04:55	Merge branch 'master' into dev
6e632af9	2020-11-04T10:13:06	Demote "fast" [I]DCT algorithms to legacy status - Refer to the "slow" [I]DCT algorithms as "accurate" instead, since they are not slow under libjpeg-turbo. - Adjust documentation claims to reflect the fact that the "slow" and "fast" algorithms produce about the same performance on AVX2-equipped CPUs (because of the dual-lane nature of AVX2, it was not possible to accelerate the "fast" algorithm beyond what was achievable with SSE2.) Also adjust the claims to reflect the fact that the "fast" algorithm tends to be ~5-15% faster than the "slow" algorithm on non-AVX2-equipped CPUs, regardless of the use of the libjpeg-turbo SIMD extensions. - Indicate the legacy status of the "fast" and float algorithms in the documentation and cjpeg/djpeg usage info. - Remove obsolete paragraph in the djpeg man page that suggested that the float algorithm could be faster than the "fast" algorithm on some CPUs.
59352195	2020-10-19T21:17:46	Merge branch 'master' into dev
1ed312ea	2020-10-15T17:47:31	"ARM"="Arm", "NEON"="Neon" Refer to: https://www.arm.com/company/policies/trademarks/arm-trademark-list/arm-trademark https://www.arm.com/company/policies/trademarks/arm-trademark-list/neon-trademark NOTE: These changes are only applied to change log entries for 2.0.x and later, since the change log is a historical record and Arm's new trademark policy did not go into effect until late 2017.
fe79f56b	2020-07-28T15:09:00	Merge branch 'master' into dev
30282a87	2020-07-28T13:00:39	README.md, jquant2.c: Use gender-neutral pronouns Closes #444
c4675d62	2019-12-31T00:42:53	Merge branch 'master' into dev
29f718ee	2019-12-31T00:06:11	README.md, package specs: Various tweaks - Don't enumerate the types of SIMD instructions that libjpeg-turbo supports, as this can change without notice. - Use more clear terminology when describing support for libjpeg v7/v8 features ("libjpeg" is, colloquially but not officially, the name for the IJG's software, whereas the "libjpeg API" refers to our emulation of said software.) - "PhotoShop" = "Photoshop" (StudLy Caps Police) - Adjust dynamic library versions to reflect the addition of jpeg_read_icc_profile() and jpeg_write_icc_profile() in libjpeg-turbo 2.0.x.
5db6a681	2019-08-30T12:02:50	README.md: Document memory debugger pitfalls (more specifically, the need to disable libjpeg-turbo's SIMD extensions when testing with valgrind, MSan, etc.) Addresses a concern expressed in #365
f448279b	2019-08-30T11:15:47	README.md: Remove vestigial autotools references
450306a8	2018-04-06T18:31:17	READMEs: Mention that prog JPEG is now accelerated
d83c9977	2018-03-23T00:00:58	README.md: clarify where API docs can be found
985ef4f9	2018-02-14T14:50:04	Merge branch 'master' into dev
700de8aa	2018-02-14T15:41:36	README.md: Fix permissions
8c40ac8a	2017-11-16T18:46:01	Add TurboJPEG C example and clean up Java example Also rename example.c --> example.txt and add a disclaimer to that file so people will stop trying to compile it.
0ff7da71	2016-11-16T15:55:12	Advertise the new AVX2 SIMD extensions (our story so far ...)
ab664e35	2016-11-18T09:09:41	BUILDING.md/README.md: Increment libjpeg SO age Documentation buglet. This should have been changed in 6ed4d9d11085acd04dc7f2f899848693976dc010 to reflect the addition of libjpeg API functions in libjpeg-turbo 1.5.
ce26e83f	2016-11-18T09:08:52	README.md: Don't use trailing spaces as line break Makes it easier to maintain this file using editors that automatically remove trailing spaces.
9407cf7f	2016-09-22T00:42:25	README.md: Fix typo Introduced in 17de51835735e319ada5ca139a64227423946a8a Closes #102
e5f280c4	2016-03-11T11:14:28	README.md: Link to BUILDING.md Addresses a concern expressed in #56 and #58.
4f581231	2016-03-09T17:23:45	BUILDING.md and README.md: Cosmetic tweaks
fe11699d	2016-02-03T14:02:13	Adjust performance claims Document the latest benchmarks on the Nexus 5X and change the "2-4x" overall claim to "2-6x". The peak performance on x86 platforms was already closer to 5x, and the addition of SIMD-accelerated Huffman encoding gave it that extra push over the cliff.
e42032ba	2015-10-10T10:56:58	README.md: create link for jcstest.c
17de5183	2015-10-10T10:34:55	Markdown versions of README, LICENSE, BUILDING
7e3acc0e	2015-10-10T10:25:46	Rename README, LICENSE, BUILDING text files The IJG README file has been renamed to README.ijg, in order to avoid confusion (many people were assuming that that was our project's README file and weren't reading README-turbo.txt) and to lay the groundwork for markdown versions of the libjpeg-turbo README and build instructions.

e69dd40c

2024-01-23T13:26:41

Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226

3d1d68cf

2023-10-04T13:20:38

README.md: Mention 4:4:0 math. incomp. vs. jpeg-6b libjpeg-turbo implements 4:4:0 "fancy" (smooth) upsampling, which is enabled by default when decompressing JPEG images that use 4:4:0 chrominance subsampling. libjpeg did not and does not implement fancy 4:4:0 upsampling.

926f1f3d

2023-07-05T12:41:32

README.md: Include GitHub Sponsors link/button Closes #706

762f8b4f

2023-07-05T10:55:07

Doc: Mention that we are a JPEG ref implementation

6b9e3b04

2023-06-19T11:11:16

README.md: Include link to project home page (for compliance with SignPath's Code of Conduct for Open Source projects)

6c2bc901

2022-11-03T14:39:19

Don't allow disabling in-memory src/dest managers By default, libjpeg-turbo 1.3.x and later have enabled the in-memory source/destination manager functions from libjpeg v8 when emulating the libjpeg v6b or v7 API/ABI, which has allowed operating system distributors to provide those functions without adopting the backward-incompatible libjpeg v8 API/ABI. Prior to libjpeg-turbo 1.5.x, it made sense to allow users to disable the in-memory source/destination manager functions at build time and thus retain both backward and forward API/ABI compatibility relative to libjpeg v6b or v7. Since then, however, we have introduced several new libjpeg API functions that break forward API/ABI compatibility, so it no longer makes sense to allow the in-memory source/destination managers to be disabled. libjpeg-turbo only claims to be backward-API/ABI-compatible, i.e. to allow applications built against libjpeg or an older version of libjpeg-turbo to work properly with the current version of libjpeg-turbo.

240ba417

2020-01-07T16:40:32

Neon: Intrinsics impl. of prog. Huffman encoding The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance. There was no previous AArch32 GAS implementation.

7c1a1789

2020-11-05T16:04:55

Merge branch 'master' into dev

6e632af9

2020-11-04T10:13:06

Demote "fast" [I]DCT algorithms to legacy status - Refer to the "slow" [I]DCT algorithms as "accurate" instead, since they are not slow under libjpeg-turbo. - Adjust documentation claims to reflect the fact that the "slow" and "fast" algorithms produce about the same performance on AVX2-equipped CPUs (because of the dual-lane nature of AVX2, it was not possible to accelerate the "fast" algorithm beyond what was achievable with SSE2.) Also adjust the claims to reflect the fact that the "fast" algorithm tends to be ~5-15% faster than the "slow" algorithm on non-AVX2-equipped CPUs, regardless of the use of the libjpeg-turbo SIMD extensions. - Indicate the legacy status of the "fast" and float algorithms in the documentation and cjpeg/djpeg usage info. - Remove obsolete paragraph in the djpeg man page that suggested that the float algorithm could be faster than the "fast" algorithm on some CPUs.

59352195

2020-10-19T21:17:46

Merge branch 'master' into dev

1ed312ea

2020-10-15T17:47:31

"ARM"="Arm", "NEON"="Neon" Refer to: https://www.arm.com/company/policies/trademarks/arm-trademark-list/arm-trademark https://www.arm.com/company/policies/trademarks/arm-trademark-list/neon-trademark NOTE: These changes are only applied to change log entries for 2.0.x and later, since the change log is a historical record and Arm's new trademark policy did not go into effect until late 2017.

fe79f56b

2020-07-28T15:09:00

Merge branch 'master' into dev

30282a87

2020-07-28T13:00:39

README.md, jquant2.c: Use gender-neutral pronouns Closes #444

c4675d62

2019-12-31T00:42:53

Merge branch 'master' into dev

29f718ee

2019-12-31T00:06:11

README.md, package specs: Various tweaks - Don't enumerate the types of SIMD instructions that libjpeg-turbo supports, as this can change without notice. - Use more clear terminology when describing support for libjpeg v7/v8 features ("libjpeg" is, colloquially but not officially, the name for the IJG's software, whereas the "libjpeg API" refers to our emulation of said software.) - "PhotoShop" = "Photoshop" (StudLy Caps Police) - Adjust dynamic library versions to reflect the addition of jpeg_read_icc_profile() and jpeg_write_icc_profile() in libjpeg-turbo 2.0.x.

5db6a681

2019-08-30T12:02:50

README.md: Document memory debugger pitfalls (more specifically, the need to disable libjpeg-turbo's SIMD extensions when testing with valgrind, MSan, etc.) Addresses a concern expressed in #365

f448279b

2019-08-30T11:15:47

README.md: Remove vestigial autotools references

450306a8

2018-04-06T18:31:17

READMEs: Mention that prog JPEG is now accelerated

d83c9977

2018-03-23T00:00:58

README.md: clarify where API docs can be found

985ef4f9

2018-02-14T14:50:04

Merge branch 'master' into dev

700de8aa

2018-02-14T15:41:36

README.md: Fix permissions

8c40ac8a

2017-11-16T18:46:01

Add TurboJPEG C example and clean up Java example Also rename example.c --> example.txt and add a disclaimer to that file so people will stop trying to compile it.

0ff7da71

2016-11-16T15:55:12

Advertise the new AVX2 SIMD extensions (our story so far ...)

ab664e35

2016-11-18T09:09:41

BUILDING.md/README.md: Increment libjpeg SO age Documentation buglet. This should have been changed in 6ed4d9d11085acd04dc7f2f899848693976dc010 to reflect the addition of libjpeg API functions in libjpeg-turbo 1.5.

ce26e83f

2016-11-18T09:08:52

README.md: Don't use trailing spaces as line break Makes it easier to maintain this file using editors that automatically remove trailing spaces.

9407cf7f

2016-09-22T00:42:25

README.md: Fix typo Introduced in 17de51835735e319ada5ca139a64227423946a8a Closes #102

e5f280c4

2016-03-11T11:14:28

README.md: Link to BUILDING.md Addresses a concern expressed in #56 and #58.

4f581231

2016-03-09T17:23:45

BUILDING.md and README.md: Cosmetic tweaks

fe11699d

2016-02-03T14:02:13

Adjust performance claims Document the latest benchmarks on the Nexus 5X and change the "2-4x" overall claim to "2-6x". The peak performance on x86 platforms was already closer to 5x, and the addition of SIMD-accelerated Huffman encoding gave it that extra push over the cliff.

e42032ba

2015-10-10T10:56:58

README.md: create link for jcstest.c

17de5183

2015-10-10T10:34:55

Markdown versions of README, LICENSE, BUILDING

7e3acc0e

2015-10-10T10:25:46

Rename README, LICENSE, BUILDING text files The IJG README file has been renamed to README.ijg, in order to avoid confusion (many people were assuming that that was our project's README file and weren't reading README-turbo.txt) and to lay the groundwork for markdown versions of the libjpeg-turbo README and build instructions.

kc3-lang/libjpeg-turbo/README.md

README.md

Log