[Geopackage] Geopackage Digest, Vol 13, Issue 18

DBurken at Radiantblue.com DBurken at Radiantblue.com
Wed Jun 24 10:07:21 EDT 2015


Yeah that's what I get too in my code. Note it's not gdal based so it's not a gdal issue, or a spec issue.  It's the jpeg tile generation code used.  I have that source image WhiteHorse_clip.tif and can generate a viewable gpkg with ossim-chipper but I cannot give out without customer approval.

Take care,
Dave

On 06/24/2015 09:47 AM, Patrick van Dijk wrote:
This is what it looks like in the Image Editor of SQLite Professional.
When I extract the image and view it in Microsoft Photo Viewer it seems to be fine (see sqlite_whitehorse.jpg)

When viewing Whitehorse in our application (Spatial Workshop), which is based on .NET/C# it renders fine, apart from the blackmess on the edge
(which I think should be transparent).

Regards,

Patrick

On Tue, Jun 23, 2015 at 6:00 PM, <geopackage-request at lists.opengeospatial.org<mailto:geopackage-request at lists.opengeospatial.org>> wrote:
Send Geopackage mailing list submissions to
        geopackage at lists.opengeospatial.org<mailto:geopackage at lists.opengeospatial.org>

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.opengeospatial.org/mailman/listinfo/geopackage
or, via email, send a message with subject or body 'help' to
        geopackage-request at lists.opengeospatial.org<mailto:geopackage-request at lists.opengeospatial.org>

You can reach the person managing the list at
        geopackage-owner at lists.opengeospatial.org<mailto:geopackage-owner at lists.opengeospatial.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Geopackage digest..."


Today's Topics:

   1. Re: Displaying Geopackage Raster data (Even Rouault)
      (Jeff Yutzler)
   2. Re: Displaying Geopackage Raster data (Even Rouault)
      (Pepijn Van Eeckhoudt)


----------------------------------------------------------------------

Message: 1
Date: Tue, 23 Jun 2015 10:00:12 -0400
From: Jeff Yutzler <jeffy at imagemattersllc.com<mailto:jeffy at imagemattersllc.com>>
To: geopackage at lists.opengeospatial.org<mailto:geopackage at lists.opengeospatial.org>
Subject: Re: [Geopackage] Displaying Geopackage Raster data (Even
        Rouault)
Message-ID:
        <CACuR0KvLi+qRzTLt2Gi0yEuj+vki9+=RLJDmcxhOJFcihaw3xA at mail.gmail.com<mailto:RLJDmcxhOJFcihaw3xA at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

>
> Date: Fri, 19 Jun 2015 20:37:49 +0200
> From: Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>
> To: geopackage at lists.opengeospatial.org<mailto:geopackage at lists.opengeospatial.org>
> Subject: Re: [Geopackage] Displaying Geopackage Raster data
> Message-ID: <201506192037.50245.even.rouault at spatialys.com<mailto:201506192037.50245.even.rouault at spatialys.com>>
> Content-Type: Text/Plain;  charset="utf-8"
>
> Le vendredi 19 juin 2015 18:46:03, Burken, David a ?crit :
> > Hi Phillip,
> >
> > I can read with the ossim code but they are  using jpeg tiles with a CMYK
> > compression and I can't get the colors correct.  I think the gdal folks
> > complained about this also.  The original Whitehorse gpkg which they said
> > was incorrect I could read just fine.  We usually do pnga for the edge
> > tiles that are partial and plain old JCS_RRG jpeg for interior tiles.  I
> > thinks they are using the "K" for alpha maybe.
>
> I tried your hypothesis since GDAL does CMYK -> RGB conversion, by
> considering
> CMY as RGB without conversion, but the result is complete garbage, whereas
> the
> current CMYK -> RGB conversion produce just "weird" colors... One
> hypothesis I
> didn't test is to take the reverse value of K since this is often a source
> of
> ambiguity...
>
>
I'm not 100% clear on what the actual issue is here. Is there a
problem with the spec? If so, please write up a ticket and I will make sure
the SWG takes a look at it.
https://github.com/opengeospatial/geopackage/issues
Thanks,
Jeff

--
Jeff Yutzler
Image Matters LLC
Mobile: (703) 981-8753<tel:%28703%29%20981-8753>
Office: (703) 428-6731<tel:%28703%29%20428-6731>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150623/57119d62/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 23 Jun 2015 17:43:56 +0200
From: Pepijn Van Eeckhoudt <pepijn at vaneeckhoudt.net<mailto:pepijn at vaneeckhoudt.net>>
To: Jeff Yutzler <jeffy at imagemattersllc.com<mailto:jeffy at imagemattersllc.com>>
Cc: geopackage at lists.opengeospatial.org<mailto:geopackage at lists.opengeospatial.org>
Subject: Re: [Geopackage] Displaying Geopackage Raster data (Even
        Rouault)
Message-ID: <D42BDFBF-A98F-4E8B-A2F4-A12D9D9555AA at vaneeckhoudt.net<mailto:D42BDFBF-A98F-4E8B-A2F4-A12D9D9555AA at vaneeckhoudt.net>>
Content-Type: text/plain; charset="utf-8"

> I'm not 100% clear on what the actual issue is here. Is there a problem with the spec? If so, please write up a ticket and I will make sure the SWG takes a look at it.
> https://github.com/opengeospatial/geopackage/issues <https://github.com/opengeospatial/geopackage/issues>
> Thanks,
> Jeff
>

Hi Jeff,

I believe this is related to https://github.com/opengeospatial/geopackage/issues/104 <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 <https://cloud.githubusercontent.com/assets/225326/8309554/6187e18c-19cb-11e5-9713-7d0f8143c8be.jpg> 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 <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 <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/
  -------------------------------------

<snip>

*** 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)

 <https://cloud.githubusercontent.com/assets/225326/8309554/6187e18c-19cb-11e5-9713-7d0f8143c8be.jpg> <https://cloud.githubusercontent.com/assets/225326/8309554/6187e18c-19cb-11e5-9713-7d0f8143c8be.jpg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150623/5b8e03f8/attachment-0001.html>

End of Geopackage Digest, Vol 13, Issue 18
******************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20150624/a5ded005/attachment.html>


More information about the Geopackage mailing list