Define supported decoding software #37
Labels
Comments
This was referenced May 10, 2014
|
I think we're just going to handle this on a case by case basis when we get reports of decoder incompatibility. |
kornelski
pushed a commit
to ImageOptim/mozjpeg-cocoa
that referenced
this issue
Apr 27, 2016
At one time, it was possible to use CMake to build under Cygwin, but that hasn't worked since 1.4.1 (due to the Huffman codec changes that now require SIZEOF_SIZE_T to be defined for non-WIN32 platforms) and may have even been broken before that. Originally, we used the "date" command under MSYS in order to obtain the default build number, but that was rendered unnecessary by 5e3bb3e (v1.3 beta.) 9fe22da (1.4 beta) further modified CMakeLists.txt so that the "date" command was only used on Cygwin, but for unexplained reasons, that commit also applied the (now vestigial) code to all non-WIN32 platforms. This prevented CMakeLists.txt from displaying an error if someone attempted to use the CMake build system on Un*x platforms, and that may have been behind the flurry of pull requests and issues-- including mozilla#21, mozilla#29, mozilla#37, mozilla#58, mozilla#73-- complaining that the CMake build system didn't work on Un*x platforms (although it was not until mozilla#73 that this bug came to light.) This commit removes all vestiges of Un*x support from the CMake build system and makes it clear that CMake cannot be used to build libjpeg-turbo on non-WIN32 platforms. It is our position that CMake will not be supported on non-WIN32 platforms until/unless the autotools build system is removed, and this will not happen without broad support from the community (including major O/S vendors.) If you are in favor of migrating the entire build system to CMake, then please make your voice heard by commenting on mozilla#56.
xinyu391
pushed a commit
to xinyu391/mozjpeg
that referenced
this issue
Sep 25, 2018
See mozilla#56 for discussion. Fixes mozilla#21, Fixes mozilla#29, Fixes mozilla#37, Closes mozilla#56, Fixes mozilla#58, Closes mozilla#73 Obviates mozilla#82 See also: https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/ https://sourceforge.net/p/libjpeg-turbo/patches/5/
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should always produce a 'standard' and 'compliant' bitstream (although at times this may be poorly defined!).
Since some decoders have broken / incomplete implementations- and this may add a burden to support their legacy, we should define a range of 'minimum' decoders that will be supported and actively tested against (most common use cases). These would include certain browsers (i.e. do we support right back to IE6?) and common libraries.
As well as improving QA and Unit Tests, it will allow new concepts to be tested and fast tracked.
Previously support for editors (Photoshop Issue #29) was considered mandatory. If software has a broken decoder, there should be a discussion whether this should be supported at the cost of performance. Optimizing images for web publishing is normally a final step, and breaking editor compatibility may be acceptable. ...?
The text was updated successfully, but these errors were encountered: