-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is compatibility with Adobe Photoshop mandatory? #29
Comments
We should not break compatibility with Photoshop. Not breaking compat is a major goal for this project, and Photoshop is important. |
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
When I wrote JSK to show the different JPEG scans I quickly discovered that Adobe Photoshop CS5 (and CS6 at least) was unable to decode some JPEGs like the one included here (if I'm right the problem comes from the non-interleaved first scan, it holds only Y).
So is the compatibility target restricted to web browsers or larger i.e. including well-known software like Photoshop (which unfortunately is a bit crappy)?
Custom progressive scan used to produce it:
0: 0-0, 0, 0 ; # DC coefficients Y
0: 1-5, 0, 0 ; # 5 first AC coefficients Y
1,2: 0-0, 0, 0 ; # Interleaved DC scan Cb & Cr
0: 6-27, 0, 0 ; # 22 more Y
1: 1-14, 0, 0 ; # 14 first AC coefficients Cb
2: 1-14, 0, 0 ; # 14 first AC coefficients Cr
0: 28-63, 0, 0 ; # Remaining Y coefficients
1: 15-63, 0, 0 ; # Remaining Cb coefficients
2: 15-63, 0, 0 ; # Remaining Cr coefficients
The text was updated successfully, but these errors were encountered: