You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Lucas <gw...@sonalysts.com> on 2012/04/25 22:30:09 UTC
[sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
I'm taking a stab at transitioning from Sanselan to the new Apache Imaging. One thing I've noticed is that one of the EXIF tags my existing software uses seems to have been removed from imaging:
public static final TagInfo EXIF_TAG_MODIFY_DATE = new TagInfo(
"Modify Date", 0x0132, FIELD_TYPE_ASCII, 1, EXIF_DIRECTORY_IFD0);
I'm not familiar with the details behind this tag. Was it removed because it is obsolete or non-standard? An oversight?
Thanks.
Gary
Computer Programming is the Art of the Possible
Gary W. Lucas
Sonalysts, Inc.
215 Parkway North
Waterford, CT 06385
(860) 326-3682
41-22-12.35 N / 72-10-07.54 W (USNG/MGRS: 18T YL 36787 83711)
Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
Posted by Damjan Jovanovic <da...@gmail.com>.
Not your last one, the one before. It ends with:
"One question. When I"
and there's nothing after it.
On Thu, Apr 26, 2012 at 2:31 PM, Gary Lucas <gw...@sonalysts.com> wrote:
> Excellent again! Much better.
>
> I'm not sure how that last email got cut short, but you've answered my question. So thanks.
>
>
>
> g.
>
>
>
> -----Original Message-----
> From: Damjan Jovanovic [mailto:damjan.jov@gmail.com]
> Sent: Thursday, April 26, 2012 8:26 AM
> To: Commons Developers List
> Subject: Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
>
> On Thu, Apr 26, 2012 at 2:16 PM, Gary Lucas <gw...@sonalysts.com> wrote:
>>
>> Since we're on the subject, another question. In encoding data, I was
>> constructing field types and coding the information. But it looks
>> like you've got some static declarations for doing the same thing.
>> Could you verify that the following is your intended approach
>>
>> public TiffOutputField encodeASCII(TagInfo tInfo, String string)
>> throws ImageWriteException, ImageWriteException
>> {
>> // previous approach:
>> // FieldType fType = new FieldTypeAscii(2, "ASCII");
>> // byte bytes[] = fType.writeData(string, byteOrder);
>>
>> byte bytes[] = FieldType.FIELD_TYPE_ASCII.writeData(string,
>> byteOrder);
>>
>> TiffOutputField tiffOutputField =
>> new TiffOutputField(
>> tInfo.tag,
>> tInfo,
>> FieldType.FIELD_TYPE_ASCII,
>> bytes.length,
>> bytes);
>> return tiffOutputField;
>> }
>
> Do your emails keep getting cut short?
>
> The easiest way, for a known tag type, is:
>
> tiffOutputDirectory.add(TiffTagConstants.TIFF_TAG_DATE_TIME,
> "2012-04-25 01:23:45");
>
> which supports IDE code completion, and automatically overloads to the correct method based on the tag type.
>
> For an unknown tag type, I think you have to use the old way where you construct a TiffOutputField yourself.
>
> Damjan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging
package?
Posted by Gary Lucas <gw...@sonalysts.com>.
Excellent again! Much better.
I'm not sure how that last email got cut short, but you've answered my question. So thanks.
g.
-----Original Message-----
From: Damjan Jovanovic [mailto:damjan.jov@gmail.com]
Sent: Thursday, April 26, 2012 8:26 AM
To: Commons Developers List
Subject: Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
On Thu, Apr 26, 2012 at 2:16 PM, Gary Lucas <gw...@sonalysts.com> wrote:
>
> Since we're on the subject, another question. In encoding data, I was
> constructing field types and coding the information. But it looks
> like you've got some static declarations for doing the same thing.
> Could you verify that the following is your intended approach
>
> public TiffOutputField encodeASCII(TagInfo tInfo, String string)
> throws ImageWriteException, ImageWriteException
> {
> // previous approach:
> // FieldType fType = new FieldTypeAscii(2, "ASCII");
> // byte bytes[] = fType.writeData(string, byteOrder);
>
> byte bytes[] = FieldType.FIELD_TYPE_ASCII.writeData(string,
> byteOrder);
>
> TiffOutputField tiffOutputField =
> new TiffOutputField(
> tInfo.tag,
> tInfo,
> FieldType.FIELD_TYPE_ASCII,
> bytes.length,
> bytes);
> return tiffOutputField;
> }
Do your emails keep getting cut short?
The easiest way, for a known tag type, is:
tiffOutputDirectory.add(TiffTagConstants.TIFF_TAG_DATE_TIME,
"2012-04-25 01:23:45");
which supports IDE code completion, and automatically overloads to the correct method based on the tag type.
For an unknown tag type, I think you have to use the old way where you construct a TiffOutputField yourself.
Damjan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
Posted by Damjan Jovanovic <da...@gmail.com>.
On Thu, Apr 26, 2012 at 2:16 PM, Gary Lucas <gw...@sonalysts.com> wrote:
>
> Since we're on the subject, another question. In encoding data, I was constructing field types and coding the information. But it looks like you've got some static declarations for doing the same thing. Could you verify that the following is your intended approach
>
> public TiffOutputField encodeASCII(TagInfo tInfo, String string)
> throws ImageWriteException, ImageWriteException
> {
> // previous approach:
> // FieldType fType = new FieldTypeAscii(2, "ASCII");
> // byte bytes[] = fType.writeData(string, byteOrder);
>
> byte bytes[] = FieldType.FIELD_TYPE_ASCII.writeData(string, byteOrder);
>
> TiffOutputField tiffOutputField =
> new TiffOutputField(
> tInfo.tag,
> tInfo,
> FieldType.FIELD_TYPE_ASCII,
> bytes.length,
> bytes);
> return tiffOutputField;
> }
Do your emails keep getting cut short?
The easiest way, for a known tag type, is:
tiffOutputDirectory.add(TiffTagConstants.TIFF_TAG_DATE_TIME,
"2012-04-25 01:23:45");
which supports IDE code completion, and automatically overloads to the
correct method based on the tag type.
For an unknown tag type, I think you have to use the old way where you
construct a TiffOutputField yourself.
Damjan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging
package?
Posted by Gary Lucas <gw...@sonalysts.com>.
Since we're on the subject, another question. In encoding data, I was constructing field types and coding the information. But it looks like you've got some static declarations for doing the same thing. Could you verify that the following is your intended approach
public TiffOutputField encodeASCII(TagInfo tInfo, String string)
throws ImageWriteException, ImageWriteException
{
// previous approach:
// FieldType fType = new FieldTypeAscii(2, "ASCII");
// byte bytes[] = fType.writeData(string, byteOrder);
byte bytes[] = FieldType.FIELD_TYPE_ASCII.writeData(string, byteOrder);
TiffOutputField tiffOutputField =
new TiffOutputField(
tInfo.tag,
tInfo,
FieldType.FIELD_TYPE_ASCII,
bytes.length,
bytes);
return tiffOutputField;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: My vote for release
Posted by sebb <se...@gmail.com>.
On 1 August 2012 18:09, Becksfort, Jared <Ja...@stjude.org> wrote:
> Gary,
>
> I have wondered about the public scoping of arrays myself for that same reason. I also write image processing code, and the arrays can be quite large, especially if the processing is in three dimensions.
A public get method that returns the array itself is not useful, but
one can write a get(int entry) method that makes the array read-only.
In an optimising compiler the code will likely be inlined to be no
less efficient than direct access.
The array-clone approach can also be useful, depending on the application.
Mutable public data makes thorough testing much harder, as well as all
the potential security and threading issues.
> Jared
>
> -----Original Message-----
> From: Gary Lucas [mailto:gwlucas@sonalysts.com]
> Sent: Wednesday, August 01, 2012 12:01 PM
> To: 'Commons Developers List'
> Subject: My vote for release
>
>
> Damjan,
>
> I just saw that you were soliciting votes for release. I think you've done an outstanding job and I'm all for it. I would vote twice if I could :-)
>
> I saw that some of the folks on the Apache page were complaining about some of the code-checking issues. I've never looked at these myself, but I suppose that many of them are not worth fixing.
>
> For example, somebody complained that a class shouldn't have a publically scoped array. Let's say a programmer tried to address that. If he writes a "get" method that is a simple pass-through returning a reference to the internal array, has he really added any security (meaning protection against accidental misuse)? Of course not. Suppose, instead, that he writes a method that makes a copy of the array before returning it. Now he's improved security, but degraded the performance of the overall code... maybe seriously. And in imaging processing, performance trumps security almost every time.
>
> Anyway, if there are specific areas in the TIFF tree or elsewhere that you would like me to review, please let me know and I'll be glad to take a look at them.
>
> Gary
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> Email Disclaimer: www.stjude.org/emaildisclaimer
> Consultation Disclaimer: www.stjude.org/consultationdisclaimer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: My vote for release
Posted by "Becksfort, Jared" <Ja...@STJUDE.ORG>.
Gary,
I have wondered about the public scoping of arrays myself for that same reason. I also write image processing code, and the arrays can be quite large, especially if the processing is in three dimensions.
Jared
-----Original Message-----
From: Gary Lucas [mailto:gwlucas@sonalysts.com]
Sent: Wednesday, August 01, 2012 12:01 PM
To: 'Commons Developers List'
Subject: My vote for release
Damjan,
I just saw that you were soliciting votes for release. I think you've done an outstanding job and I'm all for it. I would vote twice if I could :-)
I saw that some of the folks on the Apache page were complaining about some of the code-checking issues. I've never looked at these myself, but I suppose that many of them are not worth fixing.
For example, somebody complained that a class shouldn't have a publically scoped array. Let's say a programmer tried to address that. If he writes a "get" method that is a simple pass-through returning a reference to the internal array, has he really added any security (meaning protection against accidental misuse)? Of course not. Suppose, instead, that he writes a method that makes a copy of the array before returning it. Now he's improved security, but degraded the performance of the overall code... maybe seriously. And in imaging processing, performance trumps security almost every time.
Anyway, if there are specific areas in the TIFF tree or elsewhere that you would like me to review, please let me know and I'll be glad to take a look at them.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: My vote for release
Posted by Damjan Jovanovic <da...@gmail.com>.
On Wed, Aug 1, 2012 at 7:00 PM, Gary Lucas <gw...@sonalysts.com> wrote:
>
> Damjan,
>
> I just saw that you were soliciting votes for release. I think you've done an outstanding job and I'm all for it. I would vote twice if I could :-)
>
> I saw that some of the folks on the Apache page were complaining about some of the code-checking issues. I've never looked at these myself, but I suppose that many of them are not worth fixing.
>
> For example, somebody complained that a class shouldn't have a publically scoped array. Let's say a programmer tried to address that. If he writes a "get" method that is a simple pass-through returning a reference to the internal array, has he really added any security (meaning protection against accidental misuse)? Of course not. Suppose, instead, that he writes a method that makes a copy of the array before returning it. Now he's improved security, but degraded the performance of the overall code... maybe seriously. And in imaging processing, performance trumps security almost every time.
>
> Anyway, if there are specific areas in the TIFF tree or elsewhere that you would like me to review, please let me know and I'll be glad to take a look at them.
>
> Gary
Thank you. I've fixed the worst problems, and I plan on trying to
release RC3 in a few days.
I doubt those public array scoping will stop the release, and I plan
on making big changes to the whole API for Imaging version 2.0 so
we'll see then.
Regards
Damjan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
My vote for release
Posted by Gary Lucas <gw...@sonalysts.com>.
Damjan,
I just saw that you were soliciting votes for release. I think you've done an outstanding job and I'm all for it. I would vote twice if I could :-)
I saw that some of the folks on the Apache page were complaining about some of the code-checking issues. I've never looked at these myself, but I suppose that many of them are not worth fixing.
For example, somebody complained that a class shouldn't have a publically scoped array. Let's say a programmer tried to address that. If he writes a "get" method that is a simple pass-through returning a reference to the internal array, has he really added any security (meaning protection against accidental misuse)? Of course not. Suppose, instead, that he writes a method that makes a copy of the array before returning it. Now he's improved security, but degraded the performance of the overall code... maybe seriously. And in imaging processing, performance trumps security almost every time.
Anyway, if there are specific areas in the TIFF tree or elsewhere that you would like me to review, please let me know and I'll be glad to take a look at them.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging
package?
Posted by Gary Lucas <gw...@sonalysts.com>.
Excellent idea. Thanks.
Our application uses a modified version of Sanselan that includes my performance enhancements. I've started swapping that out with the latest from Apache Imaging, again with my latest two patches for speed improvements. On the read side, it went very quickly. On the write side, I'm still trying to get things working. Although the API is definitely a lot cleaner than the original, I'm not sure I've figured it out yet.
Here's a snippet of code I'm using to write a GeoTIFF file. Would you take a look and make sure I am doing the right thing (particularly in the constructor for the TiffOutputDirectory)? The fieldList is a set of output fields that were populated by a utility routine. That approach is a hold-over from the Sanselan implementation (is there a better way to do it?). I add them to an output directory, bundle the directory in an output set, and pass the output set into the lossy writer as a parameter.
HashMap<String, Object> params = new HashMap<String, Object>();
// set optional parameters if you like
params.put(ImagingConstants.PARAM_KEY_COMPRESSION,
new Integer(TiffConstants.TIFF_COMPRESSION_UNCOMPRESSED));
// tiffByteOrder set as appropriate for system
// fieldList is an array list of TiffOutputFields that
// was set by a utility class.
TiffImageWriterLossy lWriter =
new TiffImageWriterLossy(tiffByteOrder);
TiffOutputDirectory tiffDirectory = new TiffOutputDirectory(
TiffDirectoryConstants.DIRECTORY_TYPE_DIR_0, tiffByteOrder);
for (TiffOutputField field : fieldList) {
tiffDirectory.add(field);
}
TiffOutputSet tiffOutputSet = new TiffOutputSet();
tiffOutputSet.addDirectory(tiffDirectory);
params.put(ImagingConstants.PARAM_KEY_EXIF, tiffOutputSet);
FileOutputStream fos = new FileOutputStream(outputFile);
BufferedOutputStream bos = new BufferedOutputStream(fos);
lWriter.writeImage(outputImage, bos, params);
bos.flush();
bos.close();
fos.close();
One question. When I
-----Original Message-----
From: Damjan Jovanovic [mailto:damjan.jov@gmail.com]
Sent: Thursday, April 26, 2012 12:02 AM
To: Commons Developers List
Subject: Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
On Wed, Apr 25, 2012 at 10:30 PM, Gary Lucas <gw...@sonalysts.com> wrote:
> I'm taking a stab at transitioning from Sanselan to the new Apache Imaging. One thing I've noticed is that one of the EXIF tags my existing software uses seems to have been removed from imaging:
>
> public static final TagInfo EXIF_TAG_MODIFY_DATE = new TagInfo(
> "Modify Date", 0x0132, FIELD_TYPE_ASCII, 1,
> EXIF_DIRECTORY_IFD0);
>
>
> I'm not familiar with the details behind this tag. Was it removed because it is obsolete or non-standard? An oversight?
>
> Thanks.
>
> Gary
One of the recent changes was deduplication of TIFF tags, and grouping of tags by specification.
Tag 0x0132 is defined in the TIFF6 specification, so it is now under TiffTagConstants, and known as TIFF_TAG_DATE_TIME.
Also I am considering replacing the EXIF_ prefix with TIFF_ for all tags.
Damjan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
Posted by Damjan Jovanovic <da...@gmail.com>.
On Wed, Apr 25, 2012 at 10:30 PM, Gary Lucas <gw...@sonalysts.com> wrote:
> I'm taking a stab at transitioning from Sanselan to the new Apache Imaging. One thing I've noticed is that one of the EXIF tags my existing software uses seems to have been removed from imaging:
>
> public static final TagInfo EXIF_TAG_MODIFY_DATE = new TagInfo(
> "Modify Date", 0x0132, FIELD_TYPE_ASCII, 1, EXIF_DIRECTORY_IFD0);
>
>
> I'm not familiar with the details behind this tag. Was it removed because it is obsolete or non-standard? An oversight?
>
> Thanks.
>
> Gary
One of the recent changes was deduplication of TIFF tags, and grouping
of tags by specification.
Tag 0x0132 is defined in the TIFF6 specification, so it is now under
TiffTagConstants, and known as TIFF_TAG_DATE_TIME.
Also I am considering replacing the EXIF_ prefix with TIFF_ for all tags.
Damjan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org