From sanselan-dev-returnpeterbradley@example.com Thu May 07 05:00:27 2009
Return-Path: <sanselan-dev-returnpeterbradley@example.com>
Delivered-To: peterbradley@example.com
Received: (qmail 18090 invoked from network); 7 May 2009 05:00:26 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 7 May 2009 05:00:26 -0000
Received: (qmail 84538 invoked by uid 500); 7 May 2009 05:00:26 -0000
Delivered-To: peterbradley@example.com
Received: (qmail 84492 invoked by uid 500); 7 May 2009 05:00:26 -0000
Mailing-List: contact peterbradley@example.com; run by ezmlm
Precedence: bulk
List-Help: <mailto:peterbradley@example.com>
List-Unsubscribe: <mailto:peterbradley@example.com>
List-Post: <mailto:peterbradley@example.com>
List-Id: <sanselan-dev.incubator.apache.org>
Reply-To: peterbradley@example.com
Delivered-To: mailing list peterbradley@example.com
Received: (qmail 84482 invoked by uid 99); 7 May 2009 05:00:26 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2009 05:00:26 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO mail-ew0-f172.google.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2009 05:00:18 +0000
Received: by ewy20 with SMTP id 20so760912ewy.12
        for <peterbradley@example.com>; Wed, 06 May 2009 21:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        bh=rknj0PrIj+3yhLgmOGKCX/CcpbYWosXM8OZAs8ehtuI=;
        b=iwJwTB0YZs9bDF8ZIcsJ4pzue+oU5rEm6zV6HBpKmSNaANVXhs4e5l9HpTQIA8cc+I
         BksWs+RG+4oMWunn7kRLGW2uVwIQNKUzTbgzc2m7seyRaitWjksYPosgbbTfkBqi4qC9
         yymK2UwU1sse/ZqM+It54rBHSl5b0DgFB70ns=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=DE/gQVUmYplZcRbR3yyr0TjeheYoqxqqLTR98gpWq3fnAZO/zkhfX+VnGAb2eQpTWC
         UuI9EwF9W3WJ31NfvWS2UYqpgHfWvt4XPUuNLVmZMzwZcf69Tag6Z5cwLCHmLNSzws77
         yE3DceJcVomYkjSqO+T0QspeKThA/iwr+r5qw=
MIME-Version: 1.0
Received: by 83.161.120.155 with SMTP id q61mr1034938wed.14.1241672396369; Wed, 
	06 May 2009 21:59:56 -0700 (PDT)
In-Reply-To: <peterbradley@example.com>
References: <peterbradley@example.com>
Date: Thu, 7 May 2009 00:59:56 -0400
Message-ID: <peterbradley@example.com>
Subject: Re: Sanselan issue, with patch
From: Charles Matthew Chen <peterbradley@example.com>
To: peterbradley@example.com, peterbradley@example.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

Hi Jonathan,

   Sorry for the delay reply.  Thanks for looking into this issue and
contributing a patch.  This is a known issue - there seems to be a
large amount of variation in how some IPTC data is encoded.  The
possible problem with continuing after find an unknown marker in IPTC
data is that subsequent data might be invalid.  I'll look into this
issue more when I get a chance.  In the meantime, can you please open
an issue in JIRA and contribute (by attaching it to the issue) a
sample image that demonstrates this issue?

https://issues.apache.org/jira/browse/SANSELAN

Thanks,
   Matthew


On Thu, Apr 30, 2009 at 5:10 PM, Jonathan Giles <peterbradley@example.com> wrote:
> Hi all,
>
> I'm using Sanselan to extract IPTC metadata. Recently I was given an imag=
e
> that was causing Sanselan to return an empty set when retrieving the
> metadata, despite the fact that there is clearly iptc metadata in the ima=
ge.
>
> I trawled through the Sanselan code and found the problem: it's in
> IPTCParser.parseIPTCBlock(...), and is the second 'if' statement within t=
he
> while loop. In particular, instead of the following:
> if (tagMarker !=3D IPTC_RECORD_TAG_MARKER) {
> =A0 if (verbose) {
> =A0 =A0 =A0 System.out.println("Unexpected record tag marker in IPTC data=
.");
> =A0 }
> =A0 return elements;
> }
>
> You should do the following:
> if (tagMarker !=3D IPTC_RECORD_TAG_MARKER) {
> =A0 if (verbose) {
> =A0 =A0 =A0 System.out.println("Unexpected record tag marker in IPTC data=
.");
> =A0 }
> =A0 continue;
> }
>
> In my case, this was tripping up the continued parsing of the image, as i=
t
> was occuring early in the parsing process. If you're interested, the verb=
ose
> output of an attempt to parse this file once the little patch above is
> applied is shown below. In particular, look at the 'Unexpected record tag
> marker in IPTC data.' midway down. I don't know what these values are, an=
d I
> am slightly concerned that I may be throwing away good data. Do you have =
any
> thoughts?
>
> Cheers,
> Jonathan Giles
>
> Output of verbose run after patch was applied:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> blockType 1002 (0x3ea)
> blockSize 6143 (0x17ff)
> blockType 1005 (0x3ed)
> blockSize 16 (0x10)
> blockType 1062 (0x426)
> blockSize 14 (0xe)
> blockType 1037 (0x40d)
> blockSize 4 (0x4)
> blockType 1049 (0x419)
> blockSize 4 (0x4)
> blockType 1011 (0x3f3)
> blockSize 9 (0x9)
> blockType 1034 (0x40a)
> blockSize 1 (0x1)
> blockType 10000 (0x2710)
> blockSize 10 (0xa)
> blockType 1013 (0x3f5)
> blockSize 72 (0x48)
> blockType 1016 (0x3f8)
> blockSize 112 (0x70)
> blockType 1032 (0x408)
> blockSize 16 (0x10)
> blockType 1054 (0x41e)
> blockSize 4 (0x4)
> blockType 1050 (0x41a)
> blockSize 837 (0x345)
> blockType 1064 (0x428)
> blockSize 12 (0xc)
> blockType 1044 (0x414)
> blockSize 4 (0x4)
> blockType 1036 (0x40c)
> blockSize 6151 (0x1807)
> blockType 1057 (0x421)
> blockSize 85 (0x55)
> blockType 1030 (0x406)
> blockSize 7 (0x7)
> blockType 1028 (0x404)
> blockSize 1136 (0x470)
> tagMarker 28 (0x1c)
> recordNumber 1 (0x1)
> tagMarker 0 (0x0)
> Unexpected record tag marker in IPTC data.
> tagMarker 0 (0x0)
> Unexpected record tag marker in IPTC data.
> tagMarker 2 (0x2)
> Unexpected record tag marker in IPTC data.
> tagMarker 0 (0x0)
> Unexpected record tag marker in IPTC data.
> tagMarker 4 (0x4)
> Unexpected record tag marker in IPTC data.
> tagMarker 28 (0x1c)
> recordNumber 1 (0x1)
> tagMarker 90 (0x5a)
> Unexpected record tag marker in IPTC data.
> tagMarker 0 (0x0)
> Unexpected record tag marker in IPTC data.
> tagMarker 3 (0x3)
> Unexpected record tag marker in IPTC data.
> tagMarker 27 (0x1b)
> Unexpected record tag marker in IPTC data.
> tagMarker 37 (0x25)
> Unexpected record tag marker in IPTC data.
> tagMarker 71 (0x47)
> Unexpected record tag marker in IPTC data.
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 0 (0x0)
> ignore record version record! 0
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 5 (0x5)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 25 (0x19)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 40 (0x28)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 55 (0x37)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 80 (0x50)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 85 (0x55)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 103 (0x67)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 105 (0x69)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 110 (0x6e)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 120 (0x78)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 122 (0x7a)
> tagMarker 28 (0x1c)
> recordNumber 2 (0x2)
> recordType 22 (0x16)
>

From sanselan-dev-returnpeterbradley@example.com Thu May 07 21:53:00 2009
Return-Path: <sanselan-dev-returnpeterbradley@example.com>
Delivered-To: peterbradley@example.com
Received: (qmail 81603 invoked from network); 7 May 2009 21:52:59 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 7 May 2009 21:52:59 -0000
Received: (qmail 87414 invoked by uid 500); 7 May 2009 21:52:59 -0000
Delivered-To: peterbradley@example.com
Received: (qmail 87381 invoked by uid 500); 7 May 2009 21:52:59 -0000
Mailing-List: contact peterbradley@example.com; run by ezmlm
Precedence: bulk
List-Help: <mailto:peterbradley@example.com>
List-Unsubscribe: <mailto:peterbradley@example.com>
List-Post: <mailto:peterbradley@example.com>
List-Id: <sanselan-dev.incubator.apache.org>
Reply-To: peterbradley@example.com
Delivered-To: mailing list peterbradley@example.com
Received: (qmail 87370 invoked by uid 99); 7 May 2009 21:52:59 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2009 21:52:59 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO wf-out-1314.google.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2009 21:52:49 +0000
Received: by wf-out-1314.google.com with SMTP id 28so2137388wfa.21
        for <peterbradley@example.com>; Thu, 07 May 2009 14:52:28 -0700 (PDT)
Received: by 83.161.120.155 with SMTP id y1mr1172195wfy.112.1241733148803;
        Thu, 07 May 2009 14:52:28 -0700 (PDT)
Received: from ?83.161.120.155? (ip-118-90-107-245.xdsl.xnet.co.nz [83.161.120.155])
        by mx.google.com with ESMTPS id 27sm472454wff.6.283.161.120.155.52.26
        (version=SSLv3 cipher=RC4-MD5);
        Thu, 07 May 2009 14:52:28 -0700 (PDT)
Message-ID: <peterbradley@example.com>
Date: Fri, 08 May 2009 09:52:23 +1200
From: Jonathan Giles <peterbradley@example.com>
Reply-To: peterbradley@example.com
User-Agent: Thunderbird 83.161.120.155 (Windows/20090302)
MIME-Version: 1.0
To: Charles Matthew Chen <peterbradley@example.com>
CC: peterbradley@example.com
Subject: Re: Sanselan issue, with patch
References: <peterbradley@example.com> <peterbradley@example.com>
In-Reply-To: <peterbradley@example.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Charles,

Thanks for getting back to me regarding this issue. I hope that the 
patch may be considered, given how small it is (1 line). Without this 
patch, my project is unable to use Sanselan. However, with this patch, 
my project works perfectly with a large number of images.

Unfortunately, I can't recall which image actually provided the hurdle 
that required me to investigate this issue, but I will look into it. 
Unfortunately, I am actually leaving on vacation today for a week, so I 
will not be able to do this until I get back.

Sanselan is very important to me now, and I use it extensively for it's 
support for reading and writing IPTC data. Do you have any plans to 
improve Sanselan to make use of Java 5 language features such as 
enumerations and generics? I certainly would benefit from an API with 
these features.

Cheers,
Jonathan Giles

Charles Matthew Chen wrote:
> Hi Jonathan,
>
>    Sorry for the delay reply.  Thanks for looking into this issue and
> contributing a patch.  This is a known issue - there seems to be a
> large amount of variation in how some IPTC data is encoded.  The
> possible problem with continuing after find an unknown marker in IPTC
> data is that subsequent data might be invalid.  I'll look into this
> issue more when I get a chance.  In the meantime, can you please open
> an issue in JIRA and contribute (by attaching it to the issue) a
> sample image that demonstrates this issue?
>
> https://issues.apache.org/jira/browse/SANSELAN
>
> Thanks,
>    Matthew
>
>
> On Thu, Apr 30, 2009 at 5:10 PM, Jonathan Giles <peterbradley@example.com> wrote:
>   
>> Hi all,
>>
>> I'm using Sanselan to extract IPTC metadata. Recently I was given an image
>> that was causing Sanselan to return an empty set when retrieving the
>> metadata, despite the fact that there is clearly iptc metadata in the image.
>>
>> I trawled through the Sanselan code and found the problem: it's in
>> IPTCParser.parseIPTCBlock(...), and is the second 'if' statement within the
>> while loop. In particular, instead of the following:
>> if (tagMarker != IPTC_RECORD_TAG_MARKER) {
>>   if (verbose) {
>>       System.out.println("Unexpected record tag marker in IPTC data.");
>>   }
>>   return elements;
>> }
>>
>> You should do the following:
>> if (tagMarker != IPTC_RECORD_TAG_MARKER) {
>>   if (verbose) {
>>       System.out.println("Unexpected record tag marker in IPTC data.");
>>   }
>>   continue;
>> }
>>
>> In my case, this was tripping up the continued parsing of the image, as it
>> was occuring early in the parsing process. If you're interested, the verbose
>> output of an attempt to parse this file once the little patch above is
>> applied is shown below. In particular, look at the 'Unexpected record tag
>> marker in IPTC data.' midway down. I don't know what these values are, and I
>> am slightly concerned that I may be throwing away good data. Do you have any
>> thoughts?
>>
>> Cheers,
>> Jonathan Giles
>>
>> Output of verbose run after patch was applied:
>> ==============================
>> blockType 1002 (0x3ea)
>> blockSize 6143 (0x17ff)
>> blockType 1005 (0x3ed)
>> blockSize 16 (0x10)
>> blockType 1062 (0x426)
>> blockSize 14 (0xe)
>> blockType 1037 (0x40d)
>> blockSize 4 (0x4)
>> blockType 1049 (0x419)
>> blockSize 4 (0x4)
>> blockType 1011 (0x3f3)
>> blockSize 9 (0x9)
>> blockType 1034 (0x40a)
>> blockSize 1 (0x1)
>> blockType 10000 (0x2710)
>> blockSize 10 (0xa)
>> blockType 1013 (0x3f5)
>> blockSize 72 (0x48)
>> blockType 1016 (0x3f8)
>> blockSize 112 (0x70)
>> blockType 1032 (0x408)
>> blockSize 16 (0x10)
>> blockType 1054 (0x41e)
>> blockSize 4 (0x4)
>> blockType 1050 (0x41a)
>> blockSize 837 (0x345)
>> blockType 1064 (0x428)
>> blockSize 12 (0xc)
>> blockType 1044 (0x414)
>> blockSize 4 (0x4)
>> blockType 1036 (0x40c)
>> blockSize 6151 (0x1807)
>> blockType 1057 (0x421)
>> blockSize 85 (0x55)
>> blockType 1030 (0x406)
>> blockSize 7 (0x7)
>> blockType 1028 (0x404)
>> blockSize 1136 (0x470)
>> tagMarker 28 (0x1c)
>> recordNumber 1 (0x1)
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 2 (0x2)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 4 (0x4)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 28 (0x1c)
>> recordNumber 1 (0x1)
>> tagMarker 90 (0x5a)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 3 (0x3)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 27 (0x1b)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 37 (0x25)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 71 (0x47)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 0 (0x0)
>> ignore record version record! 0
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 5 (0x5)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 40 (0x28)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 55 (0x37)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 80 (0x50)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 85 (0x55)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 103 (0x67)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 105 (0x69)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 110 (0x6e)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 120 (0x78)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 122 (0x7a)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 22 (0x16)
>>
>>     

From sanselan-dev-returnpeterbradley@example.com Fri May 15 04:48:43 2009
Return-Path: <sanselan-dev-returnpeterbradley@example.com>
Delivered-To: peterbradley@example.com
Received: (qmail 75129 invoked from network); 15 May 2009 04:48:43 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 15 May 2009 04:48:43 -0000
Received: (qmail 48907 invoked by uid 500); 15 May 2009 04:48:43 -0000
Delivered-To: peterbradley@example.com
Received: (qmail 48862 invoked by uid 500); 15 May 2009 04:48:43 -0000
Mailing-List: contact peterbradley@example.com; run by ezmlm
Precedence: bulk
List-Help: <mailto:peterbradley@example.com>
List-Unsubscribe: <mailto:peterbradley@example.com>
List-Post: <mailto:peterbradley@example.com>
List-Id: <sanselan-dev.incubator.apache.org>
Reply-To: peterbradley@example.com
Delivered-To: mailing list peterbradley@example.com
Received: (qmail 48852 invoked by uid 99); 15 May 2009 04:48:43 -0000
Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2009 04:48:43 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO mail-px0-f197.google.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2009 04:48:32 +0000
Received: by pxi35 with SMTP id 35so814258pxi.32
        for <peterbradley@example.com>; Thu, 14 May 2009 21:48:09 -0700 (PDT)
Received: by 83.161.120.155 with SMTP id v3mr3781830wai.32.1242362889751;
        Thu, 14 May 2009 21:48:09 -0700 (PDT)
Received: from ?83.161.120.155? (tomcat.premedia.co.nz [83.161.120.155])
        by mx.google.com with ESMTPS id n33sm902071wag.21.283.161.120.155.48.07
        (version=SSLv3 cipher=RC4-MD5);
        Thu, 14 May 2009 21:48:08 -0700 (PDT)
Message-ID: <peterbradley@example.com>
Date: Fri, 15 May 2009 16:48:00 +1200
From: Jonathan Giles <peterbradley@example.com>
Reply-To: peterbradley@example.com
User-Agent: Thunderbird 83.161.120.155 (Windows/20090302)
MIME-Version: 1.0
To: Charles Matthew Chen <peterbradley@example.com>
CC: peterbradley@example.com
Subject: Re: Sanselan issue, with patch
References: <peterbradley@example.com> <peterbradley@example.com>
In-Reply-To: <peterbradley@example.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Hello,

Sorry for the delayed response - I have been away for some time and 
unable to afford the time to respond.

In addition to the patch proposed below, I have another few suggestions 
I would recommend for Sanselan. At present I am running my own patched 
version of Sanselan until (hopefully) these can be integrated. The 
suggestions / patches are:

 * Add equals() / hashcode() methods to IPTCType and IPTCRecord.

 * In JpefImageParser, change getPhotoshopMetadata() so that instead of 
doing the following:
        photoshopApp13Data = data;
in the loop, I suggest doing the following:
        records.addAll(data.getRecords());
        rawBlocks.addAll(data.getRawBlocks());
This suggestion requires a little bit more rejigging of the code, but 
once done, it has the effect of merging the IPTC segments, which in my 
use cases works. Prior to this change, I was in some circumstances not 
getting the results I was wanting. Since this change, I have noticed no 
regressions in my testing.

Cheers,
Jonathan

Charles Matthew Chen wrote:
> Hi Jonathan,
>
>    Sorry for the delay reply.  Thanks for looking into this issue and
> contributing a patch.  This is a known issue - there seems to be a
> large amount of variation in how some IPTC data is encoded.  The
> possible problem with continuing after find an unknown marker in IPTC
> data is that subsequent data might be invalid.  I'll look into this
> issue more when I get a chance.  In the meantime, can you please open
> an issue in JIRA and contribute (by attaching it to the issue) a
> sample image that demonstrates this issue?
>
> https://issues.apache.org/jira/browse/SANSELAN
>
> Thanks,
>    Matthew
>
>
> On Thu, Apr 30, 2009 at 5:10 PM, Jonathan Giles <peterbradley@example.com> wrote:
>   
>> Hi all,
>>
>> I'm using Sanselan to extract IPTC metadata. Recently I was given an image
>> that was causing Sanselan to return an empty set when retrieving the
>> metadata, despite the fact that there is clearly iptc metadata in the image.
>>
>> I trawled through the Sanselan code and found the problem: it's in
>> IPTCParser.parseIPTCBlock(...), and is the second 'if' statement within the
>> while loop. In particular, instead of the following:
>> if (tagMarker != IPTC_RECORD_TAG_MARKER) {
>>   if (verbose) {
>>       System.out.println("Unexpected record tag marker in IPTC data.");
>>   }
>>   return elements;
>> }
>>
>> You should do the following:
>> if (tagMarker != IPTC_RECORD_TAG_MARKER) {
>>   if (verbose) {
>>       System.out.println("Unexpected record tag marker in IPTC data.");
>>   }
>>   continue;
>> }
>>
>> In my case, this was tripping up the continued parsing of the image, as it
>> was occuring early in the parsing process. If you're interested, the verbose
>> output of an attempt to parse this file once the little patch above is
>> applied is shown below. In particular, look at the 'Unexpected record tag
>> marker in IPTC data.' midway down. I don't know what these values are, and I
>> am slightly concerned that I may be throwing away good data. Do you have any
>> thoughts?
>>
>> Cheers,
>> Jonathan Giles
>>
>> Output of verbose run after patch was applied:
>> ==============================
>> blockType 1002 (0x3ea)
>> blockSize 6143 (0x17ff)
>> blockType 1005 (0x3ed)
>> blockSize 16 (0x10)
>> blockType 1062 (0x426)
>> blockSize 14 (0xe)
>> blockType 1037 (0x40d)
>> blockSize 4 (0x4)
>> blockType 1049 (0x419)
>> blockSize 4 (0x4)
>> blockType 1011 (0x3f3)
>> blockSize 9 (0x9)
>> blockType 1034 (0x40a)
>> blockSize 1 (0x1)
>> blockType 10000 (0x2710)
>> blockSize 10 (0xa)
>> blockType 1013 (0x3f5)
>> blockSize 72 (0x48)
>> blockType 1016 (0x3f8)
>> blockSize 112 (0x70)
>> blockType 1032 (0x408)
>> blockSize 16 (0x10)
>> blockType 1054 (0x41e)
>> blockSize 4 (0x4)
>> blockType 1050 (0x41a)
>> blockSize 837 (0x345)
>> blockType 1064 (0x428)
>> blockSize 12 (0xc)
>> blockType 1044 (0x414)
>> blockSize 4 (0x4)
>> blockType 1036 (0x40c)
>> blockSize 6151 (0x1807)
>> blockType 1057 (0x421)
>> blockSize 85 (0x55)
>> blockType 1030 (0x406)
>> blockSize 7 (0x7)
>> blockType 1028 (0x404)
>> blockSize 1136 (0x470)
>> tagMarker 28 (0x1c)
>> recordNumber 1 (0x1)
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 2 (0x2)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 4 (0x4)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 28 (0x1c)
>> recordNumber 1 (0x1)
>> tagMarker 90 (0x5a)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 0 (0x0)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 3 (0x3)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 27 (0x1b)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 37 (0x25)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 71 (0x47)
>> Unexpected record tag marker in IPTC data.
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 0 (0x0)
>> ignore record version record! 0
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 5 (0x5)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 25 (0x19)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 40 (0x28)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 55 (0x37)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 80 (0x50)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 85 (0x55)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 103 (0x67)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 105 (0x69)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 110 (0x6e)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 120 (0x78)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 122 (0x7a)
>> tagMarker 28 (0x1c)
>> recordNumber 2 (0x2)
>> recordType 22 (0x16)
>>
>>     

From sanselan-dev-returnpeterbradley@example.com Thu May 21 19:42:55 2009
Return-Path: <sanselan-dev-returnpeterbradley@example.com>
Delivered-To: peterbradley@example.com
Received: (qmail 88689 invoked from network); 21 May 2009 19:42:55 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 21 May 2009 19:42:55 -0000
Received: (qmail 94903 invoked by uid 500); 21 May 2009 19:43:08 -0000
Delivered-To: peterbradley@example.com
Received: (qmail 94858 invoked by uid 500); 21 May 2009 19:43:08 -0000
Mailing-List: contact peterbradley@example.com; run by ezmlm
Precedence: bulk
List-Help: <mailto:peterbradley@example.com>
List-Unsubscribe: <mailto:peterbradley@example.com>
List-Post: <mailto:peterbradley@example.com>
List-Id: <sanselan-dev.incubator.apache.org>
Reply-To: peterbradley@example.com
Delivered-To: mailing list peterbradley@example.com
Received: (qmail 94848 invoked by uid 99); 21 May 2009 19:43:08 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 May 2009 19:43:08 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 May 2009 19:43:05 +0000
Received: from brutus (localhost [83.161.120.155])
	by brutus.apache.org (Postfix) with ESMTP id 851AC234C004
	for <peterbradley@example.com>; Thu, 21 May 2009 12:42:45 -0700 (PDT)
Message-ID: <1593053667.1242934965530.JavaMail.jira@brutus>
Date: Thu, 21 May 2009 12:42:45 -0700 (PDT)
From: "Jon Weygandt (JIRA)" <peterbradley@example.com>
To: peterbradley@example.com
Subject: [jira] Created: (SANSELAN-23)
 NullPointerException(Sanselan.java:323)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org

NullPointerException(Sanselan.java:323)
---------------------------------------

                 Key: SANSELAN-23
                 URL: https://issues.apache.org/jira/browse/SANSELAN-23
             Project: Sanselan
          Issue Type: Bug
            Reporter: Jon Weygandt


Static code analysis reveals that IccProfileParser.getICCProfileInfo can return a null value.

Sanselan.getICCProfile(line 323) uses info, which can be null, without checking for the value.

There is a test case in Shindig, JPEGOptimizerTest.testBadICC4, where the ICC count is too large. On some JVMs (like Sun) you get an OutOfMemory error, on other like IBM null is returned from getICCProfileInfo, resulting in a NPE.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



{'source': 'Apache Software Foundation Public Mail Archives'}