[jira] [Commented] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO
[ https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260864#comment-14260864 ] Damjan Jovanovic commented on IMAGING-126: -- Guys I've gone further than that: I even have a patch to Imaging which implements LZW decompression using the classes in Compress, and copies those classes into Imaging's JAR using maven-shade-plugin to avoid a run-time dependency. It passed all the tests, and was even somewhat faster than Imaging's LZW in my preliminary benchmarks - can't remember by how much though. It's not committed yet because I wasn't sure if Imaging could/should depend on a SNAPSHOT version of Compress, and there still hasn't been any new releases of Compress since before my LZW changes to it were committed. > TIFF and PNG images should not be bigger than the ones created by java ImageIO > -- > > Key: IMAGING-126 > URL: https://issues.apache.org/jira/browse/IMAGING-126 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG, Format: TIFF >Affects Versions: 1.0 > Environment: W7 >Reporter: Tilman Hausherr >Priority: Minor > Fix For: Discussion > > Attachments: Imaging_126_patch_1.patch, pdfbox-1870-devicen3-01.png, > pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png, > pdfbox-1870-devicen3.pdf-1.tif > > > I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of > problems with setting the tiff resolution in java imageio. > While the code is pretty nice, I found that the generated images are > sometimes much bigger in size than the ones generated by java imageio. > Example: > pdfbox-1870-devicen3-01.png 50 KB (imageio) > pdfbox-1870-devicen3.pdf-1.png 70 KB (imaging) > pdfbox-1870-devicen3-01.tif 401 KB (imageio) > pdfbox-1870-devicen3.pdf-1.tif 1063 KB (imaging) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-139) PropertySetter doesn't set Enum properly
[
https://issues.apache.org/jira/browse/JCS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Youngho Cho updated JCS-139:
Attachment: PropertySetter.java.patch
patch file
> PropertySetter doesn't set Enum properly
>
>
> Key: JCS-139
> URL: https://issues.apache.org/jira/browse/JCS-139
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-2.0
>Reporter: Youngho Cho
> Attachments: PropertySetter.java.patch
>
>
> I saw following log
> 2014-12-30 11:42:44,937 [main] WARN
> org.apache.commons.jcs.utils.config.PropertySetter - Failed to set property
> eventQueueType to value "POOLED". Conversion to type [class
> org.apache.commons.jcs.engine.behavior.ICacheEventQueue$QueueType] failed.
> Looks like enum doesn't set properly
> Here is a patch
> Index: PropertySetter.java
> ===
> --- PropertySetter.java (revision 1648479)
> +++ PropertySetter.java (working copy)
> @@ -263,6 +263,19 @@
> return Boolean.FALSE;
> }
> }
> +else if( type.isEnum() )
> +{
> +try
> +{
> +@SuppressWarnings("unchecked")
> +Class cl = (Class) Class.forName(type.getName());
> +return Enum.valueOf( cl, v );
> +}
> +catch(Exception e)
> +{
> +e.printStackTrace();
> +}
> +}
> else if ( File.class.isAssignableFrom( type ) )
> {
> return new File( v );
> Thanks
> Youngho
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCS-139) PropertySetter doesn't set Enum properly
Youngho Cho created JCS-139:
---
Summary: PropertySetter doesn't set Enum properly
Key: JCS-139
URL: https://issues.apache.org/jira/browse/JCS-139
Project: Commons JCS
Issue Type: Bug
Affects Versions: jcs-2.0
Reporter: Youngho Cho
I saw following log
2014-12-30 11:42:44,937 [main] WARN
org.apache.commons.jcs.utils.config.PropertySetter - Failed to set property
eventQueueType to value "POOLED". Conversion to type [class
org.apache.commons.jcs.engine.behavior.ICacheEventQueue$QueueType] failed.
Looks like enum doesn't set properly
Here is a patch
Index: PropertySetter.java
===
--- PropertySetter.java (revision 1648479)
+++ PropertySetter.java (working copy)
@@ -263,6 +263,19 @@
return Boolean.FALSE;
}
}
+else if( type.isEnum() )
+{
+try
+{
+@SuppressWarnings("unchecked")
+Class cl = (Class) Class.forName(type.getName());
+return Enum.valueOf( cl, v );
+}
+catch(Exception e)
+{
+e.printStackTrace();
+}
+}
else if ( File.class.isAssignableFrom( type ) )
{
return new File( v );
Thanks
Youngho
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-428) Unsuccessful Connection enlistment in XA Transaction ignored by TransactionContext
[ https://issues.apache.org/jira/browse/DBCP-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-428: - Fix Version/s: 2.1 > Unsuccessful Connection enlistment in XA Transaction ignored by > TransactionContext > -- > > Key: DBCP-428 > URL: https://issues.apache.org/jira/browse/DBCP-428 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4, 2.0.1 > Environment: All >Reporter: Vladimir Konkov >Priority: Critical > Fix For: 2.1 > > Attachments: DBCP-428.diff > > > When TransactionContext call 'enlistResource()' on Transaction it is ignored > returned result. This hapens at least when XAResource throws XAException in > enlistResource method. By contract XAException should not be propagated by > 'enlistResource()' , instead 'false' is returned. > As result: > 1. ManagedConnection returned by pool is not enlisted in transaction > (application think it does) > 2. Transaction itself marked for rollback (because of XaException). > 3. ManagedConnection returned by pool used by application without any errors > until commit on transaction is called. Changes made in not enlisted > connection may be commited on other use of native connection or rolled back > depending on pool config. > Issue is very dangerous especialy if changed made by application will be > commited later but XA transaction in witch it made has bin rolled back. > We are hit by this bug in production using MS SQL Server and PostgreSQL JDBC > drivers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-117) SofnSegment.components - public mutable array
[ https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260175#comment-14260175 ] Sebb commented on IMAGING-117: -- Have fixed all the entries previously mentioned in the issue. However, I could not fix: ColorGroup.color_counts - List is sorted multiple times, so cannot be made read-only > SofnSegment.components - public mutable array > - > > Key: IMAGING-117 > URL: https://issues.apache.org/jira/browse/IMAGING-117 > Project: Commons Imaging > Issue Type: Bug >Reporter: Sebb >Priority: Blocker > Fix For: Patch Needed, 1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO
[ https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260117#comment-14260117 ] Stefan Bodewig commented on IMAGING-126: I won't comment on the real issue since I never looked at Imaging's code at all. [~damjan] has modified Compress' LZW implementation so it becomes a better fit for Imaging[1] - it's inside Compress' trunk and the next release (1.10) shouldn't be too far away. I have no idea how it compares to the existing LZW implementation. [1] http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/compressors/lzw/LZWInputStream.java?view=log > TIFF and PNG images should not be bigger than the ones created by java ImageIO > -- > > Key: IMAGING-126 > URL: https://issues.apache.org/jira/browse/IMAGING-126 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG, Format: TIFF >Affects Versions: 1.0 > Environment: W7 >Reporter: Tilman Hausherr >Priority: Minor > Fix For: Discussion > > Attachments: Imaging_126_patch_1.patch, pdfbox-1870-devicen3-01.png, > pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png, > pdfbox-1870-devicen3.pdf-1.tif > > > I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of > problems with setting the tiff resolution in java imageio. > While the code is pretty nice, I found that the generated images are > sometimes much bigger in size than the ones generated by java imageio. > Example: > pdfbox-1870-devicen3-01.png 50 KB (imageio) > pdfbox-1870-devicen3.pdf-1.png 70 KB (imaging) > pdfbox-1870-devicen3-01.tif 401 KB (imageio) > pdfbox-1870-devicen3.pdf-1.tif 1063 KB (imaging) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO
[ https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260103#comment-14260103 ] Gary Lucas commented on IMAGING-126: Well, first off, switching to Compress is an interesting side issue, not the key question raised by this particular tracker item. So let me talk about the code change involved in the size of the compressed images before moving on to the question of using Compress. In terms of the image size... I did some work on this a year ago, but got busy with other things and let the matter drop. Basically, the issue comes down to the size of a memory allocation used to compress and decompress an image. This memory holds a "dictionary" of sorts which is used to encode and decode the image. The current size is 8K. A bigger size, say 32 K, achieves substantially better compression ratios and results in substantially smaller images. However, a bigger dictionary presents a larger search space for the compressor and slows things down. In testing with the existing code I found that 32 K was a reasonable compromise... It didn't make things as small as I'd wish, but it didn't increase the run time to an unacceptable degree. My gut instinct is to simply make 32K be the default and be done with it. Some of the others who joined the discussion pointed out that this would change the behavior of the existing code and might interfere with existing applications. So, what I would propose as an alternate is to offer a new option for the "parameters" passed to the Imaging.writeImage() methods. This would involve defining a key/value pair defined in the TiffConstants class which could be passed in to control compression. This would require extra knowledge on the part of person writing application code to employ a feature that he would almost always want, but has the advantage of preserving the existing behavior. But I do think it's a reasonable approach. So, if you are looking to wrap things up and put out a release, I will give this some attention and prepare a patch for you. Is there a consensus on approach? -- Now, on to the discussion of Compress. There are tradeoffs involved in adding a cross-project dependency. So if we're thinking about doing that, let's be sure we've considered all the issues and have determined that it is a good idea. I will briefly consider both the pro's and con's. First the con's: Right now, all you have to do to use Apache Commons Imaging is download one jar file. Introducing cross dependencies to the build will complicate its use and management for anyone who wants to use the code. Also, when I looked at this last year, Compress was not a perfect fit with the LZW compression used in the TIFF format. Unless things have changed since then (which is entirely possible), the Compress code would require some modifications to present a more general-purpose solution that could be used for Imaging. Also, the current solution in Imaging does work, so it's not as if it has bugs that need to be fixed. Now the pro's: One of the issues I mentioned above with the increase in the size of the memory used for the compression "dictionary" is the increase in compression time (and decompression time too?) related to the larger search space. If Compress implements a more advanced compression implementation that improves performance, that would be a motivation for adopting it. I don't think that anyone would argue against the idea that, in general, it is better not to maintain redundant implementations of anything. On the other hand, sometimes you have a need that is just specialized enough that maintaining a single code base becomes problematic. We might be looking at just such a case here. > TIFF and PNG images should not be bigger than the ones created by java ImageIO > -- > > Key: IMAGING-126 > URL: https://issues.apache.org/jira/browse/IMAGING-126 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG, Format: TIFF >Affects Versions: 1.0 > Environment: W7 >Reporter: Tilman Hausherr >Priority: Minor > Fix For: Discussion > > Attachments: Imaging_126_patch_1.patch, pdfbox-1870-devicen3-01.png, > pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png, > pdfbox-1870-devicen3.pdf-1.tif > > > I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of > problems with setting the tiff resolution in java imageio. > While the code is pretty nice, I found that the generated images are > sometimes much bigger in size than the ones generated by java imageio. > Example: > pdfbox-1870-devicen3-01.png 50 KB (imageio) > p
[jira] [Created] (IMAGING-147) Color constants
Benedikt Ritter created IMAGING-147: --- Summary: Color constants Key: IMAGING-147 URL: https://issues.apache.org/jira/browse/IMAGING-147 Project: Commons Imaging Issue Type: Improvement Components: imaging.color.* Reporter: Benedikt Ritter Fix For: Patch Needed The Color classes should provide constants for useful colors like black, white and maybe their base colors. For example ColorRgb could provide Constants for red, green and blue ColorRgb objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-146) Add documentation for the color package
[ https://issues.apache.org/jira/browse/IMAGING-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-146: Component/s: imaging.color.* > Add documentation for the color package > --- > > Key: IMAGING-146 > URL: https://issues.apache.org/jira/browse/IMAGING-146 > Project: Commons Imaging > Issue Type: Improvement > Components: Documentation, imaging.color.* >Reporter: Benedikt Ritter > Fix For: Patch Needed > > > The color package has almost no documentation. Each Color should have > documentation describing its components and probably a wikipedia link or a > link to the ISO norm/standard describing the color. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IMAGING-146) Add documentation for the color package
Benedikt Ritter created IMAGING-146: --- Summary: Add documentation for the color package Key: IMAGING-146 URL: https://issues.apache.org/jira/browse/IMAGING-146 Project: Commons Imaging Issue Type: Improvement Components: Documentation Reporter: Benedikt Ritter Fix For: Patch Needed The color package has almost no documentation. Each Color should have documentation describing its components and probably a wikipedia link or a link to the ISO norm/standard describing the color. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-117) SofnSegment.components - public mutable array
[ https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260070#comment-14260070 ] Sebb commented on IMAGING-117: -- Apart from read-only collections, arrays can be made read-only by providing a getter for the individual entries. Alternatively, the array holder can provide an interface to process entries. In any case, mutable fields should never be exposed. Code should always use a getter/setter as that allows synchronisation to be easily added. Even if the getter/setter does not copy the array it provides better encapsulation, and allows for changes of implementation without affecting callers. > SofnSegment.components - public mutable array > - > > Key: IMAGING-117 > URL: https://issues.apache.org/jira/browse/IMAGING-117 > Project: Commons Imaging > Issue Type: Bug >Reporter: Sebb >Priority: Blocker > Fix For: Patch Needed, 1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1079) BUG -Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') ClassUtils
[
https://issues.apache.org/jira/browse/LANG-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-1079.
---
Resolution: Invalid
Fix Version/s: (was: 3.x)
Closing this as invalid.
> BUG -Use of Externally-Controlled Input to Select Classes or Code ('Unsafe
> Reflection') ClassUtils
> ---
>
> Key: LANG-1079
> URL: https://issues.apache.org/jira/browse/LANG-1079
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.x
>Reporter: David Camilo Espitia Manrique
>Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> we are currently using "commons-lang3-3.0" and in the analysis of veracode
> found this bug in "ClassUtils line 792":
> Description:
> A call uses reflection in an unsafe manner. An attacker can specify the class
> name to be instantiated, which may
> create unexpected control flow paths through the application. Depending on
> how reflection is being used, the attack
> vector may allow the attacker to bypass security checks or otherwise cause
> the application to behave in an unexpected
> manner. Even if the object does not implement the specified interface and a
> ClassCastException is thrown, the
> constructor of the user-supplied class name will have already executed.
> Recommendations:
> Validate the class name against a combination of white and black lists to
> ensure that only expected behavior is
> produced.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IMAGING-144) TiffOutputSet.setGPSInDegrees should make sure, GPSVersionID is set
[ https://issues.apache.org/jira/browse/IMAGING-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260054#comment-14260054 ] Benedikt Ritter commented on IMAGING-144: - Patches welcome! :-) > TiffOutputSet.setGPSInDegrees should make sure, GPSVersionID is set > --- > > Key: IMAGING-144 > URL: https://issues.apache.org/jira/browse/IMAGING-144 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Paul Hartmann >Priority: Minor > Fix For: Patch Needed > > > According to the EXIF specification, the field GPSVersionID is mandatory when > any gps information is present. > TiffOutputSet.setGPSInDegrees is a convenience method to set the location of > the image. It should make sure, that the field GPSVersionID is set. Otherwise > the resulting meta info will be invalid and some tools fail to read the > location. > See https://josm.openstreetmap.de/ticket/10745 for the original user report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-144) TiffOutputSet.setGPSInDegrees should make sure, GPSVersionID is set
[ https://issues.apache.org/jira/browse/IMAGING-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-144: Fix Version/s: Patch Needed > TiffOutputSet.setGPSInDegrees should make sure, GPSVersionID is set > --- > > Key: IMAGING-144 > URL: https://issues.apache.org/jira/browse/IMAGING-144 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Paul Hartmann >Priority: Minor > Fix For: Patch Needed > > > According to the EXIF specification, the field GPSVersionID is mandatory when > any gps information is present. > TiffOutputSet.setGPSInDegrees is a convenience method to set the location of > the image. It should make sure, that the field GPSVersionID is set. Otherwise > the resulting meta info will be invalid and some tools fail to read the > location. > See https://josm.openstreetmap.de/ticket/10745 for the original user report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-124) tidy up IconParser
[ https://issues.apache.org/jira/browse/IMAGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-124: Fix Version/s: Review > tidy up IconParser > -- > > Key: IMAGING-124 > URL: https://issues.apache.org/jira/browse/IMAGING-124 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: ICO >Affects Versions: 1.x >Reporter: Jens Kapitza >Priority: Minor > Fix For: Review > > Attachments: IcoImageParser.java.patch > > Original Estimate: 5m > Remaining Estimate: 5m > > small changes and tidy up (reduce lines) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-123) remove duplicated lines
[ https://issues.apache.org/jira/browse/IMAGING-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-123: Fix Version/s: Review > remove duplicated lines > --- > > Key: IMAGING-123 > URL: https://issues.apache.org/jira/browse/IMAGING-123 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Jens Kapitza >Priority: Minor > Labels: patch > Fix For: Review > > Attachments: T4AndT6Compression.java.patch > > Original Estimate: 10m > Remaining Estimate: 10m > > CDP message -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-142) TIFF image info can return first page only
[ https://issues.apache.org/jira/browse/IMAGING-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-142: Fix Version/s: Patch Needed > TIFF image info can return first page only > -- > > Key: IMAGING-142 > URL: https://issues.apache.org/jira/browse/IMAGING-142 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Josh Highley >Priority: Minor > Fix For: Patch Needed > > > Each page in a multi-page tiff can have it's own DPI, image size, compression > format, etc: each page has its own set of TIFF tags. The current methods to > for getting DPI and ImageInfo do not support specifying a page number for > multi-page image formats. The workaround is to duplicate the code used to > interpret the tags for page 0 for the page of interest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-128) TIFF Image Writer is not flushing output
[ https://issues.apache.org/jira/browse/IMAGING-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-128: Fix Version/s: Review > TIFF Image Writer is not flushing output > > > Key: IMAGING-128 > URL: https://issues.apache.org/jira/browse/IMAGING-128 > Project: Commons Imaging > Issue Type: Bug >Reporter: Gary Lucas >Priority: Minor > Fix For: Review > > Attachments: Imaging_128_Patch_1.patch > > > The writeImage() method in the TiffImageWriterBase class takes an > java.io.OutputStream argument as the destination for its output. It does not > explicitly call flush() on the output stream when it is finished writing > data. If the calling application allows the output stream to go out of > scope, rather than explicitly calling close(), any pending output will be > lost and the output image file will be left in a broken state. Although, > ideally, applications SHOULD explicitly call close() on an i/o file, we > should probably add a call to flush to the writeImage method to provide some > robustness. > This behavior was observed in Java 7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-125) Add missing Exif tags definition into ExifTagConstants
[ https://issues.apache.org/jira/browse/IMAGING-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-125: Fix Version/s: Patch Needed > Add missing Exif tags definition into ExifTagConstants > -- > > Key: IMAGING-125 > URL: https://issues.apache.org/jira/browse/IMAGING-125 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: TIFF >Affects Versions: 1.0 >Reporter: Olivier Voortman >Priority: Minor > Fix For: Patch Needed > > > There are some missing Tags in ExifTagConstants. > Like "Copyright", "Orientation" or "UniqueCameraModel". > See complete list on : http://www.exiv2.org/tags.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO
[ https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-126: Fix Version/s: Discussion Setting this to "Discussion" we need to decide what we want to do here. I think depending on Compress in 1.0 is a good idea because it will speed up the development. > TIFF and PNG images should not be bigger than the ones created by java ImageIO > -- > > Key: IMAGING-126 > URL: https://issues.apache.org/jira/browse/IMAGING-126 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG, Format: TIFF >Affects Versions: 1.0 > Environment: W7 >Reporter: Tilman Hausherr >Priority: Minor > Fix For: Discussion > > Attachments: Imaging_126_patch_1.patch, pdfbox-1870-devicen3-01.png, > pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png, > pdfbox-1870-devicen3.pdf-1.tif > > > I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of > problems with setting the tiff resolution in java imageio. > While the code is pretty nice, I found that the generated images are > sometimes much bigger in size than the ones generated by java imageio. > Example: > pdfbox-1870-devicen3-01.png 50 KB (imageio) > pdfbox-1870-devicen3.pdf-1.png 70 KB (imaging) > pdfbox-1870-devicen3-01.tif 401 KB (imageio) > pdfbox-1870-devicen3.pdf-1.tif 1063 KB (imaging) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-129) XMP metadata processing not well documented
[ https://issues.apache.org/jira/browse/IMAGING-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-129: Fix Version/s: Patch Needed > XMP metadata processing not well documented > --- > > Key: IMAGING-129 > URL: https://issues.apache.org/jira/browse/IMAGING-129 > Project: Commons Imaging > Issue Type: Bug > Components: Documentation >Reporter: christophe blin >Priority: Minor > Fix For: Patch Needed > > > Using commons-imaging-1.0-20140325.172317-8.jar > Using the image : > http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg > From the webpage : > http://www.controlledvocabulary.com/blog/top-metadata-myths.html > Code used : System.out.println(Imaging.getMetadata(new > File(filepath)).toString()); > Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is > processed. > Expected metadata to be found : > http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-129) XMP metadata processing not well documented
[ https://issues.apache.org/jira/browse/IMAGING-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-129: Affects Version/s: (was: 1.x) > XMP metadata processing not well documented > --- > > Key: IMAGING-129 > URL: https://issues.apache.org/jira/browse/IMAGING-129 > Project: Commons Imaging > Issue Type: Bug > Components: Documentation >Reporter: christophe blin >Priority: Minor > Fix For: Patch Needed > > > Using commons-imaging-1.0-20140325.172317-8.jar > Using the image : > http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg > From the webpage : > http://www.controlledvocabulary.com/blog/top-metadata-myths.html > Code used : System.out.println(Imaging.getMetadata(new > File(filepath)).toString()); > Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is > processed. > Expected metadata to be found : > http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-129) XMP metadata processing not well documented
[ https://issues.apache.org/jira/browse/IMAGING-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260051#comment-14260051 ] Benedikt Ritter commented on IMAGING-129: - Patches welcome :) > XMP metadata processing not well documented > --- > > Key: IMAGING-129 > URL: https://issues.apache.org/jira/browse/IMAGING-129 > Project: Commons Imaging > Issue Type: Bug > Components: Documentation >Reporter: christophe blin >Priority: Minor > Fix For: Patch Needed > > > Using commons-imaging-1.0-20140325.172317-8.jar > Using the image : > http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg > From the webpage : > http://www.controlledvocabulary.com/blog/top-metadata-myths.html > Code used : System.out.println(Imaging.getMetadata(new > File(filepath)).toString()); > Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is > processed. > Expected metadata to be found : > http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-135) "Getting started" should get people started
[
https://issues.apache.org/jira/browse/IMAGING-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260049#comment-14260049
]
Benedikt Ritter commented on IMAGING-135:
-
I'm wokring on the documentation currently.
> "Getting started" should get people started
> ---
>
> Key: IMAGING-135
> URL: https://issues.apache.org/jira/browse/IMAGING-135
> Project: Commons Imaging
> Issue Type: Bug
> Components: Documentation
>Reporter: Tilman Hausherr
>Assignee: Benedikt Ritter
>Priority: Minor
>
> On "Getting started" the link "download page"
> http://commons.apache.org/imaging/download_imaging.cgi
> does not offer downloads.
> The actual download page is probably
> https://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-imaging/1.0-SNAPSHOT/
> It might also be useful to show how to get the lib without building from
> source:
> {code}
>
>
> org.apache.commons
> commons-imaging
> 1.0-SNAPSHOT
>
>
>
>
>
> snapshots
>
> https://repository.apache.org/content/repositories/snapshots
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IMAGING-138) Provide some Ant tasks to perform image conversions
[ https://issues.apache.org/jira/browse/IMAGING-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260048#comment-14260048 ] Benedikt Ritter commented on IMAGING-138: - Sorry for the late reply. I'm just catching up with all the outstanding issues. I'm not fond this should be part of the core library. I've already thought about splitting the whole project up into several maven moduls, so that users can chose for example which formats they need instead of pulling the whole library in. An Ant task would fit into such a modular architecture. Since there is so much work to do before 1.0 I don't see the coming in 1.0. > Provide some Ant tasks to perform image conversions > --- > > Key: IMAGING-138 > URL: https://issues.apache.org/jira/browse/IMAGING-138 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: ICNS, Format: ICO >Reporter: Julien Gouesse >Priority: Minor > Fix For: Discussion > > > I suggest to add some Ant tasks to perform image conversions into Commons > Imaging, especially from/to formats that aren't supported by any known Java > library. I could have written a custom Ant task for my own project but I > think it would be better for this project. > In my case, I need to convert a PNG image into ICNS in order to use it as a > logo for a Mac application bundle and I use Ant as a build tool. As I don't > generate this bundle under Mac (I'm under Mageia Linux), I can't use Mac > build-in tools to create the .icns file and using external softwares to make > the conversion each time I modify the original logo is annoying. I'll > probably have the same problem with .ico files. > Please indicate how I should modify the Maven pom file in order to compile > the custom tasks and I'll be ready to contribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-138) Provide some Ant tasks to perform image conversions
[ https://issues.apache.org/jira/browse/IMAGING-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-138: Fix Version/s: Discussion > Provide some Ant tasks to perform image conversions > --- > > Key: IMAGING-138 > URL: https://issues.apache.org/jira/browse/IMAGING-138 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: ICNS, Format: ICO >Reporter: Julien Gouesse >Priority: Minor > Fix For: Discussion > > > I suggest to add some Ant tasks to perform image conversions into Commons > Imaging, especially from/to formats that aren't supported by any known Java > library. I could have written a custom Ant task for my own project but I > think it would be better for this project. > In my case, I need to convert a PNG image into ICNS in order to use it as a > logo for a Mac application bundle and I use Ant as a build tool. As I don't > generate this bundle under Mac (I'm under Mageia Linux), I can't use Mac > build-in tools to create the .icns file and using external softwares to make > the conversion each time I modify the original logo is annoying. I'll > probably have the same problem with .ico files. > Please indicate how I should modify the Maven pom file in order to compile > the custom tasks and I'll be ready to contribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-97) Fails to read most Sony A100 JPG files generated from Photoshop CS2
[ https://issues.apache.org/jira/browse/IMAGING-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-97: --- Fix Version/s: Patch Needed Feel free to contribute a patch for this. > Fails to read most Sony A100 JPG files generated from Photoshop CS2 > > > Key: IMAGING-97 > URL: https://issues.apache.org/jira/browse/IMAGING-97 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: JPEG >Affects Versions: 1.0 > Environment: Windows 7, JDK1.7, Imaging snapshot build from 20121013 >Reporter: William Saar > Fix For: Patch Needed > > Attachments: _DSC6099.jpg > > > This line fails with the exception at the bottom for most of my old JPG files > shot with a Sony A100, and sometimes processed by Photoshop CS2. I will > attach a failing file. > BufferedImage img = Imaging.getBufferedImage(compressedThumbnailData, > jpgDecodeParams); > where jpgDecodeParams are > ImagingConstants.BUFFERED_IMAGE_FACTORY, new RgbBufferedImageFactory() > ImagingConstants.PARAM_KEY_FORMAT, ImageFormat.IMAGE_FORMAT_JPEG > Exception: > org.apache.commons.imaging.ImageReadException: Invalid marker found in > entropy data > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:417) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:311) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:122) > at > org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:83) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:428) > at > org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:95) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1375) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1315) > at -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-102) TIFF parser does not support floating-point images
[ https://issues.apache.org/jira/browse/IMAGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-102: Fix Version/s: Patch Needed Not a show stopper for 1.0 > TIFF parser does not support floating-point images > -- > > Key: IMAGING-102 > URL: https://issues.apache.org/jira/browse/IMAGING-102 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Gary Lucas > Fix For: Patch Needed > > Attachments: Sample64BitFloatingPointPix451x337.tif > > > The TIFF specification defines a data form for storing pixels as either > 32-bit or 64-bit floating point values given in the IEEE 754 format. The > TIFF-6 specification is actually incomplete in this regard, but typically > such values are stored as data in the range [0,1] with (or other values > out of the range zero to one) used to indicate "no-data". Typically, values > are rendered in gray tones. The TIFF "SampleFormat" tag indicates when data > is encoded in this form. > Commons Imaging does not currently support data that uses the floating-point > sample format. It does define a constant in the TiffTagConstants.java file > which is named SAMPLE_FORMAT_VALUE_IEEE_FLOATING_POINT. But this constant is > not used in the code. > I propose to at least implement read-support for images in this format. I am > working to obtain permission to post a sample image which I will attach to > this tracker item in the future. > Currently, the TIFF parser provides output in the form of a BufferedImage. > For the initial implementation, I recommend staying with that convention and > resolving the floating point values to gray tones. Although this approach has > the disadvantage that it will not provide an API for extracting the original > floating-point values, it seems to me the safest tactic for an initial > implementation. > Development will require some caution to avoid degrading parser performance. > The BitImageStream.readBits() method which reads samples (pixels) from the > source data, currently returns the Java int type, which only supports 32 > bits. To support 64 bits, this function would have to return a Java long. > The development effort will require testing to ensure that making a change of > this type does not degrade performance for the mainstream TIFF data formats > (probably this is only an issue on 32-bit operating systems). > For those of you who are asking why someone would choose to store data using > floating-point values (at the cost of 64 bits per pixel)... I don't really > know. Putting aside the fact that it's in the spec (sort of) and somebody > wants me to plot data from such images, I would have to say the motivation > would probably be using TIFF files as a way of storing arbitrary data in > gridded fields. The proposed changes wouldn't satisfy their requirements, > but it is a first step in that direction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-103) Update Commons Imaging web page to represent current state of project
[ https://issues.apache.org/jira/browse/IMAGING-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260041#comment-14260041 ] Benedikt Ritter commented on IMAGING-103: - I'm working on the code currently. You can speed the release up by helping to fix outstanding issues ;-) > Update Commons Imaging web page to represent current state of project > - > > Key: IMAGING-103 > URL: https://issues.apache.org/jira/browse/IMAGING-103 > Project: Commons Imaging > Issue Type: Bug >Reporter: Gary Lucas > > I recommend that the project update the Commons Imaging web page to better > represent the project. I believe that currently it might discourage > developers who would otherwise be interested in using Commons Imaging. > Not only does the current text still refer to "Sanselan" but it also gives > the impression that the code base hasn't been updated since 2009. Also, I > would like to see the phrase "It's slow, consequently, but perfectly > portable" removed since the project has made considerable improvements in > performance over the last couple of years. > Finally, I'd like to see some of the links to the Issue Tracker and so forth > updated to point at the right place. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-106) Writing JPEG images is unsupported
[ https://issues.apache.org/jira/browse/IMAGING-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-106: Fix Version/s: Patch Needed Not a show stopper for 1.0 IMHO > Writing JPEG images is unsupported > -- > > Key: IMAGING-106 > URL: https://issues.apache.org/jira/browse/IMAGING-106 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: JPEG >Affects Versions: 1.0 > Environment: Windows 7, JDK 6, Commons Imaging svn version 1480454 >Reporter: raise > Fix For: Patch Needed > > > JpegImageParser didn't rewrite the writeImage method, this lead to that we > can not write BufferedImage to a jpeg file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-105) I am not seeing any method to rotate image based
[ https://issues.apache.org/jira/browse/IMAGING-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-105: Affects Version/s: Patch Needed Feel free to contribute a patch to add this functionality :) > I am not seeing any method to rotate image based > > > Key: IMAGING-105 > URL: https://issues.apache.org/jira/browse/IMAGING-105 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: JPEG >Affects Versions: Patch Needed >Reporter: Fazil Sharafudeen > > Hi, I have got the degree I have to rotate an image using the orientation > value > EXIF_TAG_ORIENTATION. But I am not seeing any sanselan inbuilt method I acn > use to rotate the image with this calculated degree. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-106) Writing JPEG images is unsupported
[ https://issues.apache.org/jira/browse/IMAGING-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260038#comment-14260038 ] Benedikt Ritter commented on IMAGING-106: - All unimplemented methods should throw UnsupportedOperationException. > Writing JPEG images is unsupported > -- > > Key: IMAGING-106 > URL: https://issues.apache.org/jira/browse/IMAGING-106 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: JPEG >Affects Versions: 1.0 > Environment: Windows 7, JDK 6, Commons Imaging svn version 1480454 >Reporter: raise > > JpegImageParser didn't rewrite the writeImage method, this lead to that we > can not write BufferedImage to a jpeg file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IMAGING-139) Invalid DPI value
[
https://issues.apache.org/jira/browse/IMAGING-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260036#comment-14260036
]
Benedikt Ritter commented on IMAGING-139:
-
Fix as not a problem and dead with the resolution unit = none properly in a
separate issue?
> Invalid DPI value
> --
>
> Key: IMAGING-139
> URL: https://issues.apache.org/jira/browse/IMAGING-139
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 0.97
>Reporter: prabu
> Attachments: 250dpi.jpg
>
>
> I have following code in my java program
> {code:java}
> final String IMAGE_PATH = "c:\\test\\250dpi.jpg";
> byte imageBytes[] = readImageBytes(IMAGE_PATH);
> final ImageInfo imageInfo = Sanselan.getImageInfo(imageBytes);
> final int physicalWidthDpi = imageInfo.getPhysicalWidthDpi();
> final int physicalHeightDpi = imageInfo.getPhysicalHeightDpi();
> System.out.println("physicalWidthDpi:"+physicalWidthDpi);
> {code}
> When I right click image it showing 250 DPI value,but above program returning
> DPI value -1.
> Not sure why?Can u please help how to get image correct DPI value.
> Attached image for your reference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IMAGING-141) BufferedImage from TIFF is always 24 or 32 bpp
[ https://issues.apache.org/jira/browse/IMAGING-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-141: Affects Version/s: (was: 1.x) Fix Version/s: Patch Needed > BufferedImage from TIFF is always 24 or 32 bpp > -- > > Key: IMAGING-141 > URL: https://issues.apache.org/jira/browse/IMAGING-141 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Reporter: Josh Highley > Fix For: Patch Needed > > > When getting a BufferedImage from a TIFF, TiffImageParser.getBufferedImage > gets the TIFF's BPP from the TIFF tags, but at the end > ImageBuilder.getBufferedImage() will always set the BufferedImage ColorModel > BPP to 32 for images with alpha and 24 bpp otherwise. Many TIFFs are 1 bpp > (G3 and G4) so the BufferedImage should also be 1 bpp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-139) Invalid DPI value
[
https://issues.apache.org/jira/browse/IMAGING-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated IMAGING-139:
Description:
I have following code in my java program
{code:java}
final String IMAGE_PATH = "c:\\test\\250dpi.jpg";
byte imageBytes[] = readImageBytes(IMAGE_PATH);
final ImageInfo imageInfo = Sanselan.getImageInfo(imageBytes);
final int physicalWidthDpi = imageInfo.getPhysicalWidthDpi();
final int physicalHeightDpi = imageInfo.getPhysicalHeightDpi();
System.out.println("physicalWidthDpi:"+physicalWidthDpi);
{code}
When I right click image it showing 250 DPI value,but above program returning
DPI value -1.
Not sure why?Can u please help how to get image correct DPI value.
Attached image for your reference.
was:
I have following code in my java program
final String IMAGE_PATH = "c:\\test\\250dpi.jpg";
byte imageBytes[] = readImageBytes(IMAGE_PATH);
final ImageInfo imageInfo = Sanselan.getImageInfo(imageBytes);
final int physicalWidthDpi = imageInfo.getPhysicalWidthDpi();
final int physicalHeightDpi = imageInfo.getPhysicalHeightDpi();
System.out.println("physicalWidthDpi:"+physicalWidthDpi);
When i right click image it showing 250 DPI value,but above program returning
DPI value -1.
Not sure why?Can u please help how to get image correct DPI value.
Attached image for your reference.
> Invalid DPI value
> --
>
> Key: IMAGING-139
> URL: https://issues.apache.org/jira/browse/IMAGING-139
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 0.97
>Reporter: prabu
> Attachments: 250dpi.jpg
>
>
> I have following code in my java program
> {code:java}
> final String IMAGE_PATH = "c:\\test\\250dpi.jpg";
> byte imageBytes[] = readImageBytes(IMAGE_PATH);
> final ImageInfo imageInfo = Sanselan.getImageInfo(imageBytes);
> final int physicalWidthDpi = imageInfo.getPhysicalWidthDpi();
> final int physicalHeightDpi = imageInfo.getPhysicalHeightDpi();
> System.out.println("physicalWidthDpi:"+physicalWidthDpi);
> {code}
> When I right click image it showing 250 DPI value,but above program returning
> DPI value -1.
> Not sure why?Can u please help how to get image correct DPI value.
> Attached image for your reference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IMAGING-112) JpegIptcRewriter.removeIPTC() does not remove all metadata
[ https://issues.apache.org/jira/browse/IMAGING-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-112: Fix Version/s: Patch Needed > JpegIptcRewriter.removeIPTC() does not remove all metadata > -- > > Key: IMAGING-112 > URL: https://issues.apache.org/jira/browse/IMAGING-112 > Project: Commons Imaging > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Xavier Dury > Fix For: Patch Needed > > Attachments: ImageTest.java > > > I'm trying to compute hashes from my images to detect duplicates. > To do so, I strip every metadata (like keywords I may have added) then > compute a CRC32. > My problem is that JpegIptcRewriter.removeIPTC() does not remove all metadata > as there is always a difference of 18 bytes (containing "Photoshop 3.0"). > So could it be possible to remove those 18 bytes as well in removeIPTC() so > that I can compute hashes? > Thanks, > Xavier -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-143) Decompression Exception of Tiff Group 3 with T4 Options = 4
[ https://issues.apache.org/jira/browse/IMAGING-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-143: Fix Version/s: Patch Needed > Decompression Exception of Tiff Group 3 with T4 Options = 4 > --- > > Key: IMAGING-143 > URL: https://issues.apache.org/jira/browse/IMAGING-143 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0 >Reporter: Josh Highley > Fix For: Patch Needed > > Attachments: group3test.tif > > > I have multiple tiff images that are causing an "ImageReadException: > Decompression error". All are Group 3 (T.4) encoded with T4Options tag value > 4 (zero fill to byte). Other Group 3 images without T4Options 4 work fine. > Stepping through Imaging 1.0 RC7, the hasFill boolean is being set properly > to true. The exception is thrown at the bottom of method HuffmanTree.java > decode(bitStream). Nothing is passed to this method indicating zero fill or > not. I will attach a test image that reproduces the issue. The stack trace: > Caused by: org.apache.commons.imaging.ImageReadException: Decompression error >at > org.apache.commons.imaging.common.itu_t4.T4AndT6Compression.decompressT4_1D(T4AndT6Compression.java:254) >at > org.apache.commons.imaging.formats.tiff.datareaders.DataReader.decompress(DataReader.java:163) >at > org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:216) >at > org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:676) >at > org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:161) >at > org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:478) >at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1379) >at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1293) >at > com.dstresearch.baseutils.ApacheImagingUtil.readImage(ApacheImagingUtil.java:157) >... 27 more > Caused by: org.apache.commons.imaging.common.itu_t4.HuffmanTreeException: > Invalid bit pattern >at > org.apache.commons.imaging.common.itu_t4.HuffmanTree.decode(HuffmanTree.java:89) >at > org.apache.commons.imaging.common.itu_t4.T4AndT6Compression.decompressT4_1D(T4AndT6Compression.java:240) >... 35 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IMAGING-111) Download links broken on Website
[ https://issues.apache.org/jira/browse/IMAGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved IMAGING-111. - Resolution: Fixed This problem seems to have been fixed. Looking at http://commons.apache.org/proper/commons-imaging/download_sanselan.cgi I can download the archives. > Download links broken on Website > > > Key: IMAGING-111 > URL: https://issues.apache.org/jira/browse/IMAGING-111 > Project: Commons Imaging > Issue Type: Bug > Environment: website >Reporter: Dan Litwiller > Labels: website > > Cannot download any archives for Sanselan/Imaging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-117) SofnSegment.components - public mutable array
[ https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-117: Priority: Blocker (was: Major) Fix Version/s: 1.0 Patch Needed > SofnSegment.components - public mutable array > - > > Key: IMAGING-117 > URL: https://issues.apache.org/jira/browse/IMAGING-117 > Project: Commons Imaging > Issue Type: Bug >Reporter: Sebb >Priority: Blocker > Fix For: Patch Needed, 1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-136) Imaging.getImageInfo() fails to read JPEG file
[
https://issues.apache.org/jira/browse/IMAGING-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated IMAGING-136:
Fix Version/s: Patch Needed
> Imaging.getImageInfo() fails to read JPEG file
> --
>
> Key: IMAGING-136
> URL: https://issues.apache.org/jira/browse/IMAGING-136
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0
>Reporter: Tilman Hausherr
> Fix For: Patch Needed
>
> Attachments: 1402522741337.jpg
>
>
> I get this with the attached file:
> {code}
> Exception in thread "main" java.io.IOException: Could not read block (block
> start: 20274, block length: 24267, data length: 7789).
> at
> org.apache.commons.imaging.common.bytesource.ByteSourceArray.getBlock(ByteSourceArray.java:47)
> at
> org.apache.commons.imaging.formats.tiff.TiffReader.getTiffRawImageData(TiffReader.java:445)
> at
> org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:222)
> at
> org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:120)
> at
> org.apache.commons.imaging.formats.tiff.TiffReader.readDirectories(TiffReader.java:113)
> at
> org.apache.commons.imaging.formats.tiff.TiffReader.read(TiffReader.java:425)
> at
> org.apache.commons.imaging.formats.tiff.TiffReader.readContents(TiffReader.java:417)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:123)
> at
> org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:220)
> at
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:355)
> at
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:312)
> at
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:725)
> at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:704)
> at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:678)
> at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:697)
> at com.mycompany.apacheimagingtest.App.main(App.java:17)
> {code}
> I don't need any EXIF data, so it would be nice to have a workaround that
> just gets me the basic information about the image, i.e. size, bits, and
> color type (ycck, cmyk).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IMAGING-127) API to get a single image should allow choosing which image
[ https://issues.apache.org/jira/browse/IMAGING-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-127: Fix Version/s: Patch Needed > API to get a single image should allow choosing which image > --- > > Key: IMAGING-127 > URL: https://issues.apache.org/jira/browse/IMAGING-127 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Trejkaz > Fix For: Patch Needed > > Attachments: june 1 part I.tif > > > getBufferedImage() only returns the first image. There should be a way to > retrieve any image by index (and by extension, an API to get the image count.) > getBufferedImages() cannot be used for large multi-page TIFF files, because > creating that many BufferedImage objects causes an OutOfMemoryError. > (For that matter, a method to get a scaled down copy would be useful as well, > as some formats can optimise that not to retrieve all the data, but also it > means you can reduce the memory usage for absolutely massive images.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-134) Invalid marker found in entropy data
[ https://issues.apache.org/jira/browse/IMAGING-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-134: Affects Version/s: (was: Patch Needed) > Invalid marker found in entropy data > > > Key: IMAGING-134 > URL: https://issues.apache.org/jira/browse/IMAGING-134 > Project: Commons Imaging > Issue Type: Bug > Components: Format: JPEG >Affects Versions: 1.0 >Reporter: John Hewson > Fix For: Patch Needed > > Attachments: image.jpeg > > > I'm getting the following exception when trying to read a JPEG: > Exception in thread "main" org.apache.commons.imaging.ImageReadException: > Invalid marker found in entropy data > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124) > at > org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436) > at > org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-134) Invalid marker found in entropy data
[ https://issues.apache.org/jira/browse/IMAGING-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-134: Fix Version/s: Patch Needed > Invalid marker found in entropy data > > > Key: IMAGING-134 > URL: https://issues.apache.org/jira/browse/IMAGING-134 > Project: Commons Imaging > Issue Type: Bug > Components: Format: JPEG >Affects Versions: 1.0 >Reporter: John Hewson > Fix For: Patch Needed > > Attachments: image.jpeg > > > I'm getting the following exception when trying to read a JPEG: > Exception in thread "main" org.apache.commons.imaging.ImageReadException: > Invalid marker found in entropy data > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124) > at > org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436) > at > org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-134) Invalid marker found in entropy data
[ https://issues.apache.org/jira/browse/IMAGING-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated IMAGING-134: Affects Version/s: Patch Needed > Invalid marker found in entropy data > > > Key: IMAGING-134 > URL: https://issues.apache.org/jira/browse/IMAGING-134 > Project: Commons Imaging > Issue Type: Bug > Components: Format: JPEG >Affects Versions: Patch Needed, 1.0 >Reporter: John Hewson > Attachments: image.jpeg > > > I'm getting the following exception when trying to read a JPEG: > Exception in thread "main" org.apache.commons.imaging.ImageReadException: > Invalid marker found in entropy data > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124) > at > org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80) > at > org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436) > at > org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378) > at > org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IMAGING-130) Reading of some GIF images throws java.io.IOException: AddStringToTable: codes: 4096 code_size: 12
[
https://issues.apache.org/jira/browse/IMAGING-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated IMAGING-130:
Fix Version/s: Patch Needed
> Reading of some GIF images throws java.io.IOException: AddStringToTable:
> codes: 4096 code_size: 12
> --
>
> Key: IMAGING-130
> URL: https://issues.apache.org/jira/browse/IMAGING-130
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: GIF
>Affects Versions: 1.0
> Environment: Oracle JRE 1.7.0_45 on Windows 7
> Oracle JRE 1.7.0_55-b13 on Debian 7.5
>Reporter: Dhyan Blum
> Fix For: Patch Needed
>
>
> Hi guys,
> for some GIF images Imaging.getBufferedImage(byte[] bytes) throws the
> following exception:
> {quote}
> java.io.IOException: AddStringToTable: codes: 4096 code_size: 12
> at
> org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.addStringToTable(MyLzwDecompressor.java:112)
> at
> org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.decompress(MyLzwDecompressor.java:168)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:388)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:251)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:455)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:435)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getBufferedImage(GifImageParser.java:646)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1292)
> {quote}
> I have the same problem when using ImageIO.read(). In my post on
> Stackoverflow (
> http://stackoverflow.com/questions/22259714/arrayindexoutofboundsexception-4096-while-reading-gif-file
> ) you will find an example image to reproduce the exception and a similar
> looking JDK bug report that I found using Google. Quote from the bug report:
> {quote}
> A DESCRIPTION OF THE PROBLEM :
> according to specification
> http://www.w3.org/Graphics/GIF/spec-gif89a.txt
> > There is not a requirement to send a clear code when the string table is
> > full.
> However, GIFImageReader requires the clear code when the string table is full.
> GIFImageReader violates the specification, clearly.
> In the real world, sometimes people finds such high compressed gif image.
> so you should fix this bug.
> {quote}
> I hope you will find this information helpful.
> Kind regards
> Dhyan
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IMAGING-132) Remove Exif, XMP and IPTC Metadata
[
https://issues.apache.org/jira/browse/IMAGING-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated IMAGING-132:
Fix Version/s: Patch Needed
> Remove Exif, XMP and IPTC Metadata
> --
>
> Key: IMAGING-132
> URL: https://issues.apache.org/jira/browse/IMAGING-132
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: JPEG
>Affects Versions: 1.0
> Environment: Windows
>Reporter: Jacinto Verdaguer
> Labels: performance
> Fix For: Patch Needed
>
>
> I need to delete all the metadata (Exif, IPTC and XMP) of many JPEG images.
> Is there a single command to do this?
> {code:java}
> public static void removeExifMetadata(final File jpegImageFile, final File
> dst, boolean exif, boolean xmp, boolean iptc) throws IOException,
> ImageReadException, ImageWriteException {
> OutputStream os = null;
> boolean canThrow = false;
> try {
> os = new FileOutputStream(dst);
> os = new BufferedOutputStream(os);
> if(exif)
> new ExifRewriter().removeExifMetadata(jpegImageFile, os);
> else if(iptc)
> new JpegIptcRewriter().removeIPTC(jpegImageFile, os);
> else if (xmp)
> new JpegXmpRewriter().removeXmpXml(jpegImageFile, os);
> canThrow = true;
> } finally {
> IoUtils.closeQuietly(canThrow, os);
> }
> }
> {code}
> This form seems too slow, involves reading and writing the file 3 times.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IMAGING-132) Remove Exif, XMP and IPTC Metadata
[
https://issues.apache.org/jira/browse/IMAGING-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated IMAGING-132:
Description:
I need to delete all the metadata (Exif, IPTC and XMP) of many JPEG images.
Is there a single command to do this?
{code:java}
public static void removeExifMetadata(final File jpegImageFile, final File dst,
boolean exif, boolean xmp, boolean iptc) throws IOException,
ImageReadException, ImageWriteException {
OutputStream os = null;
boolean canThrow = false;
try {
os = new FileOutputStream(dst);
os = new BufferedOutputStream(os);
if(exif)
new ExifRewriter().removeExifMetadata(jpegImageFile, os);
else if(iptc)
new JpegIptcRewriter().removeIPTC(jpegImageFile, os);
else if (xmp)
new JpegXmpRewriter().removeXmpXml(jpegImageFile, os);
canThrow = true;
} finally {
IoUtils.closeQuietly(canThrow, os);
}
}
{code}
This form seems too slow, involves reading and writing the file 3 times.
was:
I need to delete all the metadata (Exif, IPTC and XMP) of many JPEG images.
Is there a single command to do this?
public static void removeExifMetadata(final File jpegImageFile, final File dst,
boolean exif, boolean xmp, boolean iptc) throws IOException,
ImageReadException, ImageWriteException {
OutputStream os = null;
boolean canThrow = false;
try {
os = new FileOutputStream(dst);
os = new BufferedOutputStream(os);
if(exif)
new ExifRewriter().removeExifMetadata(jpegImageFile, os);
else if(iptc)
new JpegIptcRewriter().removeIPTC(jpegImageFile, os);
else if (xmp)
new JpegXmpRewriter().removeXmpXml(jpegImageFile, os);
canThrow = true;
} finally {
IoUtils.closeQuietly(canThrow, os);
}
}
This form seems too slow, involves reading and writing the file 3 times.
> Remove Exif, XMP and IPTC Metadata
> --
>
> Key: IMAGING-132
> URL: https://issues.apache.org/jira/browse/IMAGING-132
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: JPEG
>Affects Versions: 1.0
> Environment: Windows
>Reporter: Jacinto Verdaguer
> Labels: performance
> Fix For: Patch Needed
>
>
> I need to delete all the metadata (Exif, IPTC and XMP) of many JPEG images.
> Is there a single command to do this?
> {code:java}
> public static void removeExifMetadata(final File jpegImageFile, final File
> dst, boolean exif, boolean xmp, boolean iptc) throws IOException,
> ImageReadException, ImageWriteException {
> OutputStream os = null;
> boolean canThrow = false;
> try {
> os = new FileOutputStream(dst);
> os = new BufferedOutputStream(os);
> if(exif)
> new ExifRewriter().removeExifMetadata(jpegImageFile, os);
> else if(iptc)
> new JpegIptcRewriter().removeIPTC(jpegImageFile, os);
> else if (xmp)
> new JpegXmpRewriter().removeXmpXml(jpegImageFile, os);
> canThrow = true;
> } finally {
> IoUtils.closeQuietly(canThrow, os);
> }
> }
> {code}
> This form seems too slow, involves reading and writing the file 3 times.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
