-
Notifications
You must be signed in to change notification settings - Fork 415
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
Omit JFIF header by default #36
Conversation
Do not create JFIF header (APP0 block) by default. This saves 18 bytes per image. Fixes issue #18. Signed-off-by: Andrew <dent.ace@gmail.com>
APP14 is required by YCCK images (since there is no other method to distinguish YCCK image out of CMYK images without APP14) |
@roytam1 - Thanks for the feedback. |
... Oh and the sourcecode refers to the APP14 Adobe Marker as 'optional'... :) |
in http://code.google.com/p/go/issues/detail?id=4500#c12 you can find CMYK image with compid=1,2,3,4 |
@roytam1 Thanks for the example. Interestingly the 'fix' for this doesn't use the APP14 marker, it also infers the color space by SOF (if no ICC profile): |
Talked to some folks, we are going to go ahead and disable JFIF by default and leave an option to enable it. We can reverse course if we learn something about why this is problematic. |
Upon further reflection, this win might not be worthwhile. Removing JFIF when it is expected could be considered a compatibility issue, and it doesn't really take up much space. Making it an option when it isn't with other encoders will cause some config headaches. I'm going to close this out but am happy to re-consider later. |
@bdaehlie - I submitted this after a code review of main opensource decoding libraries in use (from web browsers to LibreOffice, etc.). Since cameras can produce jpegs with EXIF and no JFIF, I didn't find any implementations dependent on JFIF block for successful decoding. To verify this, I also discussed the proposal with various prominent individuals in the jpeg compression / hacking community. However, as discussed above, it was determined the APP14 marker is required for broad compatibility (although safe to remove for many decoders). It seems a shame to limit compression based on certain decoding libraries. There should be some discussion of this re. #37 to define supported majority (and highlight any minority decoder implementations that wont be supported). We should also be making decisions based on code review (where decoding libraries have source code available)- rather than gut feel. |
Do not create JFIF header (APP0 block) by default. This saves 18 bytes per image. Fixes issue #18. Unlike original PR, this provides scope to fallback to default behaviour. Not the tidiest patch... I would prefer (once solution is field tested) to strip out all related code, for tidier code base. Utility of APP14 (Adobe) marker should also be investigated in future- is it actually useful for Colorspace data in context of web?