Re: [imaging] Read/Write Bilevel TIFF A4 image thumbnail
The EXIF specification provides a way to create a TIFF image with a thumbnail. Regards Damjan On Sun, Mar 2, 2014 at 9:13 AM, Ramanathan Srinivasan wrote: > Greetings, > > > Is it possible to embed Thumbnail in bilevel TIFF A4 image? > If yes, any example or Link for the same > > Thanks, > srinivasan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [compress] Random access of SevenZFile
On Wed, Nov 13, 2013 at 3:18 PM, wrote: > On Wed, 13 Nov 2013 06:05:06 +0100 > Stefan Bodewig wrote: > >> On 2013-11-12, wrote: >> >> > The 7z file format is (supposedly) a random access format, much like >> > zip archives. However, The SevenZFile class seems to only expose a >> > sequential interface (where I'm expected to seek over entries one at a >> > time, presumably whilst unpacking files). >> >> Much like zip 7z has file metadata at the end of the archive, so yes, >> SevenZFile could build up a Map when opening the archive and provide >> random access. Actually it does collect the information of all entries >> (in Archive.files), only an API to use it for random access is missing. >> >> Things aren't all that bad, though. Repeatedly calling getNextEntry >> will create streams for each entry but not consume them - so the files >> are not unpacked while you iterate over the entries. >> >> Stefan > > Hello! > > I spent a bit of time yesterday implementing this; I build a HashMap of > names to SevenZArchiveEntry instances by iterating over all entries upon > archive loading. > > However, I'm having further problems actually obtaining streams to specific > entries. The only interface exposed by SevenZFile is a set of mostly > undocumented read() functions that don't state where the data comes from. > The documentation for the no-argument read() function states > "Read a byte of data". > > I'm assuming that the functions will actually read from the byte offset > in the file described by the most recent entry returned by getNextEntry(). > Unfortunately, given that there's apparently no way to seek, this seems to > imply that I can't do anything with a SevenZFile beyond sequentially > decompressing all entries in order. This makes it essentially useless for > my needs (writing an interactive archive management program). > > Am I missing something obvious here? > > M It is not possible to seek to an arbitrary file's contents in a 7z archive anyway, since 7z archives can use solid compression for some or all files, which means you potentially have to sequentially decompress some or all of the preceding files' contents to get to the contents of the one you want. Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [imaging] Plan for 1.0.0 release
Wow, that's a really good idea! Yes it's feasible. If you'd like to write and commit a patch for it, feel free. Damjan On Tue, Oct 22, 2013 at 9:23 PM, Matt Benson wrote: > If the API will be extensible, that's perhaps a different matter, although > in that case maybe the extensible part should be an interface implemented > by ImageFormat's constants. In this case we could convert ImageFormat to an > enum now and still make the API extensible later on. > > Does this sound feasible? > > Matt > > > On Tue, Oct 22, 2013 at 2:12 PM, Damjan Jovanovic wrote: > >> I would like to avoid an enum there for later versions because I'd >> like to make the API extensible with user-defined image formats, but >> we can add it for 1.0.0. >> >> Damjan >> >> On Tue, Oct 22, 2013 at 9:00 PM, Matt Benson wrote: >> > At some point I had had it in mind that ImageFormat should be converted >> to >> > a proper enum type. Can anyone offer any reasons this should not be >> done, >> > particularly before 1.0.0? >> > >> > Matt >> > >> > >> > On Tue, Oct 22, 2013 at 1:44 PM, Damjan Jovanovic > >wrote: >> > >> >> Yes I agree, we might as well release trunk as 1.0.0. I am fixing the >> >> last few bugs in Jira, and then let's get started with the release >> >> :-). Support would be appreciated. >> >> >> >> Damjan >> >> >> >> On Tue, Oct 22, 2013 at 8:19 PM, Raul Kripalani >> wrote: >> >> > Hello, >> >> > >> >> > @Gregory – many thanks for your input. You surely belong very valid >> >> points >> >> > to the discussion. >> >> > >> >> > The issue I see is that Apache Sanselan 0.97 has such a wide adoption >> in >> >> > the community that even in spite of the last public release being an >> >> > Incubator one, it has earned itself the status of a de-facto library >> for >> >> > image processing out there. It's quite mature and stable for the >> standard >> >> > use cases. IMHO, release 0.97 has the status and bearing of a release >> >> 1.0.0 >> >> > already. >> >> > >> >> > Want it or not, this means that you'll find yourself supporting the >> >> current >> >> > API baseline for quite some time ;-) Bear in mind that the Sanselan >> use >> >> > cases are typically quite static: once you've built your image >> processing >> >> > functionality into your app, it'll probably remain untouched for a >> long >> >> > time. So the user has some functional changes to make in your app, >> they >> >> > won't consider upgrading, let alone investing the effort to adapt >> their >> >> > code to an entirely new API just for the sake of it. >> >> > >> >> > So, in a nutshell, it seems adequate to publish the current trunk as >> >> > version 1.0.0, as folks are indeed already treating it as such out >> there. >> >> > >> >> > @Damjan – what's your take? I can support you these days if you >> decide to >> >> > push out 1.0.0 now! >> >> > >> >> > Regards, >> >> > >> >> > *Raúl Kripalani* >> >> > Apache Camel PMC Member & Committer | Enterprise Architect, Open >> Source >> >> > Integration specialist >> >> > http://about.me/raulkripalani | >> http://www.linkedin.com/in/raulkripalani >> >> > http://blog.raulkr.net | twitter: @raulvk >> >> > >> >> > On Mon, Oct 21, 2013 at 5:23 PM, Gary Gregory > >> >wrote: >> >> > >> >> >> On Mon, Oct 21, 2013 at 10:30 AM, Gary Gregory < >> garydgreg...@gmail.com >> >> >> >wrote: >> >> >> >> >> >> > On Mon, Oct 21, 2013 at 9:47 AM, Damjan Jovanovic < >> dam...@apache.org >> >> >> >wrote: >> >> >> > >> >> >> >> Well as the only committer that's really working on the >> internals, I >> >> >> >> am wondering what to do myself now. >> >> >> >> >> >> >> >> I've been working on (and have almost finished) a very large >> change >> >> >> >> affecting virtually everything. When I
Re: [imaging] Plan for 1.0.0 release
I would like to avoid an enum there for later versions because I'd like to make the API extensible with user-defined image formats, but we can add it for 1.0.0. Damjan On Tue, Oct 22, 2013 at 9:00 PM, Matt Benson wrote: > At some point I had had it in mind that ImageFormat should be converted to > a proper enum type. Can anyone offer any reasons this should not be done, > particularly before 1.0.0? > > Matt > > > On Tue, Oct 22, 2013 at 1:44 PM, Damjan Jovanovic wrote: > >> Yes I agree, we might as well release trunk as 1.0.0. I am fixing the >> last few bugs in Jira, and then let's get started with the release >> :-). Support would be appreciated. >> >> Damjan >> >> On Tue, Oct 22, 2013 at 8:19 PM, Raul Kripalani wrote: >> > Hello, >> > >> > @Gregory – many thanks for your input. You surely belong very valid >> points >> > to the discussion. >> > >> > The issue I see is that Apache Sanselan 0.97 has such a wide adoption in >> > the community that even in spite of the last public release being an >> > Incubator one, it has earned itself the status of a de-facto library for >> > image processing out there. It's quite mature and stable for the standard >> > use cases. IMHO, release 0.97 has the status and bearing of a release >> 1.0.0 >> > already. >> > >> > Want it or not, this means that you'll find yourself supporting the >> current >> > API baseline for quite some time ;-) Bear in mind that the Sanselan use >> > cases are typically quite static: once you've built your image processing >> > functionality into your app, it'll probably remain untouched for a long >> > time. So the user has some functional changes to make in your app, they >> > won't consider upgrading, let alone investing the effort to adapt their >> > code to an entirely new API just for the sake of it. >> > >> > So, in a nutshell, it seems adequate to publish the current trunk as >> > version 1.0.0, as folks are indeed already treating it as such out there. >> > >> > @Damjan – what's your take? I can support you these days if you decide to >> > push out 1.0.0 now! >> > >> > Regards, >> > >> > *Raúl Kripalani* >> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source >> > Integration specialist >> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani >> > http://blog.raulkr.net | twitter: @raulvk >> > >> > On Mon, Oct 21, 2013 at 5:23 PM, Gary Gregory > >wrote: >> > >> >> On Mon, Oct 21, 2013 at 10:30 AM, Gary Gregory > >> >wrote: >> >> >> >> > On Mon, Oct 21, 2013 at 9:47 AM, Damjan Jovanovic > >> >wrote: >> >> > >> >> >> Well as the only committer that's really working on the internals, I >> >> >> am wondering what to do myself now. >> >> >> >> >> >> I've been working on (and have almost finished) a very large change >> >> >> affecting virtually everything. When I commit it, the API will come >> >> >> apart at the seams :-/, and people will not be very happy with the >> >> >> rewrites of their own code they'll be doing. >> >> >> >> >> >> Which of the following would be best: >> >> >> 1. Releasing what is in SVN trunk now (maybe minus another API >> >> >> breaking change from a few months ago) as 1.0, then adding my large >> >> >> API-breaking change which will eventually be released as version 2.0. >> >> >> >> >> > >> >> > Remember that you'll have to change the package name and Maven >> >> coordinates >> >> > for 2.0. >> >> > >> >> >> >> The good news is that version 0.97 is in the old package name >> >> org.apache.sanselan. This means no jar hell for 1.0 >> >> (org.apache.commons.imaging) vs. 0.97. 1.0 which will co-exist with >> 0.97 in >> >> the same class loader. With option (1), upgrading from 0.97 to 1.0 will >> >> mean AT LEAST updating all package imports, not that bad. Make sure you >> >> write good release notes ;) >> >> >> >> Let me also offer a bit of perspective for your consideration. >> Releasing an >> >> option (1) 1.0 means supporting it to some extent on the ML and with >> >> po
Re: [imaging] Plan for 1.0.0 release
Yes I agree, we might as well release trunk as 1.0.0. I am fixing the last few bugs in Jira, and then let's get started with the release :-). Support would be appreciated. Damjan On Tue, Oct 22, 2013 at 8:19 PM, Raul Kripalani wrote: > Hello, > > @Gregory – many thanks for your input. You surely belong very valid points > to the discussion. > > The issue I see is that Apache Sanselan 0.97 has such a wide adoption in > the community that even in spite of the last public release being an > Incubator one, it has earned itself the status of a de-facto library for > image processing out there. It's quite mature and stable for the standard > use cases. IMHO, release 0.97 has the status and bearing of a release 1.0.0 > already. > > Want it or not, this means that you'll find yourself supporting the current > API baseline for quite some time ;-) Bear in mind that the Sanselan use > cases are typically quite static: once you've built your image processing > functionality into your app, it'll probably remain untouched for a long > time. So the user has some functional changes to make in your app, they > won't consider upgrading, let alone investing the effort to adapt their > code to an entirely new API just for the sake of it. > > So, in a nutshell, it seems adequate to publish the current trunk as > version 1.0.0, as folks are indeed already treating it as such out there. > > @Damjan – what's your take? I can support you these days if you decide to > push out 1.0.0 now! > > Regards, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Mon, Oct 21, 2013 at 5:23 PM, Gary Gregory wrote: > >> On Mon, Oct 21, 2013 at 10:30 AM, Gary Gregory > >wrote: >> >> > On Mon, Oct 21, 2013 at 9:47 AM, Damjan Jovanovic > >wrote: >> > >> >> Well as the only committer that's really working on the internals, I >> >> am wondering what to do myself now. >> >> >> >> I've been working on (and have almost finished) a very large change >> >> affecting virtually everything. When I commit it, the API will come >> >> apart at the seams :-/, and people will not be very happy with the >> >> rewrites of their own code they'll be doing. >> >> >> >> Which of the following would be best: >> >> 1. Releasing what is in SVN trunk now (maybe minus another API >> >> breaking change from a few months ago) as 1.0, then adding my large >> >> API-breaking change which will eventually be released as version 2.0. >> >> >> > >> > Remember that you'll have to change the package name and Maven >> coordinates >> > for 2.0. >> > >> >> The good news is that version 0.97 is in the old package name >> org.apache.sanselan. This means no jar hell for 1.0 >> (org.apache.commons.imaging) vs. 0.97. 1.0 which will co-exist with 0.97 in >> the same class loader. With option (1), upgrading from 0.97 to 1.0 will >> mean AT LEAST updating all package imports, not that bad. Make sure you >> write good release notes ;) >> >> Let me also offer a bit of perspective for your consideration. Releasing an >> option (1) 1.0 means supporting it to some extent on the ML and with >> possible maintenance releases. Since 2.0 is incompatible, do you really >> want to take on maintaining two large code bases (or three if you count >> 0.97)? Right now, there seems to be only one committer with deep domain >> knowledge, you ;) Another possibility -- your (3) -- would be to "flush >> out" another (last?) 0.x "release" to get trunk out there for 0.x users, >> then release 1.0 which would be the new API. It seems self-defeating to >> release a 1.0 knowing the API is not going to live going forward to 2.0. >> With option (2), you are saying, [imaging] has learned its lessons in >> alpha, it has now grown up to a 1.0-level releasable API. What I do not >> know is how close you are to the new API being done. >> >> In the end, you know the audience best and users that adopt a 0.x product >> should know that they are taking on a certain level of risk. In addition, >> no one is forcing them to update to 1.0. Since you are doing the work, I'll >> support your efforts with option (1). If you called for a [POLL] email on >> the user's ML, my guess is that users would be happy with a non-breaking >> 1.0 release. >> &g
Re: [imaging] Plan for 1.0.0 release
Hi Rauel Nice to meet you too :). Thank you for the positive feedback. Agreed. If there are no further objections, we'll go with option 1. I would appreciate some help with making the release, as my attempts to release 4 prior RCs have failed, the most recent being RC4: http://mail-archives.apache.org/mod_mbox/commons-dev/201209.mbox/%3CCAJm2B-nbnbJwNUKkAtapZuzT5jfFODsk1aXcdsUUeoC%2BxXrDKg%40mail.gmail.com%3E Though I've fixed most of those problems, and will be sending out a reply to Gary Gregory's reply shortly. Yes it still uses SVN. That sounds good. Regards Damjan On Mon, Oct 21, 2013 at 4:01 PM, Raul Kripalani wrote: > Hi Damjan, > > Nice to meet you! And many thanks for your quick turnaround. > > Apache Sanselan / Commons Imaging is a widely used library in the community > in its 0.9.7 incubator version. As such, I strongly believe that the > current version of the code deserves to be promoted to 1.0.0. It's a stable > library, practically the only OSS library powerful enough for image > manipulation. > > Moreover, it is very confusing for users (including me) to discover that > Sanselan was integrated into Commons Imaging two years ago, yet that no > official release has been made ever since under that branding. > > For all this, I encourage option 1 ASAP. You can cut a release now with > version number 1.0.0, without backing out the breaking change you mention > in your email. As it is, the package renaming itself will break current > consumers anyway! > > Then continue working on 2.0.0 within trunk (the project still uses SVN, > right?), and keep the imaging-1.0.0 branch for minor and patch releases. > > What do you think? > > Regards, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Mon, Oct 21, 2013 at 3:47 PM, Damjan Jovanovic wrote: > >> Well as the only committer that's really working on the internals, I >> am wondering what to do myself now. >> >> I've been working on (and have almost finished) a very large change >> affecting virtually everything. When I commit it, the API will come >> apart at the seams :-/, and people will not be very happy with the >> rewrites of their own code they'll be doing. >> >> Which of the following would be best: >> 1. Releasing what is in SVN trunk now (maybe minus another API >> breaking change from a few months ago) as 1.0, then adding my large >> API-breaking change which will eventually be released as version 2.0. >> 2. Adding my large change now and API-breaking everything in trunk, >> then releasing that as 1.0. >> 3. Releasing what is in SVN trunk now (maybe minus another API >> breaking change from a few months ago) as 0.98, then API-breaking >> everything, and then either releasing a 0.99 or 1.0. (This is probably >> the hardest option, and may not be possible, since version numbering >> of nightly builds will go backwards and JIRA bugs will need to be >> changed.) >> >> Thoughts? Preferences? >> >> Regards >> Damjan >> >> On Mon, Oct 21, 2013 at 3:30 PM, Raul Kripalani wrote: >> > Hello all, >> > >> > Are there any plans for releasing 1.0.0 soon? >> > >> > The last commit was 2 months old and the community will hands-down >> benefit >> > from a GA release that includes the bugfixes and code renames from >> Sanselan >> > to Commons Imaging, carried out ever since 0.9.7. >> > >> > Can I help in any way? We need the 1.0.0 release for our project to >> acquire >> > the fix for IMAGING-49 [1], and we cannot rely on SNAPSHOTs. >> > >> > [1] https://issues.apache.org/jira/browse/IMAGING-49 >> > >> > Thanks, >> > >> > *Raúl Kripalani* >> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source >> > Integration specialist >> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani >> > http://blog.raulkr.net | twitter: @raulvk >> >> - >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> >> - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [imaging] Plan for 1.0.0 release
Well as the only committer that's really working on the internals, I am wondering what to do myself now. I've been working on (and have almost finished) a very large change affecting virtually everything. When I commit it, the API will come apart at the seams :-/, and people will not be very happy with the rewrites of their own code they'll be doing. Which of the following would be best: 1. Releasing what is in SVN trunk now (maybe minus another API breaking change from a few months ago) as 1.0, then adding my large API-breaking change which will eventually be released as version 2.0. 2. Adding my large change now and API-breaking everything in trunk, then releasing that as 1.0. 3. Releasing what is in SVN trunk now (maybe minus another API breaking change from a few months ago) as 0.98, then API-breaking everything, and then either releasing a 0.99 or 1.0. (This is probably the hardest option, and may not be possible, since version numbering of nightly builds will go backwards and JIRA bugs will need to be changed.) Thoughts? Preferences? Regards Damjan On Mon, Oct 21, 2013 at 3:30 PM, Raul Kripalani wrote: > Hello all, > > Are there any plans for releasing 1.0.0 soon? > > The last commit was 2 months old and the community will hands-down benefit > from a GA release that includes the bugfixes and code renames from Sanselan > to Commons Imaging, carried out ever since 0.9.7. > > Can I help in any way? We need the 1.0.0 release for our project to acquire > the fix for IMAGING-49 [1], and we cannot rely on SNAPSHOTs. > > [1] https://issues.apache.org/jira/browse/IMAGING-49 > > Thanks, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [imaging] save a image in cmyk
Hi
At the moment Imaging does not support saving to JPEG, and can only
write TIFF in black and white, and RGB (see photometricInterpretation
in the writeImage() method in
org/apache/commons/imaging/formats/tiff/write/TiffImageWriterBase.java).
I don't think a patch for CMYK would be hard to write though.
Regards
Damjan
On Wed, Sep 11, 2013 at 12:18 PM, samhe wrote:
> Hello , i have some problem in using Apache Common Imaging , please do me a
> favor.
> I want to write some text in a cmyk image in JPEG or TIFF. First , i got
> BufferedImage from the source cmyk image in JPEG, and i found it is in RGB
> color space , so I use ColorTools to convert it to cmyk color space, and save
> it in JPEG and TIFF, but when i open the image file with photoshop , it's
> also in RGB. The code does not work, or something i did wrong?
> My code like this:
> ICC_Profile rgbProfile =
> ICC_Profile.getInstance("D:\\test\\AdobeRGB1998.icc");
> ColorSpace rgbColorSpace = new ICC_ColorSpace(rgbProfile);
> ICC_Profile cmykProfile =
> ICC_Profile.getInstance("D:\\test\\JapanColor2001Coated.icc");
> ColorSpace cmykColorSpace = new ICC_ColorSpace(cmykProfile);
> ColorTools colorTools = new ColorTools();
> //BufferedImage cmykImage = colorTools.convertBetweenColorSpaces(image,
> rgbColorSpace, cmykColorSpace);
> BufferedImage cmykImage = colorTools.convertToColorSpace(image,
> cmykColorSpace);
> ImageFormat format = ImageFormat.IMAGE_FORMAT_TIFF;
> Map params = new HashMap();
> params.put(ImagingConstants.PARAM_KEY_FORMAT, ImageFormat.IMAGE_FORMAT_TIFF);
> Imaging.writeImage(cmykImage, new File("d:/test/y.tif"),
> ImageFormat.IMAGE_FORMAT_TIFF, params);
>
> I find some classes about cmyk in api doc , but i do not know how to use
> them. And cannot found more information or document about it in internet.
> so ... please give me some demo or point out my code error . Thank you!
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [imaging] Create a multi page TIFF
Hi Rafael Imaging isn't able to do write multi-page TIFFs right now. I was working on a patch to add that feature, but I need another week or so to finish it. Regards Damjan On Thu, Aug 22, 2013 at 8:29 PM, Rafael Ferreira de Lima Veloso (Mirante) < rafael.v...@sicoob.com.br> wrote: > Hi, > > > > I've been working with commons-imaging in a project at my company and > it have worked very well, but now I need to split multi-page TIFF and > also I need to create a multi-page TIFF from JPG images. > > So, I already know how to split a multi-page, but I've had a really hard > time trying to CREATE a multi-page. > > > > Please, I would really appreciate some help. > > > > Best Regards, > > Rafael Rakon > > > >
Re: [compress] create 7zip archive
On Thu, Jun 6, 2013 at 12:45 PM, wrote: > Hello, > > I realized that trunk has support for reading 7z archive. That is great news. > But I miss write 7z archive feature. Would you consider adding this feature? > There is no java implementation at all. > > Leoš I've just committed preliminary uncompressed 7z write support to SVN. Enjoy Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [compress] create 7zip archive
The opposite method is COutArchive::WriteNumber() in file CPP/7zip/Archive/7z/7zOut.cpp in the LZMA SDK. Damjan On Thu, Jun 6, 2013 at 7:05 PM, Leos Literak wrote: > Damjan, > > are you aware of opposite method to readUint64? I found a bug in our > implementation and it is really ugly written. I wonder that writing from > scratch would be faster than understanding it :-) I just first want to ensure > that it does not exist. I have already googled. > > Thanks > > Leos > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [compress] create 7zip archive
Ok, I'll see what I can do. The 7zFormat.txt in http://downloads.sourceforge.net/sevenzip/7z920.tar.bz2 seems newer / more accurate. Damjan On Thu, Jun 6, 2013 at 1:53 PM, Leos Literak wrote: > HI Damjan, > > that would be awesome! I just need anything that 7z can uncompress. I do not > care of passwords or selection of compression algorithm. I am OK with > RandomAccessFile. > > Ad "spec" - I downloaded lzma922.tar.bz2 - I consider it as latest. Or do you > have newer file format description? > > Leoš > > ______ >> Od: "Damjan Jovanovic" >> Komu: Commons Users List >> Datum: 06.06.2013 13:41 >> Předmět: Re: [compress] create 7zip archive >> > Hi > > I wrote the read support. Writing is tricky for several reasons: > * We need lzma for archive header compression (good to hear XZ has it > now Stefan!). It's optional but beneficial. > * No [compress] API exists for setting the password to use when writing. > * 7z supports "solid compression" in several variants: disabled, one > solid block per all files with the same extension, multiple solid > blocks of X megabytes in size, one solid block for all files, etc. > This gets complex to implement, and we need some way to configure > these. > * Writing cannot be implemented using (Archive)OutputStream and less > than O(n) memory, as fields written earlier in the file are only known > at the end of the compression process. So once again we need > RandomAccessFile. > > But I'll see if I can hack together a simple unencrypted > no-solid-compression writer that we can gradually improve. > > Yes, the 7zip GUI is generally a Windows-only tool (although it works > well in Wine), and even the 7z file format is very Windows-specific > (NTFS timestamps, Windows attributes, little-endian values, etc.). > 7zFormat.txt has mistakes (though the one in the 7z920 package is > better than the one in the lzma920 package) and even the reference > implementation differs from it, which is why I had to port from C/C++ > and give credit in NOTICE. > > Damjan > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [compress] create 7zip archive
Hi I wrote the read support. Writing is tricky for several reasons: * We need lzma for archive header compression (good to hear XZ has it now Stefan!). It's optional but beneficial. * No [compress] API exists for setting the password to use when writing. * 7z supports "solid compression" in several variants: disabled, one solid block per all files with the same extension, multiple solid blocks of X megabytes in size, one solid block for all files, etc. This gets complex to implement, and we need some way to configure these. * Writing cannot be implemented using (Archive)OutputStream and less than O(n) memory, as fields written earlier in the file are only known at the end of the compression process. So once again we need RandomAccessFile. But I'll see if I can hack together a simple unencrypted no-solid-compression writer that we can gradually improve. Yes, the 7zip GUI is generally a Windows-only tool (although it works well in Wine), and even the 7z file format is very Windows-specific (NTFS timestamps, Windows attributes, little-endian values, etc.). 7zFormat.txt has mistakes (though the one in the 7z920 package is better than the one in the lzma920 package) and even the reference implementation differs from it, which is why I had to port from C/C++ and give credit in NOTICE. Damjan On Thu, Jun 6, 2013 at 1:13 PM, Leos Literak wrote: > I understand Stephan. I am happy to see the first partial java > implementation. The situation is bad - no java support, unix version lacks > some features (multi volume support). I have to maintain one proprietary > implementation and I seek how to replace it. Well, at least I can study your > reader, as I hate 7zFormat.txt. It is not formal and I have to guess what its > author meant. > > Leoš > > __ >> Od: "Stefan Bodewig" >> Komu: >> Datum: 06.06.2013 12:58 >> Předmět: Re: [compress] create 7zip archive >> > On 2013-06-06, wrote: > >> I realized that trunk has support for reading 7z archive. > > And even read support is incomplete, we currently lack LZMA support > (only LZMA2 is present). The good news is that XZ for Java's trunk now > supports LZMA directly so we are on our way to complete read support. > >> But I miss write 7z archive feature. Would you consider adding this >> feature? > > Consider? Sure. It's just a matter of anybody finding the time to > write the code :-) > > More seriously, even read-only support is pretty new and it took a lot > of effort, there is no ETA for write support. > > Stefan > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [Imaging] Embedding Region of Interest(ROI)
Does the EXIF SubjectArea/SubjectLocation tag do what you want? Damjan -- Forwarded message -- From: Mark Fortner Date: Sun, Jan 20, 2013 at 8:32 PM Subject: [Imaging] Embedding Region of Interest(ROI) To: Commons Users List I have a number of family photographs that I'd like to annotate. A lot of these photographs already have people identified in them courtesy of Picasa. I'd like to know: - Is there a standard way of defining and embedding a region of interest in a photograph? - Are there any image viewers that currently use that standard? - Is there a way of embedding Picasa's region of interest definitions into the photograph? I understand that Picasa saves this metadata in a separate file rather than in the original photograph. Cheers, Mark - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: working example of write to EXIF with Commons Imaging (ex Sanselan)?
Try something along these lines:
private static void rewriteUserComment(String fileIn, String fileOut)
throws Exception {
TiffImageMetadata exif;
IImageMetadata meta = Imaging.getMetadata(new File(fileIn));
if (meta instanceof JpegImageMetadata) {
exif = ((JpegImageMetadata)meta).getExif();
} else if (meta instanceof TiffImageMetadata) {
exif = (TiffImageMetadata)meta;
} else {
return;
}
TiffOutputSet outputSet = exif.getOutputSet();
TiffOutputDirectory exifDir =
outputSet.findDirectory(TiffDirectoryConstants.DIRECTORY_TYPE_EXIF);
exifDir.removeField(ExifTagConstants.EXIF_TAG_USER_COMMENT);
exifDir.add(ExifTagConstants.EXIF_TAG_USER_COMMENT, "my very
own comment with " + '\u041F');
ExifRewriter rewriter = new ExifRewriter();
FileOutputStream fos = null;
try {
fos = new FileOutputStream(new File(fileOut));
rewriter.updateExifMetadataLossy(new File(fileIn), fos, outputSet);
} finally {
if (fos != null) {
fos.close();
}
}
}
Regards
Damjan
On Wed, Jan 16, 2013 at 8:52 AM, Clement Levallois
wrote:
> Hi,
>
> I posted this question on StackOverflow but it might get more attention
> here:
>
> http://stackoverflow.com/questions/14341054/writing-custom-metadata-fields-to-jpeg-with-apache-commons-imaging
>
> Basically, I can't find a working example to write on a EXIF tag with
> Commons Imaging. Any help would be appreciated!
>
> Best,
>
> Clement
>
>
> Clement Levallois, PhD
> Erasmus University Rotterdam
> The Netherlands
>
> pro website
> / personal website
Re: [sanselan] Removing GPS tags problem
Which unrelated tags are removed? From my tests, that code only
changes directory offsets (eg. "ExifOffset" and "InteropOffset"), but
doesn't remove anything.
Damjan
On Sat, Dec 1, 2012 at 7:08 PM, Piotr Czajka wrote:
> Hi,
> I have a problem with removing gps data from photo.
> It's works but also other tags unrelated with gps are removed
>
> code :
>
>
> public void removeExifTag(File jpegImageFile, File dst) throws
> IOException, ImageReadException,
>
> ImageWriteException {
> OutputStream os = null;
> try {
> TiffOutputSet outputSet = null;
>
> // note that metadata might be null if no metadata is found.
> IImageMetadata metadata = Imaging.getMetadata(
> jpegImageFile);
> JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
> if (null != jpegMetadata)
> {
> // note that exif might be null if no Exif metadata is found.
> TiffImageMetadata exif = jpegMetadata.getExif();
>
> if (null != exif)
> {
> // TiffImageMetadata class is immutable (read-only).
> // TiffOutputSet class represents the Exif data to write.
> //
> // Usually, we want to update existing Exif metadata by
> // changing
> // the values of a few fields, or adding a field.
> // In these cases, it is easiest to use getOutputSet() to
> // start with a "copy" of the fields read from the image.
> outputSet = exif.getOutputSet();
> }
> }
>
> if (null == outputSet) {
> // file does not contain any exif metadata. We don't need to
> // update the file; just copy it.
> IoUtils.copyFileNio(jpegImageFile, dst);
> return;
> }
>
> {
> // Example of how to remove a single tag/field.
> // There are two ways to do this.
>
> // Option 1: brute force
> // Note that this approach is crude: Exif data is organized in
> // directories. The same tag/field may appear in more than one
> // directory, and have different meanings in each.
>
> // outputSet.removeField(ExifTagConstants.EXIF_TAG_GPSINFO);
>
> // Option 2: precision
> // We know the exact directory the tag should appear in, in this
> // case the "exif" directory.
> // One complicating factor is that in some cases, manufacturers
> // will place the same tag in different directories.
> // To learn which directory a tag appears in, either refer to
> // the constants in ExifTagConstants.java or go to Phil Harvey's
> // EXIF website.
>
> TiffOutputDirectory gpsDirectory = outputSet.getGPSDirectory();//
> <---
> if (null != gpsDirectory)
> {
> gpsDirectory.removeField(GpsTagConstants.GPS_TAG_GPS_LATITUDE);
> gpsDirectory.removeField(GpsTagConstants.GPS_TAG_GPS_LONGITUDE);
>
> }
> }
>
> os = new FileOutputStream(dst);
> os = new BufferedOutputStream(os);
>
> new ExifRewriter().updateExifMetadataLossless(jpegImageFile, os,
> outputSet);
>
> os.close();
> os = null;
> } finally {
> if (os != null)
> try {
> os.close();
> } catch (IOException e) {
>
> }
> }
> }
>
> I want to remove only gps position information from photo
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [Imaging] Will version 1.0 ever be released?
Thank you I'll try that later. Yes, the only ones I haven't solved yet are a few dead variable stores in Findbugs, and the non-use of Nexus for the build (it's apparently mandatory now). On Mon, Sep 17, 2012 at 1:19 PM, Christian Grobmeier wrote: > Damjan, > > I recommend you to follow the UsingNexus guide: > http://wiki.apache.org/commons/UsingNexus > > Several people here (including me) have made a release with that. > Guess we all will help you whenever you come across problems. If the > release procedure is your only problem with the next release it can be > solved. > > I have not looked into the mentioned RC2 and I am not sure why it was > rejected. Do yo remember what the key concerns were? > > Cheers > > On Mon, Sep 17, 2012 at 1:15 PM, Damjan Jovanovic > wrote: > > Honestly: the incredibly complex and mostly undocumented process for > doing > > a release. There are various incompatible bits in at least 4 different > > places: > > * http://commons.apache.org/releases/prepare.html - is meant to be the > > official Commons release documentation, but it's out of date and the PMC > > rejected my RC2 built with it > > * http://wiki.apache.org/commons/CreatingReleases - a "discussion page" > > * http://wiki.apache.org/commons/UsingNexus - a "draft" > > * http://www.apache.org/dev/publishing-maven-artifacts.html - the > > instructions for top-level Apache projects, which Imaging is not > > > > Regards > > Damjan > > > > On Mon, Sep 17, 2012 at 1:08 PM, Adrian Mörchen < > > adrian.moerc...@communote.com> wrote: > > > >> Hi, > >> > >> I think me and possible a lot of others are waiting for a new release on > >> this. > >> This version has a lot of bugs fixed, features and improvements added. > At > >> least a public beta should be available (via Maven). > >> > >> So, what's holding you back not to release a new version? > >> > >> Thanks, > >> > >> Adrian > >> > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > >
Re: [Imaging] Will version 1.0 ever be released?
I think you mean https://repository.apache.org/index.html#nexus-search;gav~org.apache.commons~commons-imaging~~~ The project was renamed from sanselan. Also that is only a monthly snapshot by the looks of it. On Mon, Sep 17, 2012 at 1:25 PM, Christian Grobmeier wrote: > On Mon, Sep 17, 2012 at 1:20 PM, Matej Jelovcan wrote: > > HI. > > > > Any way of obtaining build as-is? Can't build it myself for various > reasons :) > > > > You can try that snapshot: > > https://repository.apache.org/index.html#nexus-search;gav~org.apache.commons~commons-sanselankw,versionexpand > > But no guarantee on that - its just an unreleased snapshot. > > Cheers > > > > Cheers, > > MJ > > > > On 9/17/12, Damjan Jovanovic wrote: > >> Honestly: the incredibly complex and mostly undocumented process for > doing > >> a release. There are various incompatible bits in at least 4 different > >> places: > >> * http://commons.apache.org/releases/prepare.html - is meant to be the > >> official Commons release documentation, but it's out of date and the PMC > >> rejected my RC2 built with it > >> * http://wiki.apache.org/commons/CreatingReleases - a "discussion page" > >> * http://wiki.apache.org/commons/UsingNexus - a "draft" > >> * http://www.apache.org/dev/publishing-maven-artifacts.html - the > >> instructions for top-level Apache projects, which Imaging is not > >> > >> Regards > >> Damjan > >> > >> On Mon, Sep 17, 2012 at 1:08 PM, Adrian Mörchen < > >> adrian.moerc...@communote.com> wrote: > >> > >>> Hi, > >>> > >>> I think me and possible a lot of others are waiting for a new release > on > >>> this. > >>> This version has a lot of bugs fixed, features and improvements added. > At > >>> least a public beta should be available (via Maven). > >>> > >>> So, what's holding you back not to release a new version? > >>> > >>> Thanks, > >>> > >>> Adrian > >>> > >> > > > > - > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > > For additional commands, e-mail: user-h...@commons.apache.org > > > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > >
Re: [Imaging] Will version 1.0 ever be released?
Honestly: the incredibly complex and mostly undocumented process for doing a release. There are various incompatible bits in at least 4 different places: * http://commons.apache.org/releases/prepare.html - is meant to be the official Commons release documentation, but it's out of date and the PMC rejected my RC2 built with it * http://wiki.apache.org/commons/CreatingReleases - a "discussion page" * http://wiki.apache.org/commons/UsingNexus - a "draft" * http://www.apache.org/dev/publishing-maven-artifacts.html - the instructions for top-level Apache projects, which Imaging is not Regards Damjan On Mon, Sep 17, 2012 at 1:08 PM, Adrian Mörchen < adrian.moerc...@communote.com> wrote: > Hi, > > I think me and possible a lot of others are waiting for a new release on > this. > This version has a lot of bugs fixed, features and improvements added. At > least a public beta should be available (via Maven). > > So, what's holding you back not to release a new version? > > Thanks, > > Adrian >
Re: [sanselan] Ah, the special characters
Hey
The XP fields aren't UTF-8, they're UTF-16LE.
Regards/Pozdrav
Damjan
On Fri, Jul 20, 2012 at 10:56 PM, Matej Jelovcan wrote:
> Hey guys.
>
> Damjan was already answering similar question, I thin (this is the mail
> archive I found:
> http://www.mail-archive.com/user@commons.apache.org/msg07447.html) but did
> no good to me. This is my complete test class that I use to test this
> thing...
>
> package si;
>
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.OutputStream;
> import java.util.ArrayList;
>
> import org.apache.sanselan.ImageWriteException;
> import org.apache.sanselan.Sanselan;
> import org.apache.sanselan.common.IImageMetadata;
> import org.apache.sanselan.formats.jpeg.JpegImageMetadata;
> import org.apache.sanselan.formats.jpeg.exifRewrite.ExifRewriter;
> import org.apache.sanselan.formats.tiff.TiffField;
> import org.apache.sanselan.formats.tiff.TiffImageMetadata;
> import org.apache.sanselan.formats.tiff.constants.TagInfo;
> import org.apache.sanselan.formats.tiff.constants.TiffConstants;
> import org.apache.sanselan.formats.tiff.constants.TiffFieldTypeConstants;
> import org.apache.sanselan.formats.tiff.write.TiffOutputField;
> import org.apache.sanselan.formats.tiff.write.TiffOutputSet;
>
> public class SanselanTestCase
> {
> private static File TEMPORARY_FILE = null;
> private static String ENCODING = "UTF-8";
> private ExifRewriter exifRewriter = new ExifRewriter();
> public static void main(String[] args)
> {
> File file = new File("d:\\image.jpg");
> SanselanTestCase testCase = new SanselanTestCase();
> try
> {
> String newValue = "Special chars: čšđžć";
> testCase.updateMetaDataTags(file, TiffConstants.EXIF_TAG_XPTITLE, newValue);
> testCase.updateMetaDataTags(file, TiffConstants.EXIF_TAG_XPSUBJECT,
> newValue);
> testCase.updateMetaDataTags(file, TiffConstants.EXIF_TAG_XPCOMMENT,
> newValue);
> }
> catch(Exception ex)
> {
> ex.printStackTrace();
> }
> //Read data
> testCase.getImageData(file, true);
> }
> /**
> * Read meta-data from image file and save it to Metadata_Data object that
> * is then returned.
> *
> * @param sourceFile
> * @param printOut
> *: if true, console will show what image meta data was found.
> * @return
> */
> public void getImageData(File sourceFile, boolean printOut)
> {
> IImageMetadata metadata = null;
> try
> {
> metadata = Sanselan.getMetadata(sourceFile);
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> if (metadata instanceof JpegImageMetadata)
> {
> JpegImageMetadata jpegMetadata = (JpegImageMetadata)metadata;
> getTagValue(jpegMetadata, TiffConstants.EXIF_TAG_XPTITLE, printOut);
> getTagValue(jpegMetadata, TiffConstants.EXIF_TAG_XPSUBJECT, printOut);
> getTagValue(jpegMetadata, TiffConstants.EXIF_TAG_XPCOMMENT, printOut);
> }
> }
> /**
> * Read ALL EXIF entries for specified IMAGE file.
> * @param sourceFile
> */
> public static void printAllImageMetaDataValues(File sourceFile)
> {
> IImageMetadata metadata = null;
> try
> {
> metadata = Sanselan.getMetadata(sourceFile);
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> if (metadata instanceof JpegImageMetadata)
> {
> JpegImageMetadata jpegMetadata = (JpegImageMetadata)metadata;
> System.out.println("EXIF items -");
> @SuppressWarnings("rawtypes")
> ArrayList items = jpegMetadata.getItems();
> for (int i = 0; i < items.size(); i++)
> {
> TiffImageMetadata.Item item = (TiffImageMetadata.Item)items.get(i);
> System.out.println(" " + item.getKeyword() + " = " + item.getText());
> }
> }
> }
> /**
> * Method returns value for specific meta-data tag. If tag info is not
> * found, null is returned.
> *
> * @param jpegMetadata
> * @param tagInfo
> * @param printOut
> *: if true, results are printed in console window.
> * @return
> */
> private String getTagValue(JpegImageMetadata jpegMetadata, TagInfo tagInfo,
> boolean printOut)
> {
> TiffField field = jpegMetadata.findEXIFValue(tagInfo);
> if (field == null)
> {
> if (printOut)
> System.out.println(" " + tagInfo.name + ": " + "Not Found.");
> return null;
> }
> else
> {
> if (printOut)
> System.out.println(" " + tagInfo.name + ": " +
> field.getValueDescription());
> // return field.getValueDescription();
> String result = field.getValueDescription();
> if (result.startsWith("'") && result.endsWith("'"))
> result = result.substring(1, result.length() - 1);
> return result;
> }
> }
> /**
> * Method inserts new meta-data that is supplied to the method to source
> * file.
> *
> * @param sourceFile
> * @param data
> */
> public boolean updateMetaDataTags(File sourceFile, TagInfo tagInfo, String
> value)
> {
> File destinationFile = null;
> IImageMetadata metadata = null;
> JpegImageMetadata jpegMetadata = null;
> TiffImageMetadata exif = null;
> OutputStream os = null;
> TiffOutputSet outputSet = new TiffOutputSet();
> // Establish metadata
> try
Re: [sanselan] Writing EXIF data to JPEG
On Thu, Mar 8, 2012 at 6:39 PM, Kasper Føns wrote:
>
>> I wouldn't count on Windows Explorer to give you the right values.
>> Rather check it against exiftool
>> (www.sno.phy.queensu.ca/~phil/exiftool/):
>> exiftool -a -g1 -u image.tiff
>>
>> Windows Explorer also likes the "XP" values (eg. EXIF_TAG_XPCOMMENT,
>> EXIF_TAG_XPAUTHOR), maybe try writing those as well?
>>
>> Damjan
>>
> Sorry for asking so many questions :( I hope it is okay.
Yes it's okay :).
> Hmm. It does not seem like the XP values work. They do not show correctly.
>
> Anyways, I tried using the code I sent you without special characters:
> byte[] bytesComment =
> ExifTagConstants.EXIF_TAG_USER_COMMENT.encodeValue(TiffFieldTypeConstants.FIELD_TYPE_ASCII,
> "KasperComment", set.byteOrder);
> byte[] bytesAuthor =
> TiffTagConstants.TIFF_TAG_ARTIST.encodeValue(TiffFieldTypeConstants.FIELD_TYPE_ASCII,
> "KasperAuthor", set.byteOrder);
>
> TiffOutputField commentField = new
> TiffOutputField(ExifTagConstants.EXIF_TAG_USER_COMMENT,
> ExifTagConstants.EXIF_TAG_USER_COMMENT.dataTypes[0], bytesComment.length,
> bytesComment);
> TiffOutputField authorField = new
> TiffOutputField(TiffTagConstants.TIFF_TAG_ARTIST,
> TiffTagConstants.TIFF_TAG_ARTIST.dataTypes[0], bytesAuthor.length,
> bytesAuthor);
> set.getOrCreateExifDirectory().add(commentField);
> set.getOrCreateRootDirectory().add(authorField);
>
> Then the exif tools shows (and so do windows explorer):
> IFD0
> Artist : KasperAuthor
> ExifIFD
> User Comment : KasperComment
> JFIF
> JFIF Version : 1.01
>
> However, trying the same, but adding an å to KasperComment and KasperAuthor
> gives the following:
> IFD0
> Artist : KasperAuthorå
> ExifIFD
> User Comment : 䭡獰敲䍯浭敮瓃
> JFIF
> JFIF Version : 1.01
>
> It seems the UserComment has been destroyed. Now it is suddenly chinese
> characters!?
> Windows explorer shows the artist but not the usercomment.
>
> Is this something to do with ExifDirectory vs RootDirectory?
No, the directory wouldn't affect the output.
Sanselan 0.97:
* doesn't null-terminate ASCII strings (eg. Artist), so you have to
allocate a byte array one element bigger and copy the encoded bytes to
it.
* uses the system locale for ASCII encoding, which is UTF-16LE on
Windows, even though TIFF requires UTF-8
So for ASCII fields instead of using encodeValue(), use
getBytes("UTF-8") and copy to a byte array with one more element (so
that the last element is null) like I showed you in the previous
email.
For UserComment what Sanselan does is autodetect the encoding: this
will work for ASCII and write ASCII, but in 0.97 it wrongly assumed
that the unicode encoding is UTF-8, whereas it's actually UTF-16 with
byte ordering depending on the file's byte ordering. So in 0.97 you
have to encode this manually yourself using a big hack:
byte[] unicodeMarker = new byte[]{ 0x55, 0x4E, 0x49, 0x43, 0x4F, 0x44,
0x45, 0x00 };
byte[] comment = "My Comment".getBytes("UTF-16LE"); // OR UTF-16BE if
the file is big-endian!
byte[] bytesComment = new byte[unicodeMarker.length + comment.length];
System.arraycopy(marker, 0, bytesComment, 0, marker.length);
System.arraycopy(comment, 0, bytesComment, marker.length, comment.length);
TiffOutputField commentField = new
TiffOutputField(ExifTagConstants.EXIF_TAG_USER_COMMENT,
ExifTagConstants.EXIF_TAG_USER_COMMENT.dataTypes[0], bytesComment.length,
bytesComment);
We can safely conclude from this that there is many reasons why 1.0
needs to be released, and 0.97 needs to die :).
>
> /Kasper
>
Damjan
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] Writing EXIF data to JPEG
On Thu, Mar 8, 2012 at 7:02 PM, Kasper Føns wrote:
>
>> Windows Explorer also likes the "XP" values (eg. EXIF_TAG_XPCOMMENT,
>> EXIF_TAG_XPAUTHOR), maybe try writing those as well?
>
> Hmm. You seem to be right that explorer likes the XP values. However, I
> can't figure out how to write to them. I can see that they are BYTE values,
> but how to convert a string into the wanted bytes?
>
> This is the result I get:
> IFD0
> XP Comment : 態灳牥潃浭湥t
> XP Author : 態灳牥畁桴牯
>
> With this code:
> byte[] bytesComment =
> ExifTagConstants.EXIF_TAG_XPCOMMENT.encodeValue(TiffFieldTypeConstants.FIELD_TYPE_ASCII,
> "KasperComment", set.byteOrder);
> byte[] bytesAuthor =
> ExifTagConstants.EXIF_TAG_XPAUTHOR.encodeValue(TiffFieldTypeConstants.FIELD_TYPE_ASCII,
> "KasperAuthor", set.byteOrder);
> TiffOutputField commentField = new
> TiffOutputField(ExifTagConstants.EXIF_TAG_XPCOMMENT,
> ExifTagConstants.EXIF_TAG_XPCOMMENT.dataTypes[0], bytesComment.length,
> bytesComment);
> TiffOutputField authorField = new
> TiffOutputField(ExifTagConstants.EXIF_TAG_XPAUTHOR,
> ExifTagConstants.EXIF_TAG_XPAUTHOR.dataTypes[0], bytesAuthor.length,
> bytesAuthor);
> set.getOrCreateRootDirectory().add(commentField);
> set.getOrCreateRootDirectory().add(authorField);
>
>
> /Kasper
There's no easy way in Sanselan 0.97: the XP fields use little-endian
UTF-16 (no matter what the byte ordering of the file is, thanks
Microsoft you useless @*#%!) so try this:
byte[] rawBytes = "KasperAuthor".getBytes("UTF-16LE");
byte[] nullTerminatedBytes = new byte[rawBytes.length + 2];
TiffOutputField authorField = new
TiffOutputField(ExifTagConstants.EXIF_TAG_XPAUTHOR,
ExifTagConstants.EXIF_TAG_XPAUTHOR.dataTypes[0], nullTerminatedBytes.length,
nullTerminatedBytes);
Damjan
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] Writing EXIF data to JPEG
On Thu, Mar 8, 2012 at 2:45 PM, Kasper Føns wrote: > >> Sorry about the website, I plan on fixing it with the 1.0 release. >> >> UserComment is one of the uglier cases, as it uses that GPS string >> type with a special prefix to distinguish character encodings. >> >> Try using TagInfo.Text's encodeValue() method to convert the String to >> byte[], then pass that to >> new TiffOutputField(ExifTagConstants.EXIF_TAG_USER_COMMENT, >> ExifTagConstants.EXIF_TAG_USER_COMMENT.fieldTypes, >> bytes.length, bytes); > > Thanks for the help, I can now save a usercomment and the artist field > successfully. > > There is just one tiny little problem that I am now requesting some help > for. > I am able to put international characters into the artist and usercomment > field, however, the usercomment field is not shown in Windows Explorer, but > the artist is. > I have been searching the internet and found that the byteorder should be > little_endian, but that was the default case. > Is there some way to put in internation characters in the usercomment field? > > Here is my current code. I altered yours a bit: > > TiffOutputSet set = new > TiffOutputSet(TiffConstants.BYTE_ORDER_LITTLE_ENDIAN); > > byte[] bytesComment = > ExifTagConstants.EXIF_TAG_USER_COMMENT.encodeValue(TiffFieldTypeConstants.FIELD_TYPE_ASCII, > "KasperCommentĹ", set.byteOrder); > byte[] bytesAuthor = > TiffTagConstants.TIFF_TAG_ARTIST.encodeValue(TiffFieldTypeConstants.FIELD_TYPE_ASCII, > "KasperAuthorĹ", set.byteOrder); > TiffOutputField commentField = new > TiffOutputField(ExifTagConstants.EXIF_TAG_USER_COMMENT, > ExifTagConstants.EXIF_TAG_USER_COMMENT.dataTypes[0], bytesComment.length, > bytesComment); > TiffOutputField authorField = new > TiffOutputField(TiffTagConstants.TIFF_TAG_ARTIST, > TiffTagConstants.TIFF_TAG_ARTIST.dataTypes[0], bytesAuthor.length, > bytesAuthor); > set.getOrCreateExifDirectory().add(commentField); > set.getOrCreateRootDirectory().add(authorField); > > Thanks on beforehand, and thanks for the help so far! > > > /Kasper I wouldn't count on Windows Explorer to give you the right values. Rather check it against exiftool (www.sno.phy.queensu.ca/~phil/exiftool/): exiftool -a -g1 -u image.tiff Windows Explorer also likes the "XP" values (eg. EXIF_TAG_XPCOMMENT, EXIF_TAG_XPAUTHOR), maybe try writing those as well? Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] Writing EXIF data to JPEG
On Wed, Mar 7, 2012 at 10:37 PM, Kasper Føns wrote: > On 07-03-2012 19:41, Damjan Jovanovic wrote: >> >> On Wed, Mar 7, 2012 at 8:07 PM, Kasper Føns wrote: >>> >>> On 07-03-2012 06:37, Damjan Jovanovic wrote: >>>> >>>> On Wed, Mar 7, 2012 at 12:46 AM, Kasper Føns wrote: >>>>> >>>>> Hi Sanselan. >>>>> >>>>> I have a hard time finding out how to use Sanselan. >>>>> >>>>> Suppose I have some JPEG picture which I want to add some attributes >>>>> to. >>>>> If for example I want to add some user comment or date I try this: >>>>> >>>>> TiffOutputSet outputSet = new TiffOutputSet(); >>>>> TiffOutputField dateTaken = >>>>> TiffOutputField.create(TiffConstants.EXIF_TAG_CREATE_DATE, >>>>> outputSet.byteOrder, "2003:03:29 17:47:50"); >>>>> TiffOutputField comment = >>>>> TiffOutputField.create(TiffConstants.EXIF_TAG_IMAGE_DESCRIPTION, >>>>> outputSet.byteOrder, "This is a test!"); >>>>> >>>>> However, both of these fails on "unexpected data type". >>>>> If I am not supposed to give a String, then what I am supposed to >>>>> supply? >>>>> >>>>> I hope you can help with these, probably noobish questions. >>>>> >>>>> /Kasper >>>> >>>> That TiffOutputField.create() was a horribly broken API that I've >>>> eliminated in the latest SVN, and replaced with a new, beautiful, type >>>> safe, code completable, byte order independent >>>> TiffOutputDirectory.add() API. >>>> >>>> I recommend you use the latest SVN, or wait for the 1.0 release in a >>>> few weeks. If you really must use version 0.97, I think the only way >>>> to get strings to work is to convert the string to bytes with >>>> getBytes(), null-terminate those yourself, then pass them to the >>>> low-level constructor "new TiffOutputField(...)". >>>> >>>> Damjan >>> >>> >>> Hi again Damjan. >>> >>> Thanks for the response. I have had a look at the new API, and it looks >>> cleaner. >>> >>> I want to run this on Android, and I can see that there is a heavy >>> dependency on java.awt, which unfortunately is not in Android. >>> Do you have some hints as what to do? >>> >>> >>> /Kasper >> >> No, sorry, Android isn't supported at the moment. There is a fork >> (http://code.google.com/p/sanselanandroid/) which supposedly lets you >> do EXIF on Android, but I've never tried it. >> >> Damjan >> > Hi again again. > > So, the android port is using 0.97 unfortunately, so I can't make use of > your nice API. > Is it possible that you could show me with an example, how I would write the > tag "UserComment" using 0.97? Do you have some samples I can look at? > Also, the website seems to contain a lot of dead links. > > > /Kasper Sorry about the website, I plan on fixing it with the 1.0 release. UserComment is one of the uglier cases, as it uses that GPS string type with a special prefix to distinguish character encodings. Try using TagInfo.Text's encodeValue() method to convert the String to byte[], then pass that to new TiffOutputField(ExifTagConstants.EXIF_TAG_USER_COMMENT, ExifTagConstants.EXIF_TAG_USER_COMMENT.fieldTypes, bytes.length, bytes); Good luck Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] Writing EXIF data to JPEG
On Wed, Mar 7, 2012 at 8:07 PM, Kasper Føns wrote: > On 07-03-2012 06:37, Damjan Jovanovic wrote: >> >> On Wed, Mar 7, 2012 at 12:46 AM, Kasper Føns wrote: >>> >>> Hi Sanselan. >>> >>> I have a hard time finding out how to use Sanselan. >>> >>> Suppose I have some JPEG picture which I want to add some attributes to. >>> If for example I want to add some user comment or date I try this: >>> >>> TiffOutputSet outputSet = new TiffOutputSet(); >>> TiffOutputField dateTaken = >>> TiffOutputField.create(TiffConstants.EXIF_TAG_CREATE_DATE, >>> outputSet.byteOrder, "2003:03:29 17:47:50"); >>> TiffOutputField comment = >>> TiffOutputField.create(TiffConstants.EXIF_TAG_IMAGE_DESCRIPTION, >>> outputSet.byteOrder, "This is a test!"); >>> >>> However, both of these fails on "unexpected data type". >>> If I am not supposed to give a String, then what I am supposed to supply? >>> >>> I hope you can help with these, probably noobish questions. >>> >>> /Kasper >> >> That TiffOutputField.create() was a horribly broken API that I've >> eliminated in the latest SVN, and replaced with a new, beautiful, type >> safe, code completable, byte order independent >> TiffOutputDirectory.add() API. >> >> I recommend you use the latest SVN, or wait for the 1.0 release in a >> few weeks. If you really must use version 0.97, I think the only way >> to get strings to work is to convert the string to bytes with >> getBytes(), null-terminate those yourself, then pass them to the >> low-level constructor "new TiffOutputField(...)". >> >> Damjan > > > Hi again Damjan. > > Thanks for the response. I have had a look at the new API, and it looks > cleaner. > > I want to run this on Android, and I can see that there is a heavy > dependency on java.awt, which unfortunately is not in Android. > Do you have some hints as what to do? > > > /Kasper No, sorry, Android isn't supported at the moment. There is a fork (http://code.google.com/p/sanselanandroid/) which supposedly lets you do EXIF on Android, but I've never tried it. Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] Writing EXIF data to JPEG
On Wed, Mar 7, 2012 at 12:46 AM, Kasper Føns wrote: > Hi Sanselan. > > I have a hard time finding out how to use Sanselan. > > Suppose I have some JPEG picture which I want to add some attributes to. > If for example I want to add some user comment or date I try this: > > TiffOutputSet outputSet = new TiffOutputSet(); > TiffOutputField dateTaken = > TiffOutputField.create(TiffConstants.EXIF_TAG_CREATE_DATE, > outputSet.byteOrder, "2003:03:29 17:47:50"); > TiffOutputField comment = > TiffOutputField.create(TiffConstants.EXIF_TAG_IMAGE_DESCRIPTION, > outputSet.byteOrder, "This is a test!"); > > However, both of these fails on "unexpected data type". > If I am not supposed to give a String, then what I am supposed to supply? > > I hope you can help with these, probably noobish questions. > > /Kasper That TiffOutputField.create() was a horribly broken API that I've eliminated in the latest SVN, and replaced with a new, beautiful, type safe, code completable, byte order independent TiffOutputDirectory.add() API. I recommend you use the latest SVN, or wait for the 1.0 release in a few weeks. If you really must use version 0.97, I think the only way to get strings to work is to convert the string to bytes with getBytes(), null-terminate those yourself, then pass them to the low-level constructor "new TiffOutputField(...)". Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] write IPTC example
On Mon, Feb 20, 2012 at 9:18 PM, Jan Oliver wrote: > Hi, > > I would like to edit the keyword field of IPTC header in jpeg images. I > tried it with 'writeIPTC' of 'JpegIptcRewriter' but I don't understand how > to use it correctly. > > Google doesn't find anything about that subject and the link to the Sanselan > documentation is broken. > Could anybody help me with an example? > > Thanks > Jan Hi The tests that change IPTC might be helpful to look at: http://svn.apache.org/viewvc/commons/proper/sanselan/trunk/src/test/java/org/apache/commons/sanselan/formats/jpeg/iptc/ If you're using version 0.97, rather look at the ones in the source release, since a lot has changed in SVN. Good luck Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] Unable to read jpeg comment field
No, Sanselan didn't have any way to read comments in the last released version. But I just committed a patch to SVN trunk (revision 1211882) that supports reading JPEG comments with: Sanselan.getImageInfo().getComments() If you can't check out and compile SVN, let me know and I can email you a new Sanselan JAR. Regards Damjan On Thu, Dec 8, 2011 at 3:19 PM, Erlend Aakre wrote: > Here is the program I was using and the file that has metadata. > > 1test.jpg has only the JPEG Comment (view by using exiftool for > example), when I run the attached ExifTest.java program I get a null > metadata object. > > vegas.jpg is from a camera, I get metadata but can not find the comment > (JPEG COM) anywhere in it > > Regards > Erlend > > > > > I'm checking. If not, I'll make you a patch. Can you email me an image to > > test with? > > > > Regards > > Damjan > > > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org >
Re: [sanselan] Unable to read jpeg comment field
On Thu, Dec 8, 2011 at 2:38 PM, Erlend Aakre wrote: > I have 2 images, one has almost no metadata (no EXIF), it just has the > JPEG Comment field set (not to be confused with the exif user comment > field). > > When I try to read metadata from it: > IImageMetadata meta = Sanselan.getMetadata(file); > it returns null. > > The other picture is a picture from my camera (Canon EOS1000), which has > lots of metadata. > > I've set the JPEG comment on this image with exiftool (exiftool > -comment=foo file.jpg), I read the metadata: > IImageMetadata meta = Sanselan.getMetadata(file); > > the metadata is a JpegImageMetadata object, I go trough everything in > meta.getItems(), and meta.getExif().getAllField() without finding the > jpeg comment. meta.getPhotoshop() is empty, and meta.getRawImageData() > returns null. > > Is there a way to get the JPEG comment with sanselan? > I'm checking. If not, I'll make you a patch. Can you email me an image to test with? Regards Damjan
Re: [sanselan]
On Mon, Jul 4, 2011 at 11:21 PM, shadab wrote: > Hi > > I get the exception could not read the block when I try to get metadata from > images. > > java.io.IOException: Could not read block (block start: 31742, block length: > 53177352, data length: 25713). > at > org.apache.sanselan.common.byteSources.ByteSourceArray.getBlock(ByteSourceArray.java:47) > at > org.apache.sanselan.formats.tiff.TiffReader.getTiffRawImageData(TiffReader.java:461) > at > org.apache.sanselan.formats.tiff.TiffReader.readDirectory(TiffReader.java:216) > at > org.apache.sanselan.formats.tiff.TiffReader.readDirectory(TiffReader.java:110) > at > org.apache.sanselan.formats.tiff.TiffReader.readDirectories(TiffReader.java:101) > at org.apache.sanselan.formats.tiff.TiffReader.read(TiffReader.java:448) > at > org.apache.sanselan.formats.tiff.TiffReader.readContents(TiffReader.java:438) > at > org.apache.sanselan.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:124) > at org.apache.sanselan.ImageParser.getMetadata(ImageParser.java:81) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:366) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:307) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:978) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:971) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:946) > > There is also an issue for it > https://issues.apache.org/jira/browse/SANSELAN-13 > > I wonder if anybody solve this issue or knows a workaround or can recommend > any other libraries (except Tika ) that I can use to extract XMP EXIF and > other metadata from images. > > Many thanks and please answer quickly > > > Can you try it with SVN HEAD? Damjan - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SANSELAN] How to write GPS Altitude?
Please create a bug on Jira and attach the patch, I will commit it. Thank you Damjan On Tue, Jun 21, 2011 at 4:28 PM, tonio09 wrote: > I've extended GPSInfo to read GPSImgDirection and GPSImgDirectionRef. Also, > I've changed the field length for these fields in TiffConstants. Now > Sanselan reads and writes them fine. Does anyone want the code? Where can I > submit a patch? > > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/SANSELAN-How-to-write-GPS-Altitude-tp1587685p3614297.html > Sent from the Commons - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [sanselan] how to access raw pixels?
On Mon, Apr 18, 2011 at 4:30 PM, Gary Lucas wrote: > I have an application for which I am considering the use of Sanselan to > process GeoTIFF images, but am unsure how to use the API to support one of my > requirements. > > The main Sanselan class provides an API that reads the TIFF and produces a > BufferedImage. But my need is to get at the raw pixels in a random-access > sort of pattern. While I could just use the BufferedImage.getRGB method to > read pixels, I was wondering if there was a way to "cut out the middle man" > and get at the pixel data directly (the hope being that doing so would > improve the time required to load and process the images). I've been looking > through the Sanselan source code (the documentation is a bit sparse), but am > having a bit of trouble figuring out the best way to proceed. > > Does anyone have an example snippet of code or white paper explaining how to > do this? Is it even possible? > > Gary Hi Gary Sanselan only returns BufferedImage, but the raw pixel data can be obtained from the BufferedImage. Call getRaster() to obtain a WritableRaster, then call the methods on it or even the getDataBuffer() method which return a DataBuffer subclass (depending on the BufferedImage's SampleModel and ColorModel) which can give you an array of byte/short/int etc. Good luck Damjan Jovanovic - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
