opengeospatial / geopackage

An asciidoc version of the GeoPackage specification for easier collaboration
https://www.geopackage.org
Other
264 stars 71 forks source link

Update Footnote #18 (JFIF) #104

Closed jyutzler closed 9 years ago

jyutzler commented 9 years ago

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

pepijnve commented 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.

bradh commented 9 years ago

As part of this issue, or as a separate issue, the SWG could consider profiling JFIF (e.g. to specify which colourspaces are supported).

pepijnve commented 9 years ago

@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?

pepijnve commented 9 years ago

Example or a CMYK image from the ERDC sample data set

jyutzler commented 9 years ago

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.

pepijnve commented 9 years ago

@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.

jyutzler commented 9 years ago

I opened #115 to deal with the color thing as I think it is a separate issue.

jyutzler commented 9 years ago

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/


**\* Marker: SOF0 (Baseline DCT) (xFFC0) *** OFFSET: 0x0000008C Frame header length = 20 Precision = 8 Number of Lines = 256 Samples per Line = 256 Image Size = 256 x 256 Raw Image Orientation = Landscape Number of Img components = 4 Component[1]: ID=0x01, Samp Fac=0x22 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (C) Component[2]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (M) Component[3]: ID=0x03, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Y) Component[4]: ID=0x04, Samp Fac=0x22 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (K)
jyutzler commented 9 years ago

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.

jyutzler commented 9 years ago

Approved in today's SWG.