Closed jyutzler closed 9 years ago
The ISO/ITU JFIF specification can be obtained free of charge at http://www.itu.int/rec/T-REC-T.871-201105-I/en http://www.itu.int/rec/T-REC-T.871-201105-I/en. Might be better to reference the international standard.
Pepijn
On 04 Jun 2015, at 00:05, Jeff Yutzler notifications@github.com wrote:
This link is dead. I believe this is the new link but I need to confirm it. http://www.w3.org/Graphics/JPEG/jfif3.pdf http://www.w3.org/Graphics/JPEG/jfif3.pdf — Reply to this email directly or view it on GitHub https://github.com/opengeospatial/geopackage/issues/104.
As part of this issue, or as a separate issue, the SWG could consider profiling JFIF (e.g. to specify which colourspaces are supported).
@bradh section 6.2 of the referenced ITU JFIF spec requires images to be either Y only or YCbCr. Perhaps requiring that images are compliant with the JFIF specification is sufficient?
Switching references would be a substantive change to the specification. If we need to do this then fine but I am not keen on doing it without a clear business need.
@pepijnve I need a clear description of the screwy color issue. It is a mis-encoding (the GPKG is flawed), is it a valid GPKG using an obscure but valid parameter (in which case the spec is too broad, and replacing the reference would be an appropriate corrective action), or is the GPKG fully valid and there is an implementation issue in your client (in which case we should publish some implementation guidance)? Someone needs to document this as a separate issue so we can evaluate it independently.
@jyutzler this is not a spec change. The current spec refers to a document called jfif.pdf at jpeg.org. This is the JPEG working group website. If you go to http://www.jpeg.org/jpeg/documentation.html you'll find an updated link to the JFIF specification that points to the ISO and ITU versions of that spec. The PDF of the ITU document is available free of charge which is why I suggested referring to that. So in summary, this change simply updates the link to the canonical version of the JFIF spec that we were already referencing.
On the colour issue, that would take too long to type on my phone :) Long story short, the images in the ERRC dataset are not valid JFIF files. That means that that file is not a valid GeoPackage file.
I opened #115 to deal with the color thing as I think it is a separate issue.
The following was forwarded to me by @pepijnve
I believe this is related to https://github.com/opengeospatial/geopackage/issues/104. The images in the ERDC file are 4 channel CMYK ones. Strictly speaking these are not valid JFIF files since JFIF requires 1 (Y) or 3 channel (YCbCr) images and specifies the RGB <-> YCbCr conversion formulas that should be used.
I’ve extracted and attached one of the images from the dataset and attached it to the linked issue. That hopefully makes it a bit easier to analyse. I also dumped the metadata from that file using JPEGsnoop (see below). That clearly shows this being a 4 channel image.
CMYK in JPEG seems to be an Adobe specific extension. Looking through the libjpeg code (see jdapimin.c#default_decompress_parms) it recognises a JPEG as being CMYK if it has 4 channels and contains an Adobe specific bit of metadata in an APP14 segment. The best spec I could find for this is http://www.aiim.org/documents/standards/PDF-Ref/References/Adobe/5116.DCT_Filter.pdf which was referenced from https://issues.apache.org/jira/browse/IMAGING-89
For maximum interoperability, GeoPackage should probably stick to JFIF, but that’s just my 2 cents.
Hth,
Pepijn
JPEGsnoop 1.7.3 by Calvin Hass http://www.impulseadventure.com/photo/
I just conferred with @pdaisey and he confirmed that he was using T.81 as his normative reference. We find no substantive differences between T.81 and T.871 so tomorrow I will move to make T.871 the normative reference.
Note that all three documents are consistent with regards to their support of color spaces so this will not affect #115.
Approved in today's SWG.
This link is dead. I believe this is the new link but I need to confirm it. http://www.w3.org/Graphics/JPEG/jfif3.pdf