Re: [Imaging] Drop Serializable
+1 agree. On Thu, Aug 31, 2023, 9:29 AM Gary Gregory wrote: > Hi All, > > I propose we drop implementating Serializable and avoid any and all > possible security issues in this area. > > Gary >
Re: [ANNOUNCEMENT] Apache Commons Imaging 1.0-alpha3 Released
My next step will be to update the demonstration code from the Gridfour software package to use the new API. I'm also going to update the article on Elevation GeoTIFFs and Shaded Relief Rendering <https://gwlucastrig.github.io/GridfourDocs/notes/ElevationGeoTiff1.html> to reflect the improvements to the imaging parameters specification. Finally, I'm working on a new article to discuss how to access metadata from GeoTIFFs. So I'll be using the new Imaging library quite a bit. Gary L. On Thu, May 19, 2022 at 7:20 AM Bruno Kinoshita wrote: > You are very welcome Gary! De nada :) > > And thank you for all your hard work on this release too! Have fun parsing > the TIFF files now. Let's stabilize the API, make any final changes to the > public API, and prepare the 1.0 in a few months (I'm planning the 1.0 for > 2022). > > If I have time in the next coming weeks I will start some experiments with > Imaging 1.0-alpha3 using it in the Cantaloupe IIIF server and report the > results here in the dev mailing list. > > Bruno > > On Thu, 19 May 2022 at 23:03, Gary Lucas wrote: > > > Obrigado, Bruno! I appreciate all of the careful work you put into this > > release. > > > > Gary > > > > > > On Thu, May 19, 2022 at 3:56 AM Bruno Kinoshita > wrote: > > > > > The Apache Commons Team is pleased to announce the availability of > > > Apache Commons Imaging 1.0-alpha3. > > > > > > Apache Commons Imaging, previously known as Apache Commons Sanselan, > > > is a library that reads and writes a variety of image formats, > including > > > fast parsing of image info (size, color space, ICC profile, etc.) and > > > metadata. > > > > > > Version 1.0-alpha3 has a series of bug fixes, new features, and > > > improvements. > > > There are breaking changes since alpha2 as we are not maintaining > > backward > > > compatibility until it reaches the 1.0 release (likely the next > release). > > > > > > A full list of changes can be found at > > > https://commons.apache.org/proper/commons-imaging/changes-report.html > > > > > > Source and binary distributions are available for download from the > > > Apache Commons download site: > > > > > > https://commons.apache.org/proper/commons-imaging/download_imaging.cgi > > > > > > Please verify signatures using the KEYS file available at the above > > > location when downloading the release. > > > > > > For complete information on Commons Imaging, including > > > instructions on how to submit bug reports, patches, or suggestions for > > > improvement, see the Apache Commons Imaging website: > > > > > > https://commons.apache.org/proper/commons-imaging/ > > > > > > Bruno > > > on behalf of the Apache Commons community > > > > > >
Re: [ANNOUNCEMENT] Apache Commons Imaging 1.0-alpha3 Released
Obrigado, Bruno! I appreciate all of the careful work you put into this release. Gary On Thu, May 19, 2022 at 3:56 AM Bruno Kinoshita wrote: > The Apache Commons Team is pleased to announce the availability of > Apache Commons Imaging 1.0-alpha3. > > Apache Commons Imaging, previously known as Apache Commons Sanselan, > is a library that reads and writes a variety of image formats, including > fast parsing of image info (size, color space, ICC profile, etc.) and > metadata. > > Version 1.0-alpha3 has a series of bug fixes, new features, and > improvements. > There are breaking changes since alpha2 as we are not maintaining backward > compatibility until it reaches the 1.0 release (likely the next release). > > A full list of changes can be found at > https://commons.apache.org/proper/commons-imaging/changes-report.html > > Source and binary distributions are available for download from the > Apache Commons download site: > > https://commons.apache.org/proper/commons-imaging/download_imaging.cgi > > Please verify signatures using the KEYS file available at the above > location when downloading the release. > > For complete information on Commons Imaging, including > instructions on how to submit bug reports, patches, or suggestions for > improvement, see the Apache Commons Imaging website: > > https://commons.apache.org/proper/commons-imaging/ > > Bruno > on behalf of the Apache Commons community >
[VOTE] Release Apache Commons Imaging 1.0-alpha3 based on RC2
[x] +1 Release these artifacts Bruno, Thank you for all your hard work, your mad skills on github, and the excellent insights on the PR's that you reviewed. Gary (the other Gary)
Re: [imaging] Preparing vote for imaging-1-0-alpha3 (last alpha release)
My primary interest for Commons Imaging is using it to access geo-referenced TIFF file (GeoTIFF) . So far, it's worked out pretty well. The TIFF file format provides a flexible definition for attaching metadata to images. Back in the 1990's, the Geographic Information System (GIS) community started using a specification that allowed TIFF files to be overlaid on map displays. Nowadays, GeoTIFFs are supported by all the major GIS systems. While Imaging is useful for things like aerial photographs and satellite images, it also has the capability to carry numerical information. And there are some excellent, high-resolution elevation data sources available in TIFF format. I've been using the Commons Imaging API to access elevation grids with a 10-meter spacing from the U.S. Geological Survey (USGS), global elevation data sets from NASA's Shuttle Radar Topography Mission (SRTM) that has a 30-meter spacing, some European and Japanese sources, and high-resolution bathymetry products. Not all TIFF API's support access to that kind of data, but Commons Imaging does. And, personally, I think that Imaging is one of the easier-to-use libraries for accessing numerical data from TIFFs. Anyway, I am looking forward to seeing the alpha-3 release be available via the Maven Central Repository. Bruno has introduced some significant improvements to the API. Having them available via Maven will be a boon to the Java developer community. Thanks, Gary (the other Gary) On Thu, May 12, 2022 at 12:32 AM Bruno Kinoshita wrote: > Hi, > > We have fixed all the issues that were raised as blockers for 1.0 some > years ago (4? maybe 5 years ago?). I'm finishing the preparations for the > 1.0-alpha3 vote for Imaging. It's the last alpha release I have planned. > > I started working on Imaging when I became curious if we could use it as an > IIIF processor in Cantaloupe [1]. I never had time to try that, and instead > ended up spending a long time working on these issues for the 1.0 release. > Hoping now to use the alpha3 release with IIIF, fix any bugs I may find, > give users 6-12 months to send their feedback, and then cut 1.0 if there > are no blockers. > > I received feedback from users of Imaging that were able to use > alpha1/alpha2 in their Android apps, GIS solutions, simple web apps, and > even in visual arts with processing.org. Having the 1.0 in Maven should > allow a few more users/devs to use it. > > Cheers > Bruno > > [1] https://cantaloupe-project.github.io/manual/3.1/processors.html >
Re: [TEXT][IMAGING] Releases in May
Hey Bruno, Just checking in to see if there's anything I can do to help with the new Commons Imaging. I've looked at the latest changes in your personal fork of Imaging. I could do some stuff on the TIFF branch if you wanted. Gary On Fri, Apr 9, 2021 at 6:33 PM Bruno P. Kinoshita wrote: > Hi all, > > Family will be away in May/June for ~15 days, and I'm planning to use the > spare time these weeks to release Apache Commons Imaging 1.0-alpha3, and > Apache Commons Text 1.10. > I'm working with Gary Lucas on fixing the Hashmap parameters and replacing > them by a new object [1]. Gary has also a few more fixes in the work for > issues, especially related to TIFF image parsing. > And in Text, I have merged a fix for the Jaro Winkler distance [2]. Both > the Jaro Winkler similarity and the distance were returning the same > values. A user has contributed a PR fixing it, and I've added a few more > commits to fix the issue - binary compatibility kept. > If you have any more issues for Imaging/Text, just reply here and I'll > start reading the issues and slowly working on the fixes or reviewing code > to include in the next release. > > Bruno > > > > [1] https://github.com/apache/commons-imaging/pull/116 > [2] https://github.com/apache/commons-text/pull/214 > >
[IMAGING] Request comments on proposed new feature
I just posted a proposal on Jira for a newTIFF-file-writing class that will help Commons Imaging support the production of very large TIFF files. I am looking for comments about the design and requirements for the proposed feature. If you are interested, you may read more at https://issues.apache.org/jira/browse/IMAGING-271 Thanks, Gary (the other Gary)
Re: [VOTE] Release Apache Commons Imaging 1.0-alpha2 based on RC1
I successfully built the latest version of code using the following: Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T15:00:29-04:00) Maven home: C:\Users\gwluc\Documents\Applications\apache-maven-3.6.1\bin\.. Java version: 1.8.0_211, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_211\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" [x] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because...
Trouble submitting a patch
Damjan, I just submitted a new Tracker Item, #93, and a patch. Unfortunately, I don't seem to be able to find a control for granting a license. I'm going to Google a bit to see if I can figure it out. But I wanted to let you know in case you saw it before I was able to figure it out. Gary --- Gary W. Lucas, Senior Software Engineer Sonalysts, Inc 215 Parkway North Waterford, CT 06320 (860) 326-3682
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Apache Commons Imaging] Seeking ideas for performance improvements
I am making this post to the developers mailing list to see if anyone has ideas about areas in the Apache Commons Imaging project that would benefit from performance enhancements. Last year, I had a requirement through my job to support TIFF images in Java. I selected the Apache Imaging package (which was called Sanselan at the time) because it offered a pure Java solution and avoided the hassles associated with the Java Advanced Imaging add-on. Since then, I've put in some of my own time polishing up the image-reading operations to improve the speed of rendering. I've had some success and was wondering if there were other file formats supported by Apache Imaging that might benefit from similar attention. Of course, the situation for TIFF is a little different from that of the more mainstream formats such as JPEG, PNG, and GIF which are directly supported by image ImageIO.I'd be less inclined to work on formats that already have good support, but if there were special requirements that could be addressed through Apache Imaging I'd be willing to take a look at them. Just to give a sense of what's possible, consider the speed improvements to the TIFF format. This morning, I used a test application called ApacheImagingSpeedAndMemory from the Apache Imaging code distribution to run time trials on the original Sanselan 0.97 incubation version of Apache Imaging and the lastest code trunk. For a largish 10,000 by 10,000 pixel image, the original version required 15.9 seconds and used 679.8 megabytes of memory to load the image. The new version required 1.9 seconds and used 383.2 megabytes. For a smaller 3,600-by-1,800 pixel image, the load times were reduced from 0.89 seconds to 0.095.I wish I could say that I did something really cool to get these improvements, but the truth is that it was just old-fashioned coding and recognizing areas where redundant processing could be avoided. Anyway, I don't have a huge amount of free time to throw at this project, but if anyone comes up with an interesting idea, I might be willing to give it a shot. Gary Computer Programming is the Art of the Possible Gary W. Lucas, Senior Software Engineer 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?
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@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 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?
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 params = new HashMap();
// 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@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 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[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)
[sanselan] Comments on next release
I see there's some discussion about the next release of Sanselan between Damjan Jovanovic, Gary Gregory (I'm the other Gary) and some of the Apache community leaders. My name was even mentioned... so I thought I'd chime in. First off, Damjan posted a note to the issue tracker that my submitted patches for performance enhancements aren't going to make it into the 1.0 release. While I'm naturally disappointed about that, I can understand the perspective that it is probably the best choice at this time. Also, a delay would give us more time to refine the concept before we start applying it to other areas of the code. The only point I would add here is that I think Sanselan does have problems with performance and that those problems are really unnecessary. Java is plenty fast nowadays and there's nothing wrong with the Sanselan code per se, just a rather an unlucky choice on which API element to use for setting pixel values in an image. I think that the kind of changes proposed for one small area of the code base (TIFF images) would have applicability to other parts of the code. I also think that performance is probably one of the issues might keep Sanselan from reaching a broader user base. So I'd encourage everyone interested in Sanselan development to keep that in mind for future releases. In terms of renaming the project from "Sanselan" to "Image" or something like that. Well, I think the key issue here is that the change in name would signal a much more ambitious concept of what the project is for. To me, the name Sanselan says "I'm a small and unassuming software package focused on a particular niche application." The name "Image" or something like that says "I'm gunning for the JAI, and it's high time somebody did it too". I wonder if the reason that the original authors chose the obscure name was that their intentions were fairly modest, though with the amount of work that went into Sanselan it seems a shame not to promote it. So I'm strictly on the fence about the whole name change thing. Finally, I wanted to ask if there would be any problems in changing the compiler targets in the pom.xml to 1.5 for release 1.0. The current compiler targets are set up to compile with Java 1.4 features, but I just switched them to 1.5 and everything build and tested without errors. I'm not proposing that anyone go make code changes to Sanselan so that it uses generics or other 1.5 fixtures. Just compile the current code to accommodate 1.5 rather than being stuck in the 1.4 feature set. By switching release 1.0 to Java 1.5 does have the advantage that in any new work, coders will be able to use 1.5 without compatibility issues. Gary Computer Programming is the Art of the Possible Gary W. Lucas Sonalysts, Inc. 215 Parkway North Waterford, CT 06385
[sanselan] Question about another change to improve loading speed of TIFF images
Could someone give me some direction on how to handle an Sanselan Issue Tracker issue? I've found a change to the DataReaderStrips.java class that reduces the loading time of most uncompressed TIFF images to 1/5th of the load time required for the current implementation. I've run the suite of test images in the Sanselan sample and have verified that all of them are handled correctly and all of them realize this benefit in loading speed. I would like to submit a Tracker Issue for this change. I would also like to upload a patch. and this is where the issue comes in. The code change builds on a file, DataReaderStrips.java that I have already changed in an earlier patch SANSELAN-56. Do I submit a patch with just the one file? 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)
[sanselan] Question about submitting patches
I have just submitted two patches to the Sanselan code tree. These address issues a byte-order bug (Sanselan issue #54) and a speed enhancement (Sanselan issue #56).I uploaded the patches as attachments to their associated issues. Since I am new to using Subversion and the JIRA issue tracker, I am a bit concerned that I may not have submitted the changes correctly. If someone has the time to verify that they were entered into the system correctly, I'd be grateful. The speed enhancement reduces the load time for TIFF images by about 40 percent. I believe that the same techniques could be used for some of the other, more popular, image formats. So far I focused on TIFF images because that was the particular format I needed for my application. If anyone thinks that this is worth pursuing for other image types, I am open to suggestions on where to start. On another note, when I was looking at maven (something else to which I am new) I did not see a target for creating javadoc files. Does this need to be added to the pom.xml file? 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] Question about Java coding style for sanselan project
Gary, Thanks for the tip on the POM... I would have spent a lot of time looking for that. I don't absolutely have to use generics, but it is kind of the way things are trending these days. I'll wait and see what the community has to say about it. g. -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Friday, September 30, 2011 2:19 PM To: Commons Developers List Subject: Re: [sanselan] Question about Java coding style for sanselan project Hello Gary(!): The project POM defines: 1.4 1.4 Java 1.4 is the current requirement. Using generics would mean bumping the requirements of the project to Java 5. I do not know enough about the project to know if this is acceptable. Seems OK to me though. I am not sure who on this ML knows this project well enough either, so speak up ML. No revision comments. That's what SVN is for. Cheers, Gary On Fri, Sep 30, 2011 at 1:32 PM, Gary Lucas wrote: > I am working on a couple of patches for sanselan. These involve about > a couple of dozen files. I had two questions about coding style: > > First question: Is it okay to use generics for collections? These are > a Java 1.5 element and I've noticed a couple of comments on the project page > mentioning support for 1.4. I suspect that consideration is now obsolete > since Java is now into version 1.7. > > Second question: Does anyone have preferences/guidelines for including > "revision history" or "change log" information in the comments? At the > present time, the sanselan code is practically without any comments at > all, so I don't have any examples. I can see an argument for not > including change log comments in a file because the subversion system > maintains information about change histories. I can also see an > argument for including them because a list of short, informative > change notes at the top of a file can save a lot of time in the middle > of a debugging session, especially in those times when one doesn't > have access to the Internet > > Here's a strawman for a change log. I would put these in the code > right below the Apache copyright information which appears at the top > of all sanselan code files. > > > /* > - > * > * Revision History: > * > * Date Name Description > * -- - > --- > * --/ Sanselan Sanselan 0.97 baseline (author unknown) > * 09/2011 G. Lucas Fix byte-order issue in double arrays for EXIF > tags > > > *- > - > * Notes: > > > *- > - > */ > > > Computer Programming is the Art of the Possible Gary W. Lucas > Sonalysts, Inc. > 215 Parkway North > Waterford, CT 06385 > 41-22-12.35 N / 72-10-07.54 W (USNG/MGRS: 18T YL 36787 83711) > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[sanselan] Question about Java coding style for sanselan project
I am working on a couple of patches for sanselan. These involve about a couple of dozen files. I had two questions about coding style: First question: Is it okay to use generics for collections? These are a Java 1.5 element and I've noticed a couple of comments on the project page mentioning support for 1.4. I suspect that consideration is now obsolete since Java is now into version 1.7. Second question: Does anyone have preferences/guidelines for including "revision history" or "change log" information in the comments? At the present time, the sanselan code is practically without any comments at all, so I don't have any examples. I can see an argument for not including change log comments in a file because the subversion system maintains information about change histories. I can also see an argument for including them because a list of short, informative change notes at the top of a file can save a lot of time in the middle of a debugging session, especially in those times when one doesn't have access to the Internet Here's a strawman for a change log. I would put these in the code right below the Apache copyright information which appears at the top of all sanselan code files. /*- * * Revision History: * * Date Name Description * -- - --- * --/ Sanselan Sanselan 0.97 baseline (author unknown) * 09/2011 G. Lucas Fix byte-order issue in double arrays for EXIF tags *-- * Notes: *-- */ Computer Programming is the Art of the Possible Gary W. Lucas Sonalysts, Inc. 215 Parkway North Waterford, CT 06385 41-22-12.35 N / 72-10-07.54 W (USNG/MGRS: 18T YL 36787 83711) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Sanselan] Question about and proposed change for writing metadata (EXIF) tag to TIFF files
I've been trying to implement code to write GeoTIFF tags to TIFF files. I was unable to find any code examples or documentation for this operation, but after digging through the code, it looks like the TiffImageWriterLossy and TiffImageWriterLossless classes may be the place to do this. TiffImageWriterLossy gets invoked by the Sanselan.writeImage method. First off, before I get in to this, it appears to me that the use of the terms Lossy and Lossless is a little unusual (since it has nothing to do with data compression or signal processing) in that Lossy means that it overwrites any existing files and data, Lossless means that it preserves existing data (making small but important adjustments to internal offset values).Is this a correct interpretation? Now, as far as I can tell, the TiffImageWriterLossless is supposed to allow an application to add EXIF tags to a TIFF file after it is initially written. TiffImageWriterLossless is invoked from the ExifRewriter class and apparently it operates by making a copy of an existing file and adding additionally EXIF tags to the file. The puzzling thing here is that although ExifRewriter includes references to TiffImageWriterLossless, ExifRewriter is actually in a package called "jpegRewrite".Furthermore, in many, many attempts to get the ExifRewriter to write to TIFF files, it appears to not work on TIFF files (it consistently throws exceptions warning that the file header is not a valid JPEG header). So my questions are as follows. Is the ExifRewriter intended to work on TIFF files? I have studied the TIFF file format, but don't know much about JPEG. If they were structurally similar, I guess that the ExifRewriter in the jpegRewrite package might be intended to do double duty for different formats. But it doesn't look like that's how it works. If ExifWriter really can't write TIFF files, is there any way to write application-defined tags to TIFF files? Anyway, I would like to propose a change to Sanselan based on something I've done strictly for my own work. I'd like to see if folks with more experience with the code base than I have would think it a good idea. What I did was to change the TiffImageWriterBase class (the parent of TiffImageWriterLossy) to add another variation of the writeImage method. The new method takes an array list of TiffOutputFields, and when it writes the initial TIFF Image File Directory (represented by the TiffOuputDirectory class) it adds the application-defined tags to the output. Thus, the output TIFF file with custom EXIF tags only needs to be written once and only includes one directory. Does anyone have comments on whether this is a good idea or not? Gary P.S. One last question. I notice that Java generics are not used in Sanselan. I even found a comment in the code where the author apologized for using methods from the Java 1.5 API. Is there a coding standard that restricts the use of language elements in Sanselan? --- Gary W. Lucas, Senior Software Engineer Sonalysts, Inc 215 Parkway North Waterford, CT 06320 (860) 326-3682
