Comment 1:

Labels changed: added priority-later, removed priority-triage.

Owner changed to @nigeltao.

Status changed to Accepted.

Comment 2:

Out of curiousity, what program generated these CMYK JPEGs?

Comment 3 by samuel.stauffer:

Not sure what created this particular image, but I imagine software like Adobe
Illustrator and other apps meant for printed design would produce CMYK.  This image
comes from a user's avatar on a service I run. It's using Go for the dynamic resizing
proxy to serve the avatar images.

Comment 4:

Labels changed: added size-l.

Comment 5 by jsummers3456:

Since the Go library treats YCbCr as a full-fledged color format (rather than as an
internal part of a compression algorithm for RGB images), for consistency the example
image above should probably be called "YCCK", not "CMYK".
Raw CMYK and raw RGB JPEG images do exist. They are rare, but are widely supported by
viewers. If YCCK support is being considered, I suggest that CMYK and RGB be considered
as well.
RGB JPEGs can be created with the -rgb option of the cjpeg utility included with libjpeg
8d.

Comment 6:

I'm wary of adding new color types so close to an API freeze. I'm marking this bug as
out of scope for the Go 1.1 timeframe.

Labels changed: removed go1.1, size-l.

Comment 7 by kaaloo:

I am also interested in using Go for thumbnailing but have hit this issue with some of
the problem images we have received in the past.

Comment 8:

Labels changed: added go1.2maybe.

Comment 9:

Labels changed: added feature.

Comment 10:

Won't happen for 1.2.

Labels changed: added go1.3maybe, removed go1.2maybe.

Comment 11:

Labels changed: removed go1.3maybe.

Comment 12 by dan.pupius:

Here's another example image that causes this error.   Would love to see more extensive
image decoding support. We're using Go to resize and crop user-provided images.

Attachments:

1. 0-sVYLjSP1-47U__fC.jpeg (271255 bytes)

Comment 13 by dolby0:

Another sample image, that fails to convert with "unsupported JPEG feature: SOF has
wrong length" error

Attachments:

1. porsche-cayman-2013-3_0.jpg (1053952 bytes)

Comment 14 by dolby0:

I think google converted image above, so this is the original
https://www.dropbox.com/s/2kjzt903pup7t2y/porsche-cayman-2013-3_0.jpg

Comment 15 by alexander.lobunets:

Yet another example of getting: 
... value jpeg.UnsupportedError = "bad Pq value" ("unsupported JPEG feature: bad Pq
value")

Attachments:

1. bad.jpg (535175 bytes)

Comment 16:

Labels changed: added go1.3maybe.

Comment 17:

Labels changed: removed feature.

Comment 18:

Labels changed: added release-none, removed go1.3maybe.

Comment 19:

Labels changed: added repo-main.

Comment 20 by sudhir.j:

Here's another example: 
http://demjjtnflw8t9.cloudfront.net/2dfcfeb5-5e5b-49b6-ad74-5c4fb47d8581

Comment 21 by remco.verhoef.red5:

I've made a very basic additional implementation of CMYK to the default image library.
No ICC or whatever, just plain CMYK. 
https://github.com/nl5887/golang-image

Comment 22 by arun.pbk:

Still broken. Any timeline for this to be fixed. 
The above library did not work for me.

Comment 23 by xing@fictionpress.com:

We are getting this problem as well.

alexander.lobunets: the "bad Pq value" is a different issue, #9888.

@nigeltao So, if I go get image, should CMYK decoding now work? (Or more probably I need to go get -u...)

CMYK decoding works with the latest (unstable) release of the standard library, which is due to be released as Go 1.5 on August 1.

If you need it before then, you should be able to fork the image/... packages from 1.5 and run them on 1.4.

If you are on 1.4, though, it won't be as easy as running "go get", since image/jpeg, image/color and image are part of the standard library.

@nigeltao Yeah, I wasn't sure if the std lib was tightly versioned with the Go runtime or not. Not a major issue, but I'll definitely try out the CMYK support when Go 1.5 drops. Thanks so much for this improvement!