Skip to content
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

Closed
frkay opened this issue Mar 19, 2014 · 1 comment
Closed

Is compatibility with Adobe Photoshop mandatory? #29

frkay opened this issue Mar 19, 2014 · 1 comment
Assignees

Comments

@frkay
Copy link

frkay commented Mar 19, 2014

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

snap

@bdaehlie
Copy link
Contributor

We should not break compatibility with Photoshop. Not breaking compat is a major goal for this project, and Photoshop is important.

@bdaehlie bdaehlie self-assigned this Mar 27, 2014
fbossen added a commit that referenced this issue May 8, 2014
Add option to have a single DC scan wherein all components are
interleaved when using progressive mode. This may resolve compatibility
issues raised in #29 and #48.
This option is available through -onedcscan in cjpeg
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants