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

Update Footnote #18 (JFIF) #104

Closed
jyutzler opened this issue Jun 3, 2015 · 10 comments
Closed

Update Footnote #18 (JFIF) #104

jyutzler opened this issue Jun 3, 2015 · 10 comments

Comments

@jyutzler
Copy link
Contributor

jyutzler commented Jun 3, 2015

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
Copy link
Contributor

pepijnve commented Jun 4, 2015

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 #104.

@jyutzler jyutzler added this to the tiles-corrigendum milestone Jun 16, 2015
@bradh
Copy link
Contributor

bradh commented Jun 17, 2015

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
Copy link
Contributor

@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
Copy link
Contributor

Example or a CMYK image from the ERDC sample data set

@jyutzler
Copy link
Contributor Author

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
Copy link
Contributor

@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
Copy link
Contributor Author

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

@jyutzler
Copy link
Contributor Author

The following was forwarded to me by @pepijnve


I believe this is related to #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
Copy link
Contributor Author

jyutzler commented Jul 6, 2015

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
Copy link
Contributor Author

Approved in today's SWG.

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

3 participants