[jira] [Resolved] (IMAGING-173) This image format (Jpeg-Custom) cannot be written.
[
https://issues.apache.org/jira/browse/IMAGING-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-173.
Resolution: Cannot Reproduce
Marking as cannot reproduce due to lack of test input file. Feel free to
re-open if the issue still happens with latest release.
> This image format (Jpeg-Custom) cannot be written.
> --
>
> Key: IMAGING-173
> URL: https://issues.apache.org/jira/browse/IMAGING-173
> Project: Commons Imaging
> Issue Type: Bug
>Reporter: Marco Paciucci
>Priority: Major
>
> Hello everyone,
> I've coded the following:
> {code:java}
> bufferedImage = Imaging.getBufferedImage(imageDataBytes);
> final ImageFormat format = Imaging.guessFormat(imageDataBytes);
> String extension = format.getName();
> String imageId = imageName + randomInt + "." + extension;
> File imageFile = new File(imageId);
> final Map optionalParams = new HashMap();
> Imaging.writeImage(bufferedImage, imageFile, ImageFormats.JPEG,
> optionalParams);
> {code}
> This last line breaks and raises the issue above:
> This image format (Jpeg-Custom) cannot be written.
> Is this a bug?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IMAGING-210) Imaging.getBufferedImage fails throwing NegativeArraySizeException for specific inputs -- evintila-april_dynamics
[
https://issues.apache.org/jira/browse/IMAGING-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-210:
---
Assignee: Bruno P. Kinoshita
> Imaging.getBufferedImage fails throwing NegativeArraySizeException for
> specific inputs -- evintila-april_dynamics
> -
>
> Key: IMAGING-210
> URL: https://issues.apache.org/jira/browse/IMAGING-210
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha1
> Environment: Ubuntu 17.10
>Reporter: Emanuel Vintila
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Labels: patch, security
>
> For specific inputs, Imaging.getBufferedImage fails throwing
> java.lang.NegativeArraySizeException, instead of ImageReadException or
> IOException.
> Example code that can be used to reproduce the problem, with "testfile" found
> at this link
> [https://drive.google.com/open?id=1GYB3ArNv8fk9NUes0wTQ2vioy4iMfmeR]:
> // evintila @ April Dynamics
> File file = new File("testfile");
> final Map params = new HashMap<>();
> params.put(ImagingConstants.BUFFERED_IMAGE_FACTORY,
> new ManagedImageBufferedImageFactory());
>
> try
> {
> // the problem is here:
> final BufferedImage image = Imaging.getBufferedImage(file, params);
> } catch (ImageReadException e)
> {
>
> } catch (IOException e)
> {
>
> }
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (LANG-1476) Use synchronise on a set created with Collections.synchronizedSet before iterating
Bruno P. Kinoshita created LANG-1476:
Summary: Use synchronise on a set created with
Collections.synchronizedSet before iterating
Key: LANG-1476
URL: https://issues.apache.org/jira/browse/LANG-1476
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.9
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita
Fix For: 3.10
Placeholder for PR created in GitHub.
Link to Java docs:
https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#synchronizedSet-java.util.Set-
>It is imperative that the user manually synchronize on the returned collection
>when traversing it via
>[{{Iterator}}|https://docs.oracle.com/javase/9/docs/api/java/util/Iterator.html],
>
>[{{Spliterator}}|https://docs.oracle.com/javase/9/docs/api/java/util/Spliterator.html]
> or
>[{{Stream}}|https://docs.oracle.com/javase/9/docs/api/java/util/stream/Stream.html]:
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (LANG-1476) Use synchronise on a set created with Collections.synchronizedSet before iterating
[
https://issues.apache.org/jira/browse/LANG-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved LANG-1476.
--
Resolution: Fixed
> Use synchronise on a set created with Collections.synchronizedSet before
> iterating
> --
>
> Key: LANG-1476
> URL: https://issues.apache.org/jira/browse/LANG-1476
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 3.10
>
>
> Placeholder for PR created in GitHub.
> Link to Java docs:
> https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#synchronizedSet-java.util.Set-
> >It is imperative that the user manually synchronize on the returned
> >collection when traversing it via
> >[{{Iterator}}|https://docs.oracle.com/javase/9/docs/api/java/util/Iterator.html],
> >
> >[{{Spliterator}}|https://docs.oracle.com/javase/9/docs/api/java/util/Spliterator.html]
> > or
> >[{{Stream}}|https://docs.oracle.com/javase/9/docs/api/java/util/stream/Stream.html]:
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1460) Trivial: year of release for 3.9 says 2018, should be 2019
[
https://issues.apache.org/jira/browse/LANG-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1460:
-
Assignee: Bruno P. Kinoshita
> Trivial: year of release for 3.9 says 2018, should be 2019
> --
>
> Key: LANG-1460
> URL: https://issues.apache.org/jira/browse/LANG-1460
> Project: Commons Lang
> Issue Type: Bug
> Components: Website
>Affects Versions: 3.9
>Reporter: Larry West
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Original Estimate: 1h
> Time Spent: 40m
> Remaining Estimate: 20m
>
> The [Release
> History|https://commons.apache.org/proper/commons-lang/release-history.html]
> says {{2018-04-09}} for version 3.9, but the correct year is {{2019}}.
> Change submitted in [PR#427|https://github.com/apache/commons-lang/pull/427].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (LANG-1460) Trivial: year of release for 3.9 says 2018, should be 2019
[
https://issues.apache.org/jira/browse/LANG-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved LANG-1460.
--
Fix Version/s: 3.10
Resolution: Fixed
> Trivial: year of release for 3.9 says 2018, should be 2019
> --
>
> Key: LANG-1460
> URL: https://issues.apache.org/jira/browse/LANG-1460
> Project: Commons Lang
> Issue Type: Bug
> Components: Website
>Affects Versions: 3.9
>Reporter: Larry West
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.10
>
> Original Estimate: 1h
> Time Spent: 50m
> Remaining Estimate: 10m
>
> The [Release
> History|https://commons.apache.org/proper/commons-lang/release-history.html]
> says {{2018-04-09}} for version 3.9, but the correct year is {{2019}}.
> Change submitted in [PR#427|https://github.com/apache/commons-lang/pull/427].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915106#comment-16915106
]
Bruno P. Kinoshita commented on LANG-1478:
--
Oh, I see what you mean.
{code:java}
System.out.println(ClassUtils.getAbbreviatedName("ab.de.Ghij",
className.length())); // 10
// prints a.de.Ghij {code}
So when you get the abbreviated name passing the exact length of the class
name, it is indeed one character short. I agree it is annoying having to use
`className.length() + 1`... but I suspect we could have some users using it.
I will approve the PR, but will ask in the mailing list before merging it
first, to check whether we will need to wait for a major release - as this
could break someone else's code.
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Peter Verhas
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler. (See LANG-1480.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1475) StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915133#comment-16915133
]
Bruno P. Kinoshita commented on LANG-1475:
--
Thanks for updating the ticket [~Tai] (I had completely forgotten about it).
I've moved it back to Resolved/Fixed.
Normally issues are moved to Closed after the release happens.
> StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
> --
>
> Key: LANG-1475
> URL: https://issues.apache.org/jira/browse/LANG-1475
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Silence Tai
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 3.10
>
> Original Estimate: 10m
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Call
> {code:java} StringUtils.unwrap("a", 'a'); {code}
> or
> {code:java} StringUtils.unwrap("a", "a"); {code}
> Throw Exception:
> *java.lang.StringIndexOutOfBoundsException: begin 1, end 0, length 1*
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (LANG-1475) StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved LANG-1475.
--
Resolution: Fixed
> StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
> --
>
> Key: LANG-1475
> URL: https://issues.apache.org/jira/browse/LANG-1475
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Silence Tai
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 3.10
>
> Original Estimate: 10m
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Call
> {code:java} StringUtils.unwrap("a", 'a'); {code}
> or
> {code:java} StringUtils.unwrap("a", "a"); {code}
> Throw Exception:
> *java.lang.StringIndexOutOfBoundsException: begin 1, end 0, length 1*
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Reopened] (LANG-1475) StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita reopened LANG-1475:
--
Assignee: Bruno P. Kinoshita
> StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
> --
>
> Key: LANG-1475
> URL: https://issues.apache.org/jira/browse/LANG-1475
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Silence Tai
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 3.10
>
> Original Estimate: 10m
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Call
> {code:java} StringUtils.unwrap("a", 'a'); {code}
> or
> {code:java} StringUtils.unwrap("a", "a"); {code}
> Throw Exception:
> *java.lang.StringIndexOutOfBoundsException: begin 1, end 0, length 1*
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1478:
-
Assignee: Bruno P. Kinoshita
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler. (See LANG-1480.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1478:
-
Affects Version/s: 3.9
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler. (See LANG-1480.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1480:
-
Assignee: Bruno P. Kinoshita
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 1h 20m
> Remaining Estimate: 22h 40m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915110#comment-16915110
]
Bruno P. Kinoshita commented on LANG-1480:
--
See comment for LANG-1478, on whether this should go in 4.x release line, or
3.x. The answer for that in LANG-1478, applies here as well IMO.
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 1h 20m
> Remaining Estimate: 22h 40m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915109#comment-16915109
]
Bruno P. Kinoshita commented on LANG-1478:
--
Sent a message to the mailing list, asking whether this needs to go in 4.x, or
if we can include in the next 3.x release.
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler. (See LANG-1480.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915512#comment-16915512
]
Bruno P. Kinoshita commented on LANG-1478:
--
It was pointed in the mailing list that this is actually fixing the behavior of
the class, and matching with what is described in the documentation.
So once the PR comments are addressed, it's ready to be included in the next
release.
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler. (See LANG-1480.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915513#comment-16915513
]
Bruno P. Kinoshita commented on LANG-1480:
--
Peter, if this is fixing the code, and bringing the code closer to the
documentation, then it should be good to go in the next release.
I think I left some comments in the pull request. If you could go through them
and make sure the Travis build is passing, I will re-read the documentation and
see if we can include in the next release.
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 1h 20m
> Remaining Estimate: 22h 40m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IMAGING-168) IPTC parser should use CodedCharacterSet tag to determine encoding of the IPTC tag values
[ https://issues.apache.org/jira/browse/IMAGING-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-168: --- Assignee: Bruno P. Kinoshita > IPTC parser should use CodedCharacterSet tag to determine encoding of the > IPTC tag values > - > > Key: IMAGING-168 > URL: https://issues.apache.org/jira/browse/IMAGING-168 > Project: Commons Imaging > Issue Type: Bug > Components: Format: JPEG >Reporter: sudeep khemka >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: Review Patch > > Attachments: codedCharacterSet.patch > > Time Spent: 2h 40m > Remaining Estimate: 0h > > The IPTC CodedCharacterSet tag can be used to specify the encoding of the > IPTC tag values. But the setting is currently ignored. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IMAGING-234) Unable to get ImageMetadata from JPEG file
[
https://issues.apache.org/jira/browse/IMAGING-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894391#comment-16894391
]
Bruno P. Kinoshita commented on IMAGING-234:
Oh, still debugging, looks like the segment size could be wrong, and we could
be 2 bytes shorter. So the -1 values returned by InputStream.read() are
actually just because the stream is empty.
> Unable to get ImageMetadata from JPEG file
> --
>
> Key: IMAGING-234
> URL: https://issues.apache.org/jira/browse/IMAGING-234
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: Michelle Cabahug
>Priority: Major
> Attachments: 20190725_102443_t.jpg
>
>
> Imaging.getMetadata() API is failing for JPEG image file (see attached)
> Error message:
> {code:java}
> 07-25 12:06:54.034 4495 4660 W ExifHelper: Error getting exif metadata from
> 20190725_114523_t.jpg
> 07-25 12:06:54.040 4495 4660 W ExifHelper: Exception: java.io.IOException:
> Not a Valid TIFF File
> {code}
>
> Code:
> {code:java}
> try {
> Map params = new HashMap();
> params.put(ImagingConstants.PARAM_KEY_READ_THUMBNAILS, Boolean.FALSE);
> params.put(ImagingConstants.PARAM_KEY_STRICT, Boolean.FALSE);
> ImageMetadata metadata = Imaging.getMetadata(jpegFile);
> JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
> if (jpegMetadata != null) {
> return jpegMetadata.getExif();
> }
> } catch (Exception e) {
> Log.w(TAG, "Error getting exif metadata from " +
> jpegFile.getAbsolutePath());
> Log.w(TAG, "Exception: " + e);
> }
> {code}
>
> jhove output:
> {code:java}
> ❯ ./jhove 20190725_102443_t.jpg
> Jhove (Rel. 1.22.1, 2019-04-17)
> Date: 2019-07-25 11:54:41
> EDT RepresentationInformation: 20190725_102443_t.jpg
> ReportingModule: BYTESTREAM, Rel. 1.4 (2018-10-01)
> LastModified: 2019-07-25 10:27:40 EDT Size: 18212
> Format: bytestream
> Status: Well-Formed and valid
> SignatureMatches: JPEG-hul MIMEtype: application/octet-stream
> {code}
>
> exiftool output:
> {code:java}
> ❯ exiftool -api validate=2 20190725_102443_t.jpg
> ExifTool Version Number : 11.50
> File Name : 20190725_102443_t.jpg
> Directory : .
> File Size : 18 kB
> File Modification Date/Time : 2019:07:25 10:27:40-04:00
> File Access Date/Time : 2019:07:25 11:31:49-04:00
> File Inode Change Date/Time : 2019:07:25 10:27:40-04:00
> File Permissions : rw-r--r--
> File Type : JPEG
> File Type Extension : jpg
> MIME Type : image/jpeg
> Exif Byte Order : Big-endian (Motorola, MM)
> Image Description : shawty snap
> X Resolution : 72
> Y Resolution : 72
> Resolution Unit : inches
> Y Cb Cr Positioning : Centered
> Exif Version : 0210
> Components Configuration : Y, Cb, Cr, -
> Flashpix Version : 0100
> Color Space : Uncalibrated
> Exif Image Width : 0
> Exif Image Height : 0
> Image Width : 423
> Image Height : 238
> Encoding Process : Baseline DCT, Huffman coding
> Bits Per Sample : 8
> Color Components : 3
> Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
> Image Size : 423x238
> Megapixels : 0.101{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IMAGING-234) Unable to get ImageMetadata from JPEG file
[
https://issues.apache.org/jira/browse/IMAGING-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894362#comment-16894362
]
Bruno P. Kinoshita commented on IMAGING-234:
Hi,
Thanks for the code and information provided for this issue, especially the
example file.
Successfully reproduced it. Went with a debugger examining each directory and
field in the image, and the EXIF metadata is correctly parsed... up until all
the fields were processed.
At this point, according to the standard, we should get a "Next IFD" that has 4
bytes 0 0 0 0. For some reason Imaging is getting 0 0 -1 -1. Looking at the
HTML output of exiftool, it looks like it got 00 00 00 00... not sure where the
-1 -1 (FF FF) are coming from.
Tried running exiftool with some different settings to see if there was any
warning hidden, but no luck. My guess now is that hopefully there is either a
new addendum to the specification that says that it's fine to get only 2 bytes,
or maybe that we should ignore if the Next IFD is not valid.
Commenting the code where the exception is thrown, it looks like the rest of
the file is parsed successfully.
> Unable to get ImageMetadata from JPEG file
> --
>
> Key: IMAGING-234
> URL: https://issues.apache.org/jira/browse/IMAGING-234
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: Michelle Cabahug
>Priority: Major
> Attachments: 20190725_102443_t.jpg
>
>
> Imaging.getMetadata() API is failing for JPEG image file (see attached)
> Error message:
> {code:java}
> 07-25 12:06:54.034 4495 4660 W ExifHelper: Error getting exif metadata from
> 20190725_114523_t.jpg
> 07-25 12:06:54.040 4495 4660 W ExifHelper: Exception: java.io.IOException:
> Not a Valid TIFF File
> {code}
>
> Code:
> {code:java}
> try {
> Map params = new HashMap();
> params.put(ImagingConstants.PARAM_KEY_READ_THUMBNAILS, Boolean.FALSE);
> params.put(ImagingConstants.PARAM_KEY_STRICT, Boolean.FALSE);
> ImageMetadata metadata = Imaging.getMetadata(jpegFile);
> JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
> if (jpegMetadata != null) {
> return jpegMetadata.getExif();
> }
> } catch (Exception e) {
> Log.w(TAG, "Error getting exif metadata from " +
> jpegFile.getAbsolutePath());
> Log.w(TAG, "Exception: " + e);
> }
> {code}
>
> jhove output:
> {code:java}
> ❯ ./jhove 20190725_102443_t.jpg
> Jhove (Rel. 1.22.1, 2019-04-17)
> Date: 2019-07-25 11:54:41
> EDT RepresentationInformation: 20190725_102443_t.jpg
> ReportingModule: BYTESTREAM, Rel. 1.4 (2018-10-01)
> LastModified: 2019-07-25 10:27:40 EDT Size: 18212
> Format: bytestream
> Status: Well-Formed and valid
> SignatureMatches: JPEG-hul MIMEtype: application/octet-stream
> {code}
>
> exiftool output:
> {code:java}
> ❯ exiftool -api validate=2 20190725_102443_t.jpg
> ExifTool Version Number : 11.50
> File Name : 20190725_102443_t.jpg
> Directory : .
> File Size : 18 kB
> File Modification Date/Time : 2019:07:25 10:27:40-04:00
> File Access Date/Time : 2019:07:25 11:31:49-04:00
> File Inode Change Date/Time : 2019:07:25 10:27:40-04:00
> File Permissions : rw-r--r--
> File Type : JPEG
> File Type Extension : jpg
> MIME Type : image/jpeg
> Exif Byte Order : Big-endian (Motorola, MM)
> Image Description : shawty snap
> X Resolution : 72
> Y Resolution : 72
> Resolution Unit : inches
> Y Cb Cr Positioning : Centered
> Exif Version : 0210
> Components Configuration : Y, Cb, Cr, -
> Flashpix Version : 0100
> Color Space : Uncalibrated
> Exif Image Width : 0
> Exif Image Height : 0
> Image Width : 423
> Image Height : 238
> Encoding Process : Baseline DCT, Huffman coding
> Bits Per Sample : 8
> Color Components : 3
> Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
> Image Size : 423x238
> Megapixels : 0.101{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (POOL-361) setTestOnCreate does not test on create
[
https://issues.apache.org/jira/browse/POOL-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated POOL-361:
Fix Version/s: 2.7.0
> setTestOnCreate does not test on create
> ---
>
> Key: POOL-361
> URL: https://issues.apache.org/jira/browse/POOL-361
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Pablo
>Priority: Major
> Fix For: 2.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When setting testOnCreate to true, I would expect for the validation to take
> place when an object is created, but apparently it does not.
> It only seems to be tested on borrow and when idle.
> This has a negative impact, because when new objects get created, since they
> are not tested they appear in the pool as idle.
> I'm trying to determine if the pool's health, but even though the pool
> reports idle objects they are botched instances.
> Also related to this issue, objects aren't actually created upfront. They
> seem to be created on first borrow or when timeBetweenEvictionRunMillis
> elapses.
> Environment (unimportant I think): 1.8.0_191, Ubuntu 18.04
> Test case:
>
> {code:java}
> public static void main(String[] args) throws Exception {
> PooledObjectFactory factory = new
> BasePooledObjectFactory() {
> public String create() throws Exception {
> String s = "Hello";
> System.out.println("Creating " + s);
> return s;
> }
> public void destroyObject(PooledObject p) throws
> Exception {
> System.out.println("Destroying " + p.getObject());
> }
> public boolean validateObject(PooledObject p) {
> System.out.println("Validating " + p.getObject());
> return super.validateObject(p);
> }
> public PooledObject wrap(String obj) {
> return new Wrapper(obj);
> }
> };
> GenericObjectPoolConfig socketPoolConfig = new
> GenericObjectPoolConfig();
> socketPoolConfig.setTestOnCreate(true);
> socketPoolConfig.setTestWhileIdle(false);
> GenericObjectPool objectPool = new
> GenericObjectPool(factory, socketPoolConfig);
> System.out.println("Pool created");
> String f1 = objectPool.borrowObject();
> System.out.println("Borrowed" + f1);
> objectPool.returnObject(f1);
> objectPool.close();
> System.out.println("Done");
> }{code}
>
>
> Expected result:
> {{ Pool created}}
> {{ Creating Hello}}
> {{ *Validating Hello*}}
> {{ Allocating Hello}}
> {{ BorrowedHello}}
> {{ DeallocatingHello}}
> {{ Destroying Hello}}
> {{ Done}}
>
> Actual result:
> {{ Pool created}}
> {{ Creating Hello}}
> {{ Allocating Hello}}
> {{ *Validating Hello*}}
> {{ BorrowedHello}}
> {{ DeallocatingHello}}
> {{ Destroying Hello}}
> {{ Done}}
>
> Or am I misunderstanding something?
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IMAGING-232) Close resources in XpmImageParser.java
[ https://issues.apache.org/jira/browse/IMAGING-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887663#comment-16887663 ] Bruno P. Kinoshita commented on IMAGING-232: Hi [~gopal008], unfortunately I am not able to reproduce this. You created this issue 6 days ago. The last modification in XpmImageParser is from May 16th this year. And the line 86 you mentioned appears to be something else: [https://github.com/apache/commons-imaging/blob/e6893414a699a5f2480f2d18dc9bc9e21a0cf15d/src/main/java/org/apache/commons/imaging/formats/xpm/XpmImageParser.java#L86] That change to use try-with-resources on all the streams was introduced in 2016: [https://github.com/apache/commons-imaging/commit/114cd8507f6bcc26d4b56bd53c88cd17ee31afbf#diff-f295ab2d366c58ffead715f1e97911da] So I suspect you used an invalid version with your scanner. Feel free to re-open in case this issue persists and you are able to point what version on master or on the last release tag has the issue. But please be aware that there is a [guideline for issues regarding securities|https://commons.apache.org/security.html] Bruno > Close resources in XpmImageParser.java > -- > > Key: IMAGING-232 > URL: https://issues.apache.org/jira/browse/IMAGING-232 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha1 >Reporter: Gopal Rao >Priority: Minor > > We use Veracode as the security tool to scan vulnerabilities in our > organization. Veracode raised an issue with improper closing of the buffered > reader. The class is XpmImageParser.java. The line number is 86. This refers > to the buffered reader. Can you please close this resource ? > h1. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (IMAGING-232) Close resources in XpmImageParser.java
[ https://issues.apache.org/jira/browse/IMAGING-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita closed IMAGING-232. -- Resolution: Not A Problem > Close resources in XpmImageParser.java > -- > > Key: IMAGING-232 > URL: https://issues.apache.org/jira/browse/IMAGING-232 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha1 >Reporter: Gopal Rao >Priority: Minor > > We use Veracode as the security tool to scan vulnerabilities in our > organization. Veracode raised an issue with improper closing of the buffered > reader. The class is XpmImageParser.java. The line number is 86. This refers > to the buffered reader. Can you please close this resource ? > h1. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (IMAGING-232) Close resources in XpmImageParser.java
[ https://issues.apache.org/jira/browse/IMAGING-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887663#comment-16887663 ] Bruno P. Kinoshita edited comment on IMAGING-232 at 7/18/19 6:15 AM: - Hi [~gopal008], unfortunately I am not able to reproduce this. You created this issue 6 days ago. The last modification in XpmImageParser is from May 16th this year. And the line 86 you mentioned appears to be something else: [https://github.com/apache/commons-imaging/blob/e6893414a699a5f2480f2d18dc9bc9e21a0cf15d/src/main/java/org/apache/commons/imaging/formats/xpm/XpmImageParser.java#L86] That change to use try-with-resources on all the streams was introduced in 2016: [https://github.com/apache/commons-imaging/commit/114cd8507f6bcc26d4b56bd53c88cd17ee31afbf#diff-f295ab2d366c58ffead715f1e97911da] So I suspect you used an invalid version with your scanner. Feel free to re-open in case this issue persists and you are able to point what version on master or on the last release tag has the issue. Bruno was (Author: kinow): Hi [~gopal008], unfortunately I am not able to reproduce this. You created this issue 6 days ago. The last modification in XpmImageParser is from May 16th this year. And the line 86 you mentioned appears to be something else: [https://github.com/apache/commons-imaging/blob/e6893414a699a5f2480f2d18dc9bc9e21a0cf15d/src/main/java/org/apache/commons/imaging/formats/xpm/XpmImageParser.java#L86] That change to use try-with-resources on all the streams was introduced in 2016: [https://github.com/apache/commons-imaging/commit/114cd8507f6bcc26d4b56bd53c88cd17ee31afbf#diff-f295ab2d366c58ffead715f1e97911da] So I suspect you used an invalid version with your scanner. Feel free to re-open in case this issue persists and you are able to point what version on master or on the last release tag has the issue. But please be aware that there is a [guideline for issues regarding securities|https://commons.apache.org/security.html] Bruno > Close resources in XpmImageParser.java > -- > > Key: IMAGING-232 > URL: https://issues.apache.org/jira/browse/IMAGING-232 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha1 >Reporter: Gopal Rao >Priority: Minor > > We use Veracode as the security tool to scan vulnerabilities in our > organization. Veracode raised an issue with improper closing of the buffered > reader. The class is XpmImageParser.java. The line number is 86. This refers > to the buffered reader. Can you please close this resource ? > h1. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IMAGING-231) Reading tiff with LZW compression results in mangled image
[
https://issues.apache.org/jira/browse/IMAGING-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887865#comment-16887865
]
Bruno P. Kinoshita commented on IMAGING-231:
Issue reproduced. And indeed seems to be related to LZW. Code used to reproduce
it:
{code:java}
package org.apache.commons.imaging;
import java.awt.image.BufferedImage;
import java.io.File;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class TTT {
public static void main(String[] args) throws Exception {
File f = new File("/home/kinow/Downloads/imaging/image_pages/A4.tiff");
ImageInfo imageInfo = Imaging.getImageInfo(f);
Map params = new HashMap<>();
if (imageInfo.getNumberOfImages() > 1) {
List allBufferedImages =
Imaging.getAllBufferedImages(f);
for (BufferedImage bufferedImage : allBufferedImages) {
//appendImagePage(bufferedImage);
Imaging.writeImage(bufferedImage, new File(f.getParent(), "" +
System.nanoTime()), ImageFormats.PNG,
new HashMap<>());
}
} else {
//appendImagePage(Imaging.getBufferedImage(imageBytes));
System.out.println("SINGLE PAGE!");
BufferedImage bufferedImage = Imaging.getBufferedImage(f, params);
Imaging.writeImage(bufferedImage, new File(f.getParent(), "" +
System.nanoTime()), ImageFormats.TIFF,
new HashMap<>());
}
}
}
{code}
Tested with ImageIO.write with the result BufferedReader, and got the same
issue. So the issue is not in our writer.
Tested with [ngageoint/tiff-java|[https://github.com/ngageoint/tiff-java],]
using just their LZW decoder, and got exact same image... so our LZW is
probably correct (or both incorrect).
Looked at the output of exiftool, and found nothing clearly wrong.
So it could still be something before the writer and decompressor, like the way
we read the data.
Thanks for the good issue description and the attachments. Hopefully we will
find what is wrong and include the fix in the next release.
Cheers
Bruno
> Reading tiff with LZW compression results in mangled image
> --
>
> Key: IMAGING-231
> URL: https://issues.apache.org/jira/browse/IMAGING-231
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1
>Reporter: Jimmy Merrild Krag
>Priority: Major
> Attachments: image_pages.zip, result.pdf
>
>
> I am trying to create a PDF using PDFbox with Commons Imaging for loading
> images. Commons imaging fixes most of the issues I have with the
> alternatives, but still cannot load my tiff files correctly.
> I have attached a resulting PDF as {{result.pdf}}.
> The files I use for testing, are attached in {{image_pages.zip}}. The
> tiff-files, which are not loaded correctly, are LZW-compressed, and that is
> the only difference I can find in the format.
> All images look the same if I save them to separate image files in another
> format, as they do in the PDF, so PDFbox does not seem to be the one to
> blame. My code for reading the files is pretty straightforward:
>
> {code:java}
> ImageInfo imageInfo = Imaging.getImageInfo(imageBytes);
> if (imageInfo.getNumberOfImages() > 1) {
> List allBufferedImages =
> Imaging.getAllBufferedImages(imageBytes);
> for (BufferedImage bufferedImage : allBufferedImages) {
> appendImagePage(bufferedImage);
> }
> } else {
> appendImagePage(Imaging.getBufferedImage(imageBytes));
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IMAGING-231) Reading tiff with LZW compression results in mangled image
[
https://issues.apache.org/jira/browse/IMAGING-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887865#comment-16887865
]
Bruno P. Kinoshita edited comment on IMAGING-231 at 7/19/19 2:58 AM:
-
Issue reproduced. And indeed seems to be related to LZW. Code used to reproduce
it:
{code:java}
package org.apache.commons.imaging;
import java.awt.image.BufferedImage;
import java.io.File;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class TTT {
public static void main(String[] args) throws Exception {
File f = new File("/home/kinow/Downloads/imaging/image_pages/A4.tiff");
ImageInfo imageInfo = Imaging.getImageInfo(f);
Map params = new HashMap<>();
if (imageInfo.getNumberOfImages() > 1) {
List allBufferedImages =
Imaging.getAllBufferedImages(f);
for (BufferedImage bufferedImage : allBufferedImages) {
//appendImagePage(bufferedImage);
Imaging.writeImage(bufferedImage, new File(f.getParent(), "" +
System.nanoTime()), ImageFormats.PNG,
new HashMap<>());
}
} else {
//appendImagePage(Imaging.getBufferedImage(imageBytes));
System.out.println("SINGLE PAGE!");
BufferedImage bufferedImage = Imaging.getBufferedImage(f, params);
Imaging.writeImage(bufferedImage, new File(f.getParent(), "" +
System.nanoTime()), ImageFormats.TIFF,
new HashMap<>());
}
}
}
{code}
Tested with ImageIO.write with the result BufferedReader, and got the same
issue. So the issue is not in our writer.
Tested with [ngageoint/tiff-java|[https://github.com/ngageoint/tiff-java]]
using just their LZW decoder, and got exact same image... so our LZW is
probably correct (or both incorrect).
Looked at the output of exiftool, and found nothing clearly wrong.
So it could still be something before the writer and decompressor, like the way
we read the data.
Thanks for the good issue description and the attachments. Hopefully we will
find what is wrong and include the fix in the next release.
Cheers
Bruno
was (Author: kinow):
Issue reproduced. And indeed seems to be related to LZW. Code used to reproduce
it:
{code:java}
package org.apache.commons.imaging;
import java.awt.image.BufferedImage;
import java.io.File;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class TTT {
public static void main(String[] args) throws Exception {
File f = new File("/home/kinow/Downloads/imaging/image_pages/A4.tiff");
ImageInfo imageInfo = Imaging.getImageInfo(f);
Map params = new HashMap<>();
if (imageInfo.getNumberOfImages() > 1) {
List allBufferedImages =
Imaging.getAllBufferedImages(f);
for (BufferedImage bufferedImage : allBufferedImages) {
//appendImagePage(bufferedImage);
Imaging.writeImage(bufferedImage, new File(f.getParent(), "" +
System.nanoTime()), ImageFormats.PNG,
new HashMap<>());
}
} else {
//appendImagePage(Imaging.getBufferedImage(imageBytes));
System.out.println("SINGLE PAGE!");
BufferedImage bufferedImage = Imaging.getBufferedImage(f, params);
Imaging.writeImage(bufferedImage, new File(f.getParent(), "" +
System.nanoTime()), ImageFormats.TIFF,
new HashMap<>());
}
}
}
{code}
Tested with ImageIO.write with the result BufferedReader, and got the same
issue. So the issue is not in our writer.
Tested with [ngageoint/tiff-java|[https://github.com/ngageoint/tiff-java],]
using just their LZW decoder, and got exact same image... so our LZW is
probably correct (or both incorrect).
Looked at the output of exiftool, and found nothing clearly wrong.
So it could still be something before the writer and decompressor, like the way
we read the data.
Thanks for the good issue description and the attachments. Hopefully we will
find what is wrong and include the fix in the next release.
Cheers
Bruno
> Reading tiff with LZW compression results in mangled image
> --
>
> Key: IMAGING-231
> URL: https://issues.apache.org/jira/browse/IMAGING-231
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1
>Reporter: Jimmy Merrild Krag
>Priority: Major
> Attachments: image_pages.zip, result.pdf
>
>
> I am trying to create a PDF using PDFbox with Commons Imaging for loading
> images. Commons imaging fixes most of the issues I have with the
> alternatives, but still cannot load my tiff files correctly.
> I have attached a resulting PDF as {{result.pdf}}.
> The files
[jira] [Commented] (IMAGING-231) Reading tiff with LZW compression results in mangled image
[
https://issues.apache.org/jira/browse/IMAGING-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888465#comment-16888465
]
Bruno P. Kinoshita commented on IMAGING-231:
Tried using ImageIO to read the data. i.e.
{code:java}
BufferedImage bufferedImage = Imaging.getBufferedImage(f, params);
// discard old data, read with JDK ImageIO
bufferedImage = ImageIO.read(f);{code}
It resulted in null on JDK 8. Then switched to JDK 11 (for
[http://openjdk.java.net/jeps/262] from JDK 9), and it resulted in the
following exception:
{noformat}
SINGLE PAGE!
Exception in thread "main" javax.imageio.IIOException: 16-bit samples are not
supported for Horizontal differencing Predictor
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFLZWDecompressor.decodeRaw(TIFFLZWDecompressor.java:89)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFDecompressor.decodeRaw(TIFFDecompressor.java:1907)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFDecompressor.decode(TIFFDecompressor.java:2549)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFImageReader.decodeTile(TIFFImageReader.java:1124)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFImageReader.read(TIFFImageReader.java:1342)
at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468)
at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1315)
at org.apache.commons.imaging.TTT.main(TTT.java:31){noformat}
> Reading tiff with LZW compression results in mangled image
> --
>
> Key: IMAGING-231
> URL: https://issues.apache.org/jira/browse/IMAGING-231
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1
>Reporter: Jimmy Merrild Krag
>Priority: Major
> Attachments: image_pages.zip, result.pdf
>
>
> I am trying to create a PDF using PDFbox with Commons Imaging for loading
> images. Commons imaging fixes most of the issues I have with the
> alternatives, but still cannot load my tiff files correctly.
> I have attached a resulting PDF as {{result.pdf}}.
> The files I use for testing, are attached in {{image_pages.zip}}. The
> tiff-files, which are not loaded correctly, are LZW-compressed, and that is
> the only difference I can find in the format.
> All images look the same if I save them to separate image files in another
> format, as they do in the PDF, so PDFbox does not seem to be the one to
> blame. My code for reading the files is pretty straightforward:
>
> {code:java}
> ImageInfo imageInfo = Imaging.getImageInfo(imageBytes);
> if (imageInfo.getNumberOfImages() > 1) {
> List allBufferedImages =
> Imaging.getAllBufferedImages(imageBytes);
> for (BufferedImage bufferedImage : allBufferedImages) {
> appendImagePage(bufferedImage);
> }
> } else {
> appendImagePage(Imaging.getBufferedImage(imageBytes));
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IMAGING-231) Reading tiff with LZW compression results in mangled image
[
https://issues.apache.org/jira/browse/IMAGING-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888465#comment-16888465
]
Bruno P. Kinoshita edited comment on IMAGING-231 at 7/19/19 3:10 AM:
-
Tried using ImageIO to read the data. i.e.
{code:java}
BufferedImage bufferedImage = Imaging.getBufferedImage(f, params);
// discard old data, read with JDK ImageIO
bufferedImage = ImageIO.read(f);{code}
It resulted in null on JDK 8. Then switched to JDK 11 (for
[http://openjdk.java.net/jeps/262] from JDK 9), and it resulted in the
following exception:
{noformat}
SINGLE PAGE!
Exception in thread "main" javax.imageio.IIOException: 16-bit samples are not
supported for Horizontal differencing Predictor
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFLZWDecompressor.decodeRaw(TIFFLZWDecompressor.java:89)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFDecompressor.decodeRaw(TIFFDecompressor.java:1907)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFDecompressor.decode(TIFFDecompressor.java:2549)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFImageReader.decodeTile(TIFFImageReader.java:1124)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFImageReader.read(TIFFImageReader.java:1342)
at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468)
at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1315)
at org.apache.commons.imaging.TTT.main(TTT.java:31){noformat}
Same result with ImageIO 1.4.0
{code:java}
com.github.jai-imageio
jai-imageio-core
1.4.0
{code}
Then the exception
{noformat}
SINGLE PAGE!
Exception in thread "main" javax.imageio.IIOException: 16-bit samples are not
supported for Horizontal differencing Predictor
at
com.github.jaiimageio.impl.plugins.tiff.TIFFLZWDecompressor.decodeRaw(TIFFLZWDecompressor.java:112)
at
com.github.jaiimageio.plugins.tiff.TIFFDecompressor.decodeRaw(TIFFDecompressor.java:2026)
at
com.github.jaiimageio.plugins.tiff.TIFFDecompressor.decode(TIFFDecompressor.java:2599)
at
com.github.jaiimageio.impl.plugins.tiff.TIFFImageReader.decodeTile(TIFFImageReader.java:1144)
at
com.github.jaiimageio.impl.plugins.tiff.TIFFImageReader.read(TIFFImageReader.java:1414)
at javax.imageio.ImageIO.read(ImageIO.java:1448)
at javax.imageio.ImageIO.read(ImageIO.java:1308)
at org.apache.commons.imaging.TTT.main(TTT.java:31)
{noformat}
was (Author: kinow):
Tried using ImageIO to read the data. i.e.
{code:java}
BufferedImage bufferedImage = Imaging.getBufferedImage(f, params);
// discard old data, read with JDK ImageIO
bufferedImage = ImageIO.read(f);{code}
It resulted in null on JDK 8. Then switched to JDK 11 (for
[http://openjdk.java.net/jeps/262] from JDK 9), and it resulted in the
following exception:
{noformat}
SINGLE PAGE!
Exception in thread "main" javax.imageio.IIOException: 16-bit samples are not
supported for Horizontal differencing Predictor
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFLZWDecompressor.decodeRaw(TIFFLZWDecompressor.java:89)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFDecompressor.decodeRaw(TIFFDecompressor.java:1907)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFDecompressor.decode(TIFFDecompressor.java:2549)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFImageReader.decodeTile(TIFFImageReader.java:1124)
at
java.desktop/com.sun.imageio.plugins.tiff.TIFFImageReader.read(TIFFImageReader.java:1342)
at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468)
at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1315)
at org.apache.commons.imaging.TTT.main(TTT.java:31){noformat}
> Reading tiff with LZW compression results in mangled image
> --
>
> Key: IMAGING-231
> URL: https://issues.apache.org/jira/browse/IMAGING-231
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1
>Reporter: Jimmy Merrild Krag
>Priority: Major
> Attachments: image_pages.zip, result.pdf
>
>
> I am trying to create a PDF using PDFbox with Commons Imaging for loading
> images. Commons imaging fixes most of the issues I have with the
> alternatives, but still cannot load my tiff files correctly.
> I have attached a resulting PDF as {{result.pdf}}.
> The files I use for testing, are attached in {{image_pages.zip}}. The
> tiff-files, which are not loaded correctly, are LZW-compressed, and that is
> the only difference I can find in the format.
> All images look the same if I save them to separate image files in another
> format, as they do in the PDF, so PDFbox does not seem to be the one to
> blame. My code for reading the files is pretty straightforward:
>
> {code:java}
> ImageInfo imageInfo = Imaging.getImageInfo(imageBytes);
> if
[jira] [Created] (IMAGING-236) Add support to read multiple images from GIF
Bruno P. Kinoshita created IMAGING-236: -- Summary: Add support to read multiple images from GIF Key: IMAGING-236 URL: https://issues.apache.org/jira/browse/IMAGING-236 Project: Commons Imaging Issue Type: Improvement Components: Format: GIF Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 Placeholder for https://github.com/apache/commons-imaging/pull/55 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-236) Add support to read multiple images from GIF
[ https://issues.apache.org/jira/browse/IMAGING-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-236. Resolution: Fixed > Add support to read multiple images from GIF > > > Key: IMAGING-236 > URL: https://issues.apache.org/jira/browse/IMAGING-236 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: GIF >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 3h > Remaining Estimate: 0h > > Placeholder for https://github.com/apache/commons-imaging/pull/55 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-238) Return copied byte arrays in Png Chunk and Png Chunk ICCP
[ https://issues.apache.org/jira/browse/IMAGING-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-238. Resolution: Fixed > Return copied byte arrays in Png Chunk and Png Chunk ICCP > - > > Key: IMAGING-238 > URL: https://issues.apache.org/jira/browse/IMAGING-238 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Noticed that the PngChunkIccp class was never tested. While looking at this > class, also noticed both this class and its parent had no javadoc, and a few > TODO notes. > We can remove the TODO's by returning copied values (they are already final, > and the parser may fail if users change the bytes in the array). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMAGING-239) Add inflate (deflate algorithm) to TIFF files
Bruno P. Kinoshita created IMAGING-239: -- Summary: Add inflate (deflate algorithm) to TIFF files Key: IMAGING-239 URL: https://issues.apache.org/jira/browse/IMAGING-239 Project: Commons Imaging Issue Type: Improvement Components: Format: TIFF Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 Placeholder for https://github.com/apache/commons-imaging/pull/43 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-239) Add inflate (deflate algorithm) to TIFF files
[ https://issues.apache.org/jira/browse/IMAGING-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-239. Resolution: Fixed > Add inflate (deflate algorithm) to TIFF files > - > > Key: IMAGING-239 > URL: https://issues.apache.org/jira/browse/IMAGING-239 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: TIFF >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > Placeholder for https://github.com/apache/commons-imaging/pull/43 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMAGING-242) Move to JUnit 5
Bruno P. Kinoshita created IMAGING-242: -- Summary: Move to JUnit 5 Key: IMAGING-242 URL: https://issues.apache.org/jira/browse/IMAGING-242 Project: Commons Imaging Issue Type: Improvement Components: imaging.* Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-242) Move to JUnit 5
[ https://issues.apache.org/jira/browse/IMAGING-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975986#comment-16975986 ] Bruno P. Kinoshita commented on IMAGING-242: Around 40% done on this branch [https://github.com/kinow/commons-imaging/tree/junit5] Will continue over the next days, prepare a PR, then start working on IMAGING-155 > Move to JUnit 5 > --- > > Key: IMAGING-242 > URL: https://issues.apache.org/jira/browse/IMAGING-242 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-241) Copy byte arrays fixing TODO markers
[ https://issues.apache.org/jira/browse/IMAGING-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-241. Resolution: Fixed > Copy byte arrays fixing TODO markers > > > Key: IMAGING-241 > URL: https://issues.apache.org/jira/browse/IMAGING-241 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > During the first 1.0 RC vote, several TODO markers were added, noting that we > were returning byte arrays directly to users. Those arrays, if changed, would > invalidate the work done by parsers (can even result in runtime errors once > the array is altered and other methods are called). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMAGING-241) Copy byte arrays fixing TODO markers
Bruno P. Kinoshita created IMAGING-241: -- Summary: Copy byte arrays fixing TODO markers Key: IMAGING-241 URL: https://issues.apache.org/jira/browse/IMAGING-241 Project: Commons Imaging Issue Type: Improvement Components: imaging.* Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 During the first 1.0 RC vote, several TODO markers were added, noting that we were returning byte arrays directly to users. Those arrays, if changed, would invalidate the work done by parsers (can even result in runtime errors once the array is altered and other methods are called). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-233) Unable to parse most web icons (favicon.ico)
[
https://issues.apache.org/jira/browse/IMAGING-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975950#comment-16975950
]
Bruno P. Kinoshita commented on IMAGING-233:
Hi David,
Could you share your code, please? The following worked for me.
{code:java}
List images = Imaging.getAllBufferedImages(new
File("/home/kinow/Downloads/imaging/favicon.ico"));
System.out.println(images); {code}
Resulted in:
{noformat}
[BufferedImage@e9e54c2: type = 2 DirectColorModel: rmask=ff gmask=ff00
bmask=ff amask=ff00 IntegerInterleavedRaster: width = 16 height = 16 #Bands
= 4 xOff = 0 yOff = 0 dataOffset[0] 0, BufferedImage@65ab7765: type = 2
DirectColorModel: rmask=ff gmask=ff00 bmask=ff amask=ff00
IntegerInterleavedRaster: width = 32 height = 32 #Bands = 4 xOff = 0 yOff = 0
dataOffset[0] 0]
{noformat}
Using the favicon from the URL you provided.
Cheers
Bruno
> Unable to parse most web icons (favicon.ico)
>
>
> Key: IMAGING-233
> URL: https://issues.apache.org/jira/browse/IMAGING-233
> Project: Commons Imaging
> Issue Type: Wish
> Components: Format: ICO
>Affects Versions: 1.0-alpha1
>Reporter: David Li
>Priority: Major
>
> I am unable to use 1.0-alpha1 to process a vast majority of icons on the web,
> i.e. [https://www.google.com/favicon.ico]. Attempting to do so results in
> `org.apache.commons.imaging.ImageReadException: Can't parse this format`.
>
> `file` identifies these icons as "MS Windows icon resource - 2 icons, 16x16,
> 32 bits/pixel, 32x32, 32 bits/pixel"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IMAGING-235) Tiff multi page image writing support
[ https://issues.apache.org/jira/browse/IMAGING-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975949#comment-16975949 ] Bruno P. Kinoshita commented on IMAGING-235: Hi Eric, I spent some time today looking for a good example or method that could be used, but had no luck, sorry. I think there is no simple method for that, but it should be possible to achieve that with the current API (hopefully). Will have another look later. Cheers Bruno > Tiff multi page image writing support > - > > Key: IMAGING-235 > URL: https://issues.apache.org/jira/browse/IMAGING-235 > Project: Commons Imaging > Issue Type: Wish >Affects Versions: 1.0-alpha1 >Reporter: Eric Heiss >Priority: Major > Labels: TIFF, Write > > Is there any support for writing multi page tiff images? There needs to be > some support for this. This is a common format for faxes and other automated > processes. I could not find any documentation on how to write a multi page > tiff. If this functionality does exist, could someone please point me to the > documentation, or show me an example? > Thanks, > -Eric -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-136) Imaging.getImageInfo() fails to read JPEG file
[
https://issues.apache.org/jira/browse/IMAGING-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16972197#comment-16972197
]
Bruno P. Kinoshita commented on IMAGING-136:
Patch merged. Fixed conflicts and checkstyle violations. Thanks for the PR
Michael!
> 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-alpha1
>Reporter: Tilman Hausherr
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha2
>
> 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
(v8.3.4#803005)
[jira] [Resolved] (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
]
Bruno P. Kinoshita resolved IMAGING-136.
Fix Version/s: (was: Patch Needed)
1.0-alpha2
Resolution: Fixed
> 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-alpha1
>Reporter: Tilman Hausherr
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha2
>
> 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
(v8.3.4#803005)
[jira] [Created] (IMAGING-237) The PNG parser must inform the user if the compression method is not supported
Bruno P. Kinoshita created IMAGING-237: -- Summary: The PNG parser must inform the user if the compression method is not supported Key: IMAGING-237 URL: https://issues.apache.org/jira/browse/IMAGING-237 Project: Commons Imaging Issue Type: Improvement Components: Format: PNG Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Today I was looking at the ICCP chunk type and the PNG image parser, and noticed that it was using the deflate compression only, regardless of the compression method value passed by the user. The documentation does say that deflate (0) is the supported compression, but that vendor implementations may use different compression algorithms. So instead of trying to use deflate (which would raise a runtime exception), we should inform the user that the compression method is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMAGING-238) Copy byte arrays in Png Chunk and Png Chunk ICCP
Bruno P. Kinoshita created IMAGING-238: -- Summary: Copy byte arrays in Png Chunk and Png Chunk ICCP Key: IMAGING-238 URL: https://issues.apache.org/jira/browse/IMAGING-238 Project: Commons Imaging Issue Type: Improvement Components: Format: PNG Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 Noticed that the PngChunkIccp class was never tested. While looking at this class, also noticed both this class and its parent had no javadoc, and a few TODO notes. We can remove the TODO's by returning copied values (they are already final, and the parser may fail if users change the bytes in the array). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-238) Return copied byte arrays in Png Chunk and Png Chunk ICCP
[ https://issues.apache.org/jira/browse/IMAGING-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-238: --- Summary: Return copied byte arrays in Png Chunk and Png Chunk ICCP (was: Copy byte arrays in Png Chunk and Png Chunk ICCP) > Return copied byte arrays in Png Chunk and Png Chunk ICCP > - > > Key: IMAGING-238 > URL: https://issues.apache.org/jira/browse/IMAGING-238 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > > Noticed that the PngChunkIccp class was never tested. While looking at this > class, also noticed both this class and its parent had no javadoc, and a few > TODO notes. > We can remove the TODO's by returning copied values (they are already final, > and the parser may fail if users change the bytes in the array). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-243) PNG Writer Indexed Color with semi-transparent Pixels and Better Compression
[ https://issues.apache.org/jira/browse/IMAGING-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-243. Resolution: Fixed > PNG Writer Indexed Color with semi-transparent Pixels and Better Compression > > > Key: IMAGING-243 > URL: https://issues.apache.org/jira/browse/IMAGING-243 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG >Affects Versions: 1.0-alpha1 >Reporter: Andreas >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: pull-request-available > Fix For: 1.0-alpha2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > I updated the PNG-Writer for smaller png-Files: > * PNG Writer Indexed Color with semi-transparent Pixels > * Better Compression > > See Pull-Request: [https://github.com/apache/commons-imaging/pull/58] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-146) Add documentation for the color package
[ https://issues.apache.org/jira/browse/IMAGING-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16996618#comment-16996618 ] Bruno P. Kinoshita commented on IMAGING-146: Created a PR with simple Javadoc comments, explaining what color space relates to the color class, what are the constant values available, and a link to the Wikipedia article on the color space (or the color model, but one can derive the space from the model I guess). > 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.* >Affects Versions: 1.0-alpha1 >Reporter: Benedikt Ritter >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > 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 (v8.3.4#803005)
[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 ] Bruno P. Kinoshita updated IMAGING-146: --- Fix Version/s: (was: Patch Needed) 1.0-alpha2 > 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 >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > 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 (v8.3.4#803005)
[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 ] Bruno P. Kinoshita updated IMAGING-146: --- Affects Version/s: 1.0-alpha1 > 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.* >Affects Versions: 1.0-alpha1 >Reporter: Benedikt Ritter >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > 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 (v8.3.4#803005)
[jira] [Updated] (IMAGING-151) ColorGroup.color_counts is mutable public List and is multiply sorted
[ https://issues.apache.org/jira/browse/IMAGING-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-151: --- Affects Version/s: 1.0-alpha1 > ColorGroup.color_counts is mutable public List and is multiply sorted > - > > Key: IMAGING-151 > URL: https://issues.apache.org/jira/browse/IMAGING-151 > Project: Commons Imaging > Issue Type: Bug >Affects Versions: 1.0-alpha1 >Reporter: Sebb >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > ColorGroup.color_counts is a public mutable List. > Also the List is re-sorted in several places > It looks like the field is only used within the package, so can be package > protected. > However it seems odd that the shared list is re-sorted by > MedianCutLongestAxisImplementation.doCut > and > MedianCutMostPopulatedBoxesImplementation.performNextMedianCut (twice) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-151) ColorGroup.color_counts is mutable public List and is multiply sorted
[ https://issues.apache.org/jira/browse/IMAGING-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-151: --- Fix Version/s: 1.0-alpha2 > ColorGroup.color_counts is mutable public List and is multiply sorted > - > > Key: IMAGING-151 > URL: https://issues.apache.org/jira/browse/IMAGING-151 > Project: Commons Imaging > Issue Type: Bug >Reporter: Sebb >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > ColorGroup.color_counts is a public mutable List. > Also the List is re-sorted in several places > It looks like the field is only used within the package, so can be package > protected. > However it seems odd that the shared list is re-sorted by > MedianCutLongestAxisImplementation.doCut > and > MedianCutMostPopulatedBoxesImplementation.performNextMedianCut (twice) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-151) ColorGroup.color_counts is mutable public List and is multiply sorted
[ https://issues.apache.org/jira/browse/IMAGING-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16996586#comment-16996586 ] Bruno P. Kinoshita commented on IMAGING-151: Hi [~sebb] PR submitted: [https://github.com/apache/commons-imaging/pull/64,] let me know if you have some spare time to review it later. Thanks > ColorGroup.color_counts is mutable public List and is multiply sorted > - > > Key: IMAGING-151 > URL: https://issues.apache.org/jira/browse/IMAGING-151 > Project: Commons Imaging > Issue Type: Bug >Reporter: Sebb >Assignee: Bruno P. Kinoshita >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > ColorGroup.color_counts is a public mutable List. > Also the List is re-sorted in several places > It looks like the field is only used within the package, so can be package > protected. > However it seems odd that the shared list is re-sorted by > MedianCutLongestAxisImplementation.doCut > and > MedianCutMostPopulatedBoxesImplementation.performNextMedianCut (twice) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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 ] Bruno P. Kinoshita updated IMAGING-146: --- Assignee: Bruno P. Kinoshita > 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 >Assignee: Bruno P. Kinoshita >Priority: Major > 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 (v8.3.4#803005)
[jira] [Commented] (IMAGING-158) Color component names should follow naming conventions
[
https://issues.apache.org/jira/browse/IMAGING-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16996620#comment-16996620
]
Bruno P. Kinoshita commented on IMAGING-158:
I think this has been fixed already. All the constants in the color components
are now CYAN, BLACK, WHITE, GREEN, etc. No more simple letters used, so closing
the issue.
> Color component names should follow naming conventions
> --
>
> Key: IMAGING-158
> URL: https://issues.apache.org/jira/browse/IMAGING-158
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.color.*
>Reporter: Benedikt Ritter
>Priority: Major
>
> Checkstyle reports a lot of errors because the fields of our color classes
> are just single capital letters. I'm currently thinking about renaming them
> to their full names, so that {{ColorCmy.C}} becomes {{ColorCmy.cyan}}. Don't
> know if that feels better from an API user's POV. It's longer by it's more
> explicit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IMAGING-158) Color component names should follow naming conventions
[
https://issues.apache.org/jira/browse/IMAGING-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-158.
Resolution: Fixed
> Color component names should follow naming conventions
> --
>
> Key: IMAGING-158
> URL: https://issues.apache.org/jira/browse/IMAGING-158
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.color.*
>Reporter: Benedikt Ritter
>Priority: Major
>
> Checkstyle reports a lot of errors because the fields of our color classes
> are just single capital letters. I'm currently thinking about renaming them
> to their full names, so that {{ColorCmy.C}} becomes {{ColorCmy.cyan}}. Don't
> know if that feels better from an API user's POV. It's longer by it's more
> explicit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-158) Color component names should follow naming conventions
[
https://issues.apache.org/jira/browse/IMAGING-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-158:
---
Affects Version/s: 0.97
> Color component names should follow naming conventions
> --
>
> Key: IMAGING-158
> URL: https://issues.apache.org/jira/browse/IMAGING-158
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.color.*
>Affects Versions: 0.97
>Reporter: Benedikt Ritter
>Priority: Major
>
> Checkstyle reports a lot of errors because the fields of our color classes
> are just single capital letters. I'm currently thinking about renaming them
> to their full names, so that {{ColorCmy.C}} becomes {{ColorCmy.cyan}}. Don't
> know if that feels better from an API user's POV. It's longer by it's more
> explicit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IMAGING-244) Use isEmpty instead of comparing size() with integers
Bruno P. Kinoshita created IMAGING-244: -- Summary: Use isEmpty instead of comparing size() with integers Key: IMAGING-244 URL: https://issues.apache.org/jira/browse/IMAGING-244 Project: Commons Imaging Issue Type: Improvement Components: imaging.* Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-151) ColorGroup.color_counts is mutable public List and is multiply sorted
[ https://issues.apache.org/jira/browse/IMAGING-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-151: --- Assignee: Bruno P. Kinoshita > ColorGroup.color_counts is mutable public List and is multiply sorted > - > > Key: IMAGING-151 > URL: https://issues.apache.org/jira/browse/IMAGING-151 > Project: Commons Imaging > Issue Type: Bug >Reporter: Sebb >Assignee: Bruno P. Kinoshita >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > ColorGroup.color_counts is a public mutable List. > Also the List is re-sorted in several places > It looks like the field is only used within the package, so can be package > protected. > However it seems odd that the shared list is re-sorted by > MedianCutLongestAxisImplementation.doCut > and > MedianCutMostPopulatedBoxesImplementation.performNextMedianCut (twice) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-158) Color component names should follow naming conventions
[
https://issues.apache.org/jira/browse/IMAGING-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-158:
---
Fix Version/s: 1.0-alpha1
> Color component names should follow naming conventions
> --
>
> Key: IMAGING-158
> URL: https://issues.apache.org/jira/browse/IMAGING-158
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.color.*
>Affects Versions: 0.97
>Reporter: Benedikt Ritter
>Priority: Major
> Fix For: 1.0-alpha1
>
>
> Checkstyle reports a lot of errors because the fields of our color classes
> are just single capital letters. I'm currently thinking about renaming them
> to their full names, so that {{ColorCmy.C}} becomes {{ColorCmy.cyan}}. Don't
> know if that feels better from an API user's POV. It's longer by it's more
> explicit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (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 ] Bruno P. Kinoshita resolved IMAGING-146. Resolution: Fixed > 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.* >Affects Versions: 1.0-alpha1 >Reporter: Benedikt Ritter >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 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 (v8.3.4#803005)
[jira] [Resolved] (IMAGING-244) Use isEmpty instead of comparing size() with integers
[ https://issues.apache.org/jira/browse/IMAGING-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-244. Resolution: Fixed > Use isEmpty instead of comparing size() with integers > - > > Key: IMAGING-244 > URL: https://issues.apache.org/jira/browse/IMAGING-244 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Trivial > Fix For: 1.0-alpha2 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-163) DcxImageParser.getXmpXml() always returns null
[
https://issues.apache.org/jira/browse/IMAGING-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960901#comment-16960901
]
Bruno P. Kinoshita commented on IMAGING-163:
Proposed another patch for this issue, where we introduce an interface to be
used by parsers that support embedding XMP metadata tags. (y)
> DcxImageParser.getXmpXml() always returns null
> --
>
> Key: IMAGING-163
> URL: https://issues.apache.org/jira/browse/IMAGING-163
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Michael Groß
>Priority: Major
> Labels: github
> Fix For: Review Patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Affects PCX format - can't spot this format in "Components" field.
> org.apache.commons.imaging.formats.dcx.DcxImageParser.getXmpXml() always
> returns null
> {noformat}
> /**
> * Extracts embedded XML metadata as XML string.
> *
> *
> * @param byteSource
> *File containing image data.
> * @param params
> *Map of optional parameters, defined in ImagingConstants.
> * @return Xmp Xml as String, if present. Otherwise, returns null.
> * @throws org.apache.commons.imaging.ImageReadException
> * @throws java.io.IOException
> */
> @Override
> public String getXmpXml(final ByteSource byteSource, final
> ImagingParameters params)
> throws ImageReadException, IOException {
> return null;
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-163) DcxImageParser.getXmpXml() always returns null
[
https://issues.apache.org/jira/browse/IMAGING-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-163:
---
Assignee: Bruno P. Kinoshita
> DcxImageParser.getXmpXml() always returns null
> --
>
> Key: IMAGING-163
> URL: https://issues.apache.org/jira/browse/IMAGING-163
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Labels: github
> Fix For: Review Patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Affects PCX format - can't spot this format in "Components" field.
> org.apache.commons.imaging.formats.dcx.DcxImageParser.getXmpXml() always
> returns null
> {noformat}
> /**
> * Extracts embedded XML metadata as XML string.
> *
> *
> * @param byteSource
> *File containing image data.
> * @param params
> *Map of optional parameters, defined in ImagingConstants.
> * @return Xmp Xml as String, if present. Otherwise, returns null.
> * @throws org.apache.commons.imaging.ImageReadException
> * @throws java.io.IOException
> */
> @Override
> public String getXmpXml(final ByteSource byteSource, final
> ImagingParameters params)
> throws ImageReadException, IOException {
> return null;
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IMAGING-165) TiffReader.Collector adds values to a field List but never uses it
[
https://issues.apache.org/jira/browse/IMAGING-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-165.
Fix Version/s: (was: Discussion)
1.0-alpha2
Resolution: Fixed
> TiffReader.Collector adds values to a field List but never uses it
> -
>
> Key: IMAGING-165
> URL: https://issues.apache.org/jira/browse/IMAGING-165
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: TIFF
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> org.apache.commons.imaging.formats.tiff.TiffReader.Collector adds values to a
> field List but never uses it. This could be the cause of some
> problems reported elsewhere.
> TiffReader contains an embedded class named Collector. This class has a
> private field named
> {noformat}
> private static class Collector implements Listener {
> private final List fields = new ArrayList();
> {noformat}
> There are values added in a method named
> {noformat}
> public boolean addField(final TiffField field) {
> fields.add(field);
> return true;
> }
> {noformat}
> This method is the only which uses this field so these values are never used.
> Is there a getter missing? Or was it intended to use these values in class
> TiffContents like "tiffHeader" and "directories"?
> {noformat}
> public TiffContents getContents() {
> return new TiffContents(tiffHeader, directories);
> }
> {noformat}
> At least the method "addField" seems unused but necessary to implement the
> "Listener" interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-165) TiffReader.Collector adds values to a field List but never uses it
[
https://issues.apache.org/jira/browse/IMAGING-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-165:
---
Priority: Minor (was: Major)
> TiffReader.Collector adds values to a field List but never uses it
> -
>
> Key: IMAGING-165
> URL: https://issues.apache.org/jira/browse/IMAGING-165
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> org.apache.commons.imaging.formats.tiff.TiffReader.Collector adds values to a
> field List but never uses it. This could be the cause of some
> problems reported elsewhere.
> TiffReader contains an embedded class named Collector. This class has a
> private field named
> {noformat}
> private static class Collector implements Listener {
> private final List fields = new ArrayList();
> {noformat}
> There are values added in a method named
> {noformat}
> public boolean addField(final TiffField field) {
> fields.add(field);
> return true;
> }
> {noformat}
> This method is the only which uses this field so these values are never used.
> Is there a getter missing? Or was it intended to use these values in class
> TiffContents like "tiffHeader" and "directories"?
> {noformat}
> public TiffContents getContents() {
> return new TiffContents(tiffHeader, directories);
> }
> {noformat}
> At least the method "addField" seems unused but necessary to implement the
> "Listener" interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-165) TiffReader.Collector adds values to a field List but never uses it
[
https://issues.apache.org/jira/browse/IMAGING-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-165:
---
Assignee: Bruno P. Kinoshita
> TiffReader.Collector adds values to a field List but never uses it
> -
>
> Key: IMAGING-165
> URL: https://issues.apache.org/jira/browse/IMAGING-165
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: TIFF
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Discussion
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> org.apache.commons.imaging.formats.tiff.TiffReader.Collector adds values to a
> field List but never uses it. This could be the cause of some
> problems reported elsewhere.
> TiffReader contains an embedded class named Collector. This class has a
> private field named
> {noformat}
> private static class Collector implements Listener {
> private final List fields = new ArrayList();
> {noformat}
> There are values added in a method named
> {noformat}
> public boolean addField(final TiffField field) {
> fields.add(field);
> return true;
> }
> {noformat}
> This method is the only which uses this field so these values are never used.
> Is there a getter missing? Or was it intended to use these values in class
> TiffContents like "tiffHeader" and "directories"?
> {noformat}
> public TiffContents getContents() {
> return new TiffContents(tiffHeader, directories);
> }
> {noformat}
> At least the method "addField" seems unused but necessary to implement the
> "Listener" interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-165) TiffReader.Collector adds values to a field List but never uses it
[
https://issues.apache.org/jira/browse/IMAGING-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-165:
---
Affects Version/s: 1.0-alpha1
> TiffReader.Collector adds values to a field List but never uses it
> -
>
> Key: IMAGING-165
> URL: https://issues.apache.org/jira/browse/IMAGING-165
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> org.apache.commons.imaging.formats.tiff.TiffReader.Collector adds values to a
> field List but never uses it. This could be the cause of some
> problems reported elsewhere.
> TiffReader contains an embedded class named Collector. This class has a
> private field named
> {noformat}
> private static class Collector implements Listener {
> private final List fields = new ArrayList();
> {noformat}
> There are values added in a method named
> {noformat}
> public boolean addField(final TiffField field) {
> fields.add(field);
> return true;
> }
> {noformat}
> This method is the only which uses this field so these values are never used.
> Is there a getter missing? Or was it intended to use these values in class
> TiffContents like "tiffHeader" and "directories"?
> {noformat}
> public TiffContents getContents() {
> return new TiffContents(tiffHeader, directories);
> }
> {noformat}
> At least the method "addField" seems unused but necessary to implement the
> "Listener" interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-164) Simplify code in IcoImageParser::writeImage
[
https://issues.apache.org/jira/browse/IMAGING-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-164:
---
Fix Version/s: (was: Review Patch)
1.0-alpha2
> Simplify code in IcoImageParser::writeImage
>
>
> Key: IMAGING-164
> URL: https://issues.apache.org/jira/browse/IMAGING-164
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: ICO
>Affects Versions: 1.0-alpha1
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Labels: github
> Fix For: 1.0-alpha2
>
>
> org.apache.commons.imaging.formats.ico.IcoImageParser::writeImage(final
> BufferedImage src, final OutputStream os, final ImagingParameters params)
> may throw an unexpected NullPointerException because it of the following code:
> {noformat}
> final SimplePalette palette = paletteFactory.makeExactRgbPaletteSimple(src,
> 256);
> {noformat}
> Then asking if the created palette is null. I will discuss where it comes
> from below. For now it is interesting that we set the variable bitCount
> despite the SimplePalette is null. Currently this makes no sense because the
> code will throw a NullPointerException later if SimplePalette is null.
> {noformat}
> if (palette == null) {
> if (hasTransparency) {
> bitCount = 32;
> } else {
> bitCount = 24;
> }
> {noformat}
> In the later for-loop we try to call *getPaletteIndex(rgb)* on the
> SimplePalette instance. If it contains null, we'll get a NullPointerException
> here.
> {noformat}
> for (int y = src.getHeight() - 1; y >= 0; y--) {
> for (int x = 0; x < src.getWidth(); x++) {
> final int argb = src.getRGB(x, y);
> if (bitCount < 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
>...
> } else if (bitCount == 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
> {noformat}
> Why can SimplePalette be null? It comes from
> PaletteFactory::makeExactRgbPaletteSimple(final BufferedImage src, final int
> max). As it's javadoc says it will "fails by returning null if there are more
> than max colors necessary":
> {noformat}
> if (rgbs.add(rgb) && rgbs.size() > max) {
> return null;
> }
> {noformat}
> My first idea goes to throw a RunTimeException rather than returning null.
> But one has to check if there are cases where the return of null triggers
> some error handling i.e. increasing the number of colors or creating a
> different type of object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-164) Simplify code in IcoImageParser::writeImage
[
https://issues.apache.org/jira/browse/IMAGING-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-164:
---
Affects Version/s: 1.0-alpha1
> Simplify code in IcoImageParser::writeImage
>
>
> Key: IMAGING-164
> URL: https://issues.apache.org/jira/browse/IMAGING-164
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: ICO
>Affects Versions: 1.0-alpha1
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Labels: github
> Fix For: Review Patch
>
>
> org.apache.commons.imaging.formats.ico.IcoImageParser::writeImage(final
> BufferedImage src, final OutputStream os, final ImagingParameters params)
> may throw an unexpected NullPointerException because it of the following code:
> {noformat}
> final SimplePalette palette = paletteFactory.makeExactRgbPaletteSimple(src,
> 256);
> {noformat}
> Then asking if the created palette is null. I will discuss where it comes
> from below. For now it is interesting that we set the variable bitCount
> despite the SimplePalette is null. Currently this makes no sense because the
> code will throw a NullPointerException later if SimplePalette is null.
> {noformat}
> if (palette == null) {
> if (hasTransparency) {
> bitCount = 32;
> } else {
> bitCount = 24;
> }
> {noformat}
> In the later for-loop we try to call *getPaletteIndex(rgb)* on the
> SimplePalette instance. If it contains null, we'll get a NullPointerException
> here.
> {noformat}
> for (int y = src.getHeight() - 1; y >= 0; y--) {
> for (int x = 0; x < src.getWidth(); x++) {
> final int argb = src.getRGB(x, y);
> if (bitCount < 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
>...
> } else if (bitCount == 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
> {noformat}
> Why can SimplePalette be null? It comes from
> PaletteFactory::makeExactRgbPaletteSimple(final BufferedImage src, final int
> max). As it's javadoc says it will "fails by returning null if there are more
> than max colors necessary":
> {noformat}
> if (rgbs.add(rgb) && rgbs.size() > max) {
> return null;
> }
> {noformat}
> My first idea goes to throw a RunTimeException rather than returning null.
> But one has to check if there are cases where the return of null triggers
> some error handling i.e. increasing the number of colors or creating a
> different type of object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-164) Simplify code in IcoImageParser::writeImage
[
https://issues.apache.org/jira/browse/IMAGING-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-164:
---
Summary: Simplify code in IcoImageParser::writeImage (was: Possible
dereferencing of null pointer in IcoImageParser::writeImage)
> Simplify code in IcoImageParser::writeImage
>
>
> Key: IMAGING-164
> URL: https://issues.apache.org/jira/browse/IMAGING-164
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: ICO
>Reporter: Michael Groß
>Priority: Major
> Labels: github
> Fix For: Review Patch
>
>
> org.apache.commons.imaging.formats.ico.IcoImageParser::writeImage(final
> BufferedImage src, final OutputStream os, final ImagingParameters params)
> may throw an unexpected NullPointerException because it of the following code:
> {noformat}
> final SimplePalette palette = paletteFactory.makeExactRgbPaletteSimple(src,
> 256);
> {noformat}
> Then asking if the created palette is null. I will discuss where it comes
> from below. For now it is interesting that we set the variable bitCount
> despite the SimplePalette is null. Currently this makes no sense because the
> code will throw a NullPointerException later if SimplePalette is null.
> {noformat}
> if (palette == null) {
> if (hasTransparency) {
> bitCount = 32;
> } else {
> bitCount = 24;
> }
> {noformat}
> In the later for-loop we try to call *getPaletteIndex(rgb)* on the
> SimplePalette instance. If it contains null, we'll get a NullPointerException
> here.
> {noformat}
> for (int y = src.getHeight() - 1; y >= 0; y--) {
> for (int x = 0; x < src.getWidth(); x++) {
> final int argb = src.getRGB(x, y);
> if (bitCount < 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
>...
> } else if (bitCount == 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
> {noformat}
> Why can SimplePalette be null? It comes from
> PaletteFactory::makeExactRgbPaletteSimple(final BufferedImage src, final int
> max). As it's javadoc says it will "fails by returning null if there are more
> than max colors necessary":
> {noformat}
> if (rgbs.add(rgb) && rgbs.size() > max) {
> return null;
> }
> {noformat}
> My first idea goes to throw a RunTimeException rather than returning null.
> But one has to check if there are cases where the return of null triggers
> some error handling i.e. increasing the number of colors or creating a
> different type of object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-164) Simplify code in IcoImageParser::writeImage
[
https://issues.apache.org/jira/browse/IMAGING-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-164:
---
Assignee: Bruno P. Kinoshita
> Simplify code in IcoImageParser::writeImage
>
>
> Key: IMAGING-164
> URL: https://issues.apache.org/jira/browse/IMAGING-164
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: ICO
>Reporter: Michael Groß
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Labels: github
> Fix For: Review Patch
>
>
> org.apache.commons.imaging.formats.ico.IcoImageParser::writeImage(final
> BufferedImage src, final OutputStream os, final ImagingParameters params)
> may throw an unexpected NullPointerException because it of the following code:
> {noformat}
> final SimplePalette palette = paletteFactory.makeExactRgbPaletteSimple(src,
> 256);
> {noformat}
> Then asking if the created palette is null. I will discuss where it comes
> from below. For now it is interesting that we set the variable bitCount
> despite the SimplePalette is null. Currently this makes no sense because the
> code will throw a NullPointerException later if SimplePalette is null.
> {noformat}
> if (palette == null) {
> if (hasTransparency) {
> bitCount = 32;
> } else {
> bitCount = 24;
> }
> {noformat}
> In the later for-loop we try to call *getPaletteIndex(rgb)* on the
> SimplePalette instance. If it contains null, we'll get a NullPointerException
> here.
> {noformat}
> for (int y = src.getHeight() - 1; y >= 0; y--) {
> for (int x = 0; x < src.getWidth(); x++) {
> final int argb = src.getRGB(x, y);
> if (bitCount < 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
>...
> } else if (bitCount == 8) {
> final int rgb = 0xff & argb;
> final int index = palette.getPaletteIndex(rgb); //
> possible NullPointerException
> {noformat}
> Why can SimplePalette be null? It comes from
> PaletteFactory::makeExactRgbPaletteSimple(final BufferedImage src, final int
> max). As it's javadoc says it will "fails by returning null if there are more
> than max colors necessary":
> {noformat}
> if (rgbs.add(rgb) && rgbs.size() > max) {
> return null;
> }
> {noformat}
> My first idea goes to throw a RunTimeException rather than returning null.
> But one has to check if there are cases where the return of null triggers
> some error handling i.e. increasing the number of colors or creating a
> different type of object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IMAGING-217) ImageMetadata NULL returned from Imaging.getMetadata() for JPEG
[
https://issues.apache.org/jira/browse/IMAGING-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-217.
Resolution: Not A Bug
Closing as not a bug. Please feel free to re-open in case the problem persists.
See my previous comment too about the validation issue with another tool as
well. Thanks!
> ImageMetadata NULL returned from Imaging.getMetadata() for JPEG
> ---
>
> Key: IMAGING-217
> URL: https://issues.apache.org/jira/browse/IMAGING-217
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: Ritesh Srivastava
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Attachments: P1002265.JPG, P1002265.JPG.html
>
>
> The Imaging.getMetadata() API is failing for JPEG Image File (Attached) -
> The same file ImageInfo is geting pulled via Imaging.getImageInfo()
> {code:java}
> File imageFile = new File("D:\\sample_files\\P1002265.jpg");
> ImageInfo imageInfo = Imaging.getImageInfo(imageFile);
> System.out.println(imageInfo);
> ImageMetadata imageMetadata = Imaging.getMetadata(imageFile);
> System.out.println(imageMetadata);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-243) PNG Writer Indexed Color with semi-transparent Pixels and Better Compression
[ https://issues.apache.org/jira/browse/IMAGING-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-243: --- Fix Version/s: 1.0-alpha2 > PNG Writer Indexed Color with semi-transparent Pixels and Better Compression > > > Key: IMAGING-243 > URL: https://issues.apache.org/jira/browse/IMAGING-243 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG >Affects Versions: 1.0-alpha2 >Reporter: Andreas >Assignee: Bruno P. Kinoshita >Priority: Major > Labels: pull-request-available > Fix For: 1.0-alpha2 > > > I updated the PNG-Writer for smaller png-Files: > * PNG Writer Indexed Color with semi-transparent Pixels > * Better Compression > > See Pull-Request: [https://github.com/apache/commons-imaging/pull/58] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-243) PNG Writer Indexed Color with semi-transparent Pixels and Better Compression
[ https://issues.apache.org/jira/browse/IMAGING-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-243: --- Priority: Minor (was: Major) > PNG Writer Indexed Color with semi-transparent Pixels and Better Compression > > > Key: IMAGING-243 > URL: https://issues.apache.org/jira/browse/IMAGING-243 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG >Affects Versions: 1.0-alpha1 >Reporter: Andreas >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: pull-request-available > Fix For: 1.0-alpha2 > > > I updated the PNG-Writer for smaller png-Files: > * PNG Writer Indexed Color with semi-transparent Pixels > * Better Compression > > See Pull-Request: [https://github.com/apache/commons-imaging/pull/58] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-243) PNG Writer Indexed Color with semi-transparent Pixels and Better Compression
[ https://issues.apache.org/jira/browse/IMAGING-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-243: --- Assignee: Bruno P. Kinoshita > PNG Writer Indexed Color with semi-transparent Pixels and Better Compression > > > Key: IMAGING-243 > URL: https://issues.apache.org/jira/browse/IMAGING-243 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG >Affects Versions: 1.0-alpha2 >Reporter: Andreas >Assignee: Bruno P. Kinoshita >Priority: Major > Labels: pull-request-available > > I updated the PNG-Writer for smaller png-Files: > * PNG Writer Indexed Color with semi-transparent Pixels > * Better Compression > > See Pull-Request: [https://github.com/apache/commons-imaging/pull/58] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-243) PNG Writer Indexed Color with semi-transparent Pixels and Better Compression
[ https://issues.apache.org/jira/browse/IMAGING-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-243: --- Affects Version/s: (was: 1.0-alpha2) 1.0-alpha1 > PNG Writer Indexed Color with semi-transparent Pixels and Better Compression > > > Key: IMAGING-243 > URL: https://issues.apache.org/jira/browse/IMAGING-243 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: PNG >Affects Versions: 1.0-alpha1 >Reporter: Andreas >Assignee: Bruno P. Kinoshita >Priority: Major > Labels: pull-request-available > Fix For: 1.0-alpha2 > > > I updated the PNG-Writer for smaller png-Files: > * PNG Writer Indexed Color with semi-transparent Pixels > * Better Compression > > See Pull-Request: [https://github.com/apache/commons-imaging/pull/58] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-242) Move to JUnit 5
[ https://issues.apache.org/jira/browse/IMAGING-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-242. Resolution: Fixed > Move to JUnit 5 > --- > > Key: IMAGING-242 > URL: https://issues.apache.org/jira/browse/IMAGING-242 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TEXT-149) StringEscapeUtils.unescapeCsv doesn't remove quotes at begin and end of string
[
https://issues.apache.org/jira/browse/TEXT-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated TEXT-149:
Fix Version/s: 1.8.1
> StringEscapeUtils.unescapeCsv doesn't remove quotes at begin and end of string
> --
>
> Key: TEXT-149
> URL: https://issues.apache.org/jira/browse/TEXT-149
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Krzysztof Szalast
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.8.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> org.apache.commons.text.translate.CsvTranslators:
> {code:java}
> void translateWhole(CharSequence input, Writer out) throws IOException {
> if (input.charAt(0) == '"' && input.charAt(input.length() - 1) == '"') {
> String quoteless = input.subSequence(1, input.length() -
> 1).toString();
> if (StringUtils.containsAny(quoteless,
> CsvTranslators.CSV_SEARCH_CHARS)) {
> out.write(StringUtils.replace(quoteless,
> CsvTranslators.CSV_ESCAPED_QUOTE_STR, CsvTranslators.CSV_QUOTE_STR));
> } else {
> out.write(input.toString());
> }
> } else {
> out.write(input.toString());
> }
> }{code}
>
> In my opinion first occurence "out.write(input.toString());" should be
> replaced with:
> {code:java}
> out.write(quoteless.toString());{code}
> Because '"' quotes around "input" will be never removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TEXT-149) StringEscapeUtils.unescapeCsv doesn't remove quotes at begin and end of string
[
https://issues.apache.org/jira/browse/TEXT-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated TEXT-149:
Assignee: Bruno P. Kinoshita
> StringEscapeUtils.unescapeCsv doesn't remove quotes at begin and end of string
> --
>
> Key: TEXT-149
> URL: https://issues.apache.org/jira/browse/TEXT-149
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Krzysztof Szalast
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> org.apache.commons.text.translate.CsvTranslators:
> {code:java}
> void translateWhole(CharSequence input, Writer out) throws IOException {
> if (input.charAt(0) == '"' && input.charAt(input.length() - 1) == '"') {
> String quoteless = input.subSequence(1, input.length() -
> 1).toString();
> if (StringUtils.containsAny(quoteless,
> CsvTranslators.CSV_SEARCH_CHARS)) {
> out.write(StringUtils.replace(quoteless,
> CsvTranslators.CSV_ESCAPED_QUOTE_STR, CsvTranslators.CSV_QUOTE_STR));
> } else {
> out.write(input.toString());
> }
> } else {
> out.write(input.toString());
> }
> }{code}
>
> In my opinion first occurence "out.write(input.toString());" should be
> replaced with:
> {code:java}
> out.write(quoteless.toString());{code}
> Because '"' quotes around "input" will be never removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (TEXT-166) FuzzyScore JavaDoc mistake
[
https://issues.apache.org/jira/browse/TEXT-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved TEXT-166.
-
Resolution: Fixed
> FuzzyScore JavaDoc mistake
> --
>
> Key: TEXT-166
> URL: https://issues.apache.org/jira/browse/TEXT-166
> Project: Commons Text
> Issue Type: Task
>Affects Versions: 1.8
>Reporter: Ben Manes
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Labels: javadoc
> Fix For: 1.8.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{FuzzyScore}} was adapted from {{StringUtils#getFuzzyDistance}} and the
> JavaDoc was copied as is. The deprecated utility method took three arguments
> (term, query, locale). The class takes {{locale}} as a constructor argument
> and the remaining as method arguments. However, the JavaDoc was unchanged and
> shows the {{locale}} method parameter.
> {code:java}
> /**
> *
> * Find the Fuzzy Score which indicates the similarity score between two
> * Strings.
> *
> *
> *
> * score.fuzzyScore(null, null, null) = IllegalArgumentException
> * score.fuzzyScore("", "", Locale.ENGLISH) = 0
> * score.fuzzyScore("Workshop", "b", Locale.ENGLISH) = 0
> * score.fuzzyScore("Room", "o", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "w", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "ws", Locale.ENGLISH) = 2
> * score.fuzzyScore("Workshop", "wo", Locale.ENGLISH) = 4
> * score.fuzzyScore("Apache Software Foundation", "asf", Locale.ENGLISH) = 3
> *
> *
> * @param term a full term that should be matched against, must not be null
> * @param query the query that will be matched against a term, must not be
> * null
> * @return result score
> * @throws IllegalArgumentException if either CharSequence input is {@code
> null}
> */
> public Integer fuzzyScore(final CharSequence term, final CharSequence query)
> {{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TEXT-166) FuzzyScore JavaDoc mistake
[
https://issues.apache.org/jira/browse/TEXT-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated TEXT-166:
Fix Version/s: 1.8.1
> FuzzyScore JavaDoc mistake
> --
>
> Key: TEXT-166
> URL: https://issues.apache.org/jira/browse/TEXT-166
> Project: Commons Text
> Issue Type: Task
>Reporter: Ben Manes
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 1.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{FuzzyScore}} was adapted from {{StringUtils#getFuzzyDistance}} and the
> JavaDoc was copied as is. The deprecated utility method took three arguments
> (term, query, locale). The class takes {{locale}} as a constructor argument
> and the remaining as method arguments. However, the JavaDoc was unchanged and
> shows the {{locale}} method parameter.
> {code:java}
> /**
> *
> * Find the Fuzzy Score which indicates the similarity score between two
> * Strings.
> *
> *
> *
> * score.fuzzyScore(null, null, null) = IllegalArgumentException
> * score.fuzzyScore("", "", Locale.ENGLISH) = 0
> * score.fuzzyScore("Workshop", "b", Locale.ENGLISH) = 0
> * score.fuzzyScore("Room", "o", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "w", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "ws", Locale.ENGLISH) = 2
> * score.fuzzyScore("Workshop", "wo", Locale.ENGLISH) = 4
> * score.fuzzyScore("Apache Software Foundation", "asf", Locale.ENGLISH) = 3
> *
> *
> * @param term a full term that should be matched against, must not be null
> * @param query the query that will be matched against a term, must not be
> * null
> * @return result score
> * @throws IllegalArgumentException if either CharSequence input is {@code
> null}
> */
> public Integer fuzzyScore(final CharSequence term, final CharSequence query)
> {{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TEXT-166) FuzzyScore JavaDoc mistake
[
https://issues.apache.org/jira/browse/TEXT-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated TEXT-166:
Labels: javadoc (was: )
> FuzzyScore JavaDoc mistake
> --
>
> Key: TEXT-166
> URL: https://issues.apache.org/jira/browse/TEXT-166
> Project: Commons Text
> Issue Type: Task
>Affects Versions: 1.8
>Reporter: Ben Manes
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Labels: javadoc
> Fix For: 1.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{FuzzyScore}} was adapted from {{StringUtils#getFuzzyDistance}} and the
> JavaDoc was copied as is. The deprecated utility method took three arguments
> (term, query, locale). The class takes {{locale}} as a constructor argument
> and the remaining as method arguments. However, the JavaDoc was unchanged and
> shows the {{locale}} method parameter.
> {code:java}
> /**
> *
> * Find the Fuzzy Score which indicates the similarity score between two
> * Strings.
> *
> *
> *
> * score.fuzzyScore(null, null, null) = IllegalArgumentException
> * score.fuzzyScore("", "", Locale.ENGLISH) = 0
> * score.fuzzyScore("Workshop", "b", Locale.ENGLISH) = 0
> * score.fuzzyScore("Room", "o", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "w", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "ws", Locale.ENGLISH) = 2
> * score.fuzzyScore("Workshop", "wo", Locale.ENGLISH) = 4
> * score.fuzzyScore("Apache Software Foundation", "asf", Locale.ENGLISH) = 3
> *
> *
> * @param term a full term that should be matched against, must not be null
> * @param query the query that will be matched against a term, must not be
> * null
> * @return result score
> * @throws IllegalArgumentException if either CharSequence input is {@code
> null}
> */
> public Integer fuzzyScore(final CharSequence term, final CharSequence query)
> {{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TEXT-166) FuzzyScore JavaDoc mistake
[
https://issues.apache.org/jira/browse/TEXT-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated TEXT-166:
Affects Version/s: 1.8
> FuzzyScore JavaDoc mistake
> --
>
> Key: TEXT-166
> URL: https://issues.apache.org/jira/browse/TEXT-166
> Project: Commons Text
> Issue Type: Task
>Affects Versions: 1.8
>Reporter: Ben Manes
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 1.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{FuzzyScore}} was adapted from {{StringUtils#getFuzzyDistance}} and the
> JavaDoc was copied as is. The deprecated utility method took three arguments
> (term, query, locale). The class takes {{locale}} as a constructor argument
> and the remaining as method arguments. However, the JavaDoc was unchanged and
> shows the {{locale}} method parameter.
> {code:java}
> /**
> *
> * Find the Fuzzy Score which indicates the similarity score between two
> * Strings.
> *
> *
> *
> * score.fuzzyScore(null, null, null) = IllegalArgumentException
> * score.fuzzyScore("", "", Locale.ENGLISH) = 0
> * score.fuzzyScore("Workshop", "b", Locale.ENGLISH) = 0
> * score.fuzzyScore("Room", "o", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "w", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "ws", Locale.ENGLISH) = 2
> * score.fuzzyScore("Workshop", "wo", Locale.ENGLISH) = 4
> * score.fuzzyScore("Apache Software Foundation", "asf", Locale.ENGLISH) = 3
> *
> *
> * @param term a full term that should be matched against, must not be null
> * @param query the query that will be matched against a term, must not be
> * null
> * @return result score
> * @throws IllegalArgumentException if either CharSequence input is {@code
> null}
> */
> public Integer fuzzyScore(final CharSequence term, final CharSequence query)
> {{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TEXT-166) FuzzyScore JavaDoc mistake
[
https://issues.apache.org/jira/browse/TEXT-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935407#comment-16935407
]
Bruno P. Kinoshita commented on TEXT-166:
-
Thanks for reporting the issue and for the PR. Merging it now on GitHub. Thanks!
> FuzzyScore JavaDoc mistake
> --
>
> Key: TEXT-166
> URL: https://issues.apache.org/jira/browse/TEXT-166
> Project: Commons Text
> Issue Type: Task
>Reporter: Ben Manes
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{FuzzyScore}} was adapted from {{StringUtils#getFuzzyDistance}} and the
> JavaDoc was copied as is. The deprecated utility method took three arguments
> (term, query, locale). The class takes {{locale}} as a constructor argument
> and the remaining as method arguments. However, the JavaDoc was unchanged and
> shows the {{locale}} method parameter.
> {code:java}
> /**
> *
> * Find the Fuzzy Score which indicates the similarity score between two
> * Strings.
> *
> *
> *
> * score.fuzzyScore(null, null, null) = IllegalArgumentException
> * score.fuzzyScore("", "", Locale.ENGLISH) = 0
> * score.fuzzyScore("Workshop", "b", Locale.ENGLISH) = 0
> * score.fuzzyScore("Room", "o", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "w", Locale.ENGLISH) = 1
> * score.fuzzyScore("Workshop", "ws", Locale.ENGLISH) = 2
> * score.fuzzyScore("Workshop", "wo", Locale.ENGLISH) = 4
> * score.fuzzyScore("Apache Software Foundation", "asf", Locale.ENGLISH) = 3
> *
> *
> * @param term a full term that should be matched against, must not be null
> * @param query the query that will be matched against a term, must not be
> * null
> * @return result score
> * @throws IllegalArgumentException if either CharSequence input is {@code
> null}
> */
> public Integer fuzzyScore(final CharSequence term, final CharSequence query)
> {{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (TEXT-149) StringEscapeUtils.unescapeCsv doesn't remove quotes at begin and end of string
[
https://issues.apache.org/jira/browse/TEXT-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved TEXT-149.
-
Resolution: Fixed
> StringEscapeUtils.unescapeCsv doesn't remove quotes at begin and end of string
> --
>
> Key: TEXT-149
> URL: https://issues.apache.org/jira/browse/TEXT-149
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Krzysztof Szalast
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.8.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> org.apache.commons.text.translate.CsvTranslators:
> {code:java}
> void translateWhole(CharSequence input, Writer out) throws IOException {
> if (input.charAt(0) == '"' && input.charAt(input.length() - 1) == '"') {
> String quoteless = input.subSequence(1, input.length() -
> 1).toString();
> if (StringUtils.containsAny(quoteless,
> CsvTranslators.CSV_SEARCH_CHARS)) {
> out.write(StringUtils.replace(quoteless,
> CsvTranslators.CSV_ESCAPED_QUOTE_STR, CsvTranslators.CSV_QUOTE_STR));
> } else {
> out.write(input.toString());
> }
> } else {
> out.write(input.toString());
> }
> }{code}
>
> In my opinion first occurence "out.write(input.toString());" should be
> replaced with:
> {code:java}
> out.write(quoteless.toString());{code}
> Because '"' quotes around "input" will be never removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (VFS-733) Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject
[
https://issues.apache.org/jira/browse/VFS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945554#comment-16945554
]
Bruno P. Kinoshita commented on VFS-733:
Don't know the component and its codebase well enough to have a good opinion on
whether it's safe to remove it or not. But at least looking at the git blame
with GitHub's interface, it doesn't seem to have been added to fix a security
bug.
[https://github.com/apache/commons-vfs/commit/5e5a5eaeba244bde97283135ee3f6d1730850563]
The commit message seems to be related to GC collection for soft references.
But given other class attributes are not set to null, maybe it that line where
parentLayer is set to null could be removed. I wonder if it could also be made
a `private final FileObject` as the `rootName`?
> Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject
> -
>
> Key: VFS-733
> URL: https://issues.apache.org/jira/browse/VFS-733
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2, 2.4, 2.3, 2.4.1
>Reporter: Falco
>Priority: Major
>
> When using {{FileObject#exists}} and {{FileObject#getContent}} on a ZIP file
> (in any order), the reference to the parent file system is set to {{null}}.
> {code}
> final FileObject zippedFile = new OnCallRefreshFileObject(fileInZip());
> assertNotNull(zippedFile.getFileSystem().getParentLayer());
> zippedFile.exists();
> zippedFile.getContent();
> assertNotNull(zippedFile.getFileSystem().getParentLayer()); // fails
> {code}
> For an executable example, refer to
> [https://github.com/f4lco/vfs-repro/blob/master/src/test/java/vfs/ZipParentLayerTest.java].
> I come to believe this does not work as intended. I'm also relatively
> clueless about a potential fix or workaround. For me, this bug blocks
> upgrading from VFS 2.1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IMAGING-245) Add disposal method to GIF metadata
Bruno P. Kinoshita created IMAGING-245: -- Summary: Add disposal method to GIF metadata Key: IMAGING-245 URL: https://issues.apache.org/jira/browse/IMAGING-245 Project: Commons Imaging Issue Type: Improvement Components: Format: GIF Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 Placeholder for https://github.com/apache/commons-imaging/pull/64 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-245) Add disposal method to GIF metadata
[ https://issues.apache.org/jira/browse/IMAGING-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-245. Resolution: Fixed > Add disposal method to GIF metadata > --- > > Key: IMAGING-245 > URL: https://issues.apache.org/jira/browse/IMAGING-245 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: GIF >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > Placeholder for https://github.com/apache/commons-imaging/pull/64 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1514) Test may fail due to a different iteration order
[ https://issues.apache.org/jira/browse/LANG-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated LANG-1514: - Fix Version/s: 3.10 > Test may fail due to a different iteration order > > > Key: LANG-1514 > URL: https://issues.apache.org/jira/browse/LANG-1514 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Reporter: contextshuffling >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 3.10 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Test `testGetAllFieldsList` in `FieldUtilsTest` checks if method > `getAllFields` returns correct fields of a certain class. `getAllFields` > depends on `java.lang.class.getDeclaredFields` to use reflection to get the > fields. However, `java.lang.class.getDeclaredFields` does not guarantee any > specific order of fields returned. Therefore, test will fail if the order > returned by the API is different. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1514) Test may fail due to a different iteration order
[ https://issues.apache.org/jira/browse/LANG-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated LANG-1514: - Affects Version/s: 3.9 > Test may fail due to a different iteration order > > > Key: LANG-1514 > URL: https://issues.apache.org/jira/browse/LANG-1514 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.9 >Reporter: contextshuffling >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 3.10 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Test `testGetAllFieldsList` in `FieldUtilsTest` checks if method > `getAllFields` returns correct fields of a certain class. `getAllFields` > depends on `java.lang.class.getDeclaredFields` to use reflection to get the > fields. However, `java.lang.class.getDeclaredFields` does not guarantee any > specific order of fields returned. Therefore, test will fail if the order > returned by the API is different. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1514) Test may fail due to a different iteration order
[ https://issues.apache.org/jira/browse/LANG-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated LANG-1514: - Assignee: Bruno P. Kinoshita > Test may fail due to a different iteration order > > > Key: LANG-1514 > URL: https://issues.apache.org/jira/browse/LANG-1514 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Reporter: contextshuffling >Assignee: Bruno P. Kinoshita >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > Test `testGetAllFieldsList` in `FieldUtilsTest` checks if method > `getAllFields` returns correct fields of a certain class. `getAllFields` > depends on `java.lang.class.getDeclaredFields` to use reflection to get the > fields. However, `java.lang.class.getDeclaredFields` does not guarantee any > specific order of fields returned. Therefore, test will fail if the order > returned by the API is different. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMAGING-249) Make IPTCBlock fields private
[ https://issues.apache.org/jira/browse/IMAGING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-249. Resolution: Fixed > Make IPTCBlock fields private > - > > Key: IMAGING-249 > URL: https://issues.apache.org/jira/browse/IMAGING-249 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > > Placeholder for [https://github.com/apache/commons-imaging/pull/69] > Fixes a TODO left during review for 1.0 (from some years ago) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMAGING-249) Make IPTCBlock fields private
Bruno P. Kinoshita created IMAGING-249: -- Summary: Make IPTCBlock fields private Key: IMAGING-249 URL: https://issues.apache.org/jira/browse/IMAGING-249 Project: Commons Imaging Issue Type: Improvement Components: imaging.* Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 Placeholder for [https://github.com/apache/commons-imaging/pull/69] Fixes a TODO left during review for 1.0 (from some years ago) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-738) The last assertNull in IterableUtilsTest.find is redundant
[
https://issues.apache.org/jira/browse/COLLECTIONS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated COLLECTIONS-738:
---
Assignee: Bruno P. Kinoshita
> The last assertNull in IterableUtilsTest.find is redundant
> --
>
> Key: COLLECTIONS-738
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-738
> Project: Commons Collections
> Issue Type: Test
> Components: Iterator
>Reporter: Pengyu Nie
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The last assertNull in IterableUtilsTest.find (line 277, as shown
> below), is redundant and confusing; it will not be invoked because
> IterableUtils.find(*, null) should not return any value but just throw
> NullPointerException. I will make a PR to clarify this.
> {code:java}
> try {
> assertNull(IterableUtils.find(iterableA, null));
> fail("expecting NullPointerException");
> } catch (final NullPointerException npe) {
> // expected
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-738) The last assertNull in IterableUtilsTest.find is redundant
[
https://issues.apache.org/jira/browse/COLLECTIONS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated COLLECTIONS-738:
---
Fix Version/s: 4.5
> The last assertNull in IterableUtilsTest.find is redundant
> --
>
> Key: COLLECTIONS-738
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-738
> Project: Commons Collections
> Issue Type: Test
> Components: Iterator
>Affects Versions: 4.4
>Reporter: Pengyu Nie
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 4.5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The last assertNull in IterableUtilsTest.find (line 277, as shown
> below), is redundant and confusing; it will not be invoked because
> IterableUtils.find(*, null) should not return any value but just throw
> NullPointerException. I will make a PR to clarify this.
> {code:java}
> try {
> assertNull(IterableUtils.find(iterableA, null));
> fail("expecting NullPointerException");
> } catch (final NullPointerException npe) {
> // expected
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (COLLECTIONS-738) The last assertNull in IterableUtilsTest.find is redundant
[
https://issues.apache.org/jira/browse/COLLECTIONS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved COLLECTIONS-738.
Resolution: Fixed
> The last assertNull in IterableUtilsTest.find is redundant
> --
>
> Key: COLLECTIONS-738
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-738
> Project: Commons Collections
> Issue Type: Test
> Components: Iterator
>Affects Versions: 4.4
>Reporter: Pengyu Nie
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 4.5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The last assertNull in IterableUtilsTest.find (line 277, as shown
> below), is redundant and confusing; it will not be invoked because
> IterableUtils.find(*, null) should not return any value but just throw
> NullPointerException. I will make a PR to clarify this.
> {code:java}
> try {
> assertNull(IterableUtils.find(iterableA, null));
> fail("expecting NullPointerException");
> } catch (final NullPointerException npe) {
> // expected
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-738) The last assertNull in IterableUtilsTest.find is redundant
[
https://issues.apache.org/jira/browse/COLLECTIONS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated COLLECTIONS-738:
---
Affects Version/s: 4.4
> The last assertNull in IterableUtilsTest.find is redundant
> --
>
> Key: COLLECTIONS-738
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-738
> Project: Commons Collections
> Issue Type: Test
> Components: Iterator
>Affects Versions: 4.4
>Reporter: Pengyu Nie
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The last assertNull in IterableUtilsTest.find (line 277, as shown
> below), is redundant and confusing; it will not be invoked because
> IterableUtils.find(*, null) should not return any value but just throw
> NullPointerException. I will make a PR to clarify this.
> {code:java}
> try {
> assertNull(IterableUtils.find(iterableA, null));
> fail("expecting NullPointerException");
> } catch (final NullPointerException npe) {
> // expected
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-246) Invalid Block Size error prevents handling of block 1084, Macintosh NSPrintInfo
[
https://issues.apache.org/jira/browse/IMAGING-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-246:
---
Description:
When processing an image created on a Mac with Adobe Photoshop which contains
embedded metadata having block 1084, an invalid block size error occurs.
|0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific info
for Macintosh. NSPrintInfo. It is recommened that you do not interpret or use
this data.|
Here is some simple test code that replicates what our application is trying to
do, and recreates the error:
{code:java}
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class RegexMatches {
public static void main(String args[]) {// String to be scanned to
find the pattern.
String line = "This order was placed for QT3000! OK?";
String pattern = "(.*)(\\d+)(.*)";// Create a Pattern object
Pattern r = Pattern.compile(pattern);// Now create matcher
object.
Matcher m = r.matcher(line);
if (m.find()) {
System.out.println("Found value: " + m.group(0));
System.out.println("Found value: " + m.group(1));
System.out.println("Found value: " + m.group(2));
} else {
System.out.println("NO MATCH");
}
}
}{code}
Here is the resulting error:
{noformat}
Exception in thread "main" org.apache.commons.imaging.ImageReadException:
Invalid Block Size : 89562 > 65504Exception in thread "main"
org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
65504 at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
at
org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:635) at
Main.getMetaData(Main.java:22) at Main.main(Main.java:17){noformat}
was:
When processing an image created on a Mac with Adobe Photoshop which contains
embedded metadata having block 1084, an invalid block size error occurs.
|0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific info
for Macintosh. NSPrintInfo. It is recommened that you do not interpret or use
this data.|
Here is some simple test code that replicates what our application is trying to
do, and recreates the error:
{code:java}
import org.apache.commons.imaging.ImageInfo;
import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.Imaging;
import org.apache.commons.io.FileUtils;
import java.io.File;
import java.io.IOException;
import java.util.Base64;
public class Main {
public static void main(String[] args) throws IOException, ImageReadException
{ String fileName = "FallHarvestKitKat_07610.jpg"; ClassLoader classLoader =
ClassLoader.getSystemClassLoader(); File file = new
File(classLoader.getResource(fileName).getFile()); byte[] fileContent =
FileUtils.readFileToByteArray(file); String encodedString =
Base64.getEncoder().encodeToString(fileContent); byte[] decodedValue =
Base64.getDecoder().decode(encodedString); ImageInfo imageInfo =
Imaging.getImageInfo(decodedValue); }
}{code}
Here is the resulting error:
{noformat}
Exception in thread "main" org.apache.commons.imaging.ImageReadException:
Invalid Block Size : 89562 > 65504Exception in thread "main"
org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
65504 at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
at
org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
[jira] [Updated] (IMAGING-246) Invalid Block Size error prevents handling of block 1084, Macintosh NSPrintInfo
[
https://issues.apache.org/jira/browse/IMAGING-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-246:
---
Description:
When processing an image created on a Mac with Adobe Photoshop which contains
embedded metadata having block 1084, an invalid block size error occurs.
|0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific info
for Macintosh. NSPrintInfo. It is recommened that you do not interpret or use
this data.|
Here is some simple test code that replicates what our application is trying to
do, and recreates the error:
{code:java}
import org.apache.commons.imaging.ImageInfo;
import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.Imaging;
import org.apache.commons.io.FileUtils;
import java.io.File;
import java.io.IOException;
import java.util.Base64;
public class Main {
public static void main(String[] args) throws IOException, ImageReadException
{ String fileName = "FallHarvestKitKat_07610.jpg"; ClassLoader classLoader =
ClassLoader.getSystemClassLoader(); File file = new
File(classLoader.getResource(fileName).getFile()); byte[] fileContent =
FileUtils.readFileToByteArray(file); String encodedString =
Base64.getEncoder().encodeToString(fileContent); byte[] decodedValue =
Base64.getDecoder().decode(encodedString); ImageInfo imageInfo =
Imaging.getImageInfo(decodedValue); }
}{code}
Here is the resulting error:
{noformat}
Exception in thread "main" org.apache.commons.imaging.ImageReadException:
Invalid Block Size : 89562 > 65504Exception in thread "main"
org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
65504 at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
at
org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:635) at
Main.getMetaData(Main.java:22) at Main.main(Main.java:17){noformat}
was:
When processing an image created on a Mac with Adobe Photoshop which contains
embedded metadata having block 1084, an invalid block size error occurs.
|0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific info
for Macintosh. NSPrintInfo. It is recommened that you do not interpret or use
this data.|
Here is some simple test code that replicates what our application is trying to
do, and recreates the error:
import org.apache.commons.imaging.ImageInfo;
import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.Imaging;
import org.apache.commons.io.FileUtils;
import java.io.File;
import java.io.IOException;
import java.util.Base64;
public class Main {
public static void main(String[] args) throws IOException, ImageReadException {
String fileName = "FallHarvestKitKat_07610.jpg";
ClassLoader classLoader = ClassLoader.getSystemClassLoader();
File file = new File(classLoader.getResource(fileName).getFile());
byte[] fileContent = FileUtils.readFileToByteArray(file);
String encodedString = Base64.getEncoder().encodeToString(fileContent);
byte[] decodedValue = Base64.getDecoder().decode(encodedString);
ImageInfo imageInfo = Imaging.getImageInfo(decodedValue);
}
}
Here is the resulting error:
Exception in thread "main" org.apache.commons.imaging.ImageReadException:
Invalid Block Size : 89562 > 65504Exception in thread "main"
org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
65504 at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
at
org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
[jira] [Updated] (IMAGING-246) Invalid Block Size error prevents handling of block 1084, Macintosh NSPrintInfo
[
https://issues.apache.org/jira/browse/IMAGING-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-246:
---
Description:
When processing an image created on a Mac with Adobe Photoshop which contains
embedded metadata having block 1084, an invalid block size error occurs.
|0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific info
for Macintosh. NSPrintInfo. It is recommened that you do not interpret or use
this data.|
Here is some simple test code that replicates what our application is trying to
do, and recreates the error:
{code:java}
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class RegexMatches {
public static void main(String args[]) {// String to be scanned to
find the pattern.
String line = "This order was placed for QT3000! OK?";
String pattern = "(.*)(\\d+)(.*)";// Create a Pattern object
Pattern r = Pattern.compile(pattern);// Now create matcher
object.
Matcher m = r.matcher(line);
if (m.find()) {
System.out.println("Found value: " + m.group(0));
System.out.println("Found value: " + m.group(1));
System.out.println("Found value: " + m.group(2));
} else {
System.out.println("NO MATCH");
}
}
}{code}
Here is the resulting error:
{noformat}
Exception in thread "main" org.apache.commons.imaging.ImageReadException:
Invalid Block Size : 89562 > 65504Exception in thread "main"
org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
65504 at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
at
org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:635) at
Main.getMetaData(Main.java:22) at Main.main(Main.java:17){noformat}
was:
When processing an image created on a Mac with Adobe Photoshop which contains
embedded metadata having block 1084, an invalid block size error occurs.
|0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific info
for Macintosh. NSPrintInfo. It is recommened that you do not interpret or use
this data.|
Here is some simple test code that replicates what our application is trying to
do, and recreates the error:
{code:java}
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class RegexMatches {
public static void main(String args[]) {// String to be scanned to
find the pattern.
String line = "This order was placed for QT3000! OK?";
String pattern = "(.*)(\\d+)(.*)";// Create a Pattern object
Pattern r = Pattern.compile(pattern);// Now create matcher
object.
Matcher m = r.matcher(line);
if (m.find()) {
System.out.println("Found value: " + m.group(0));
System.out.println("Found value: " + m.group(1));
System.out.println("Found value: " + m.group(2));
} else {
System.out.println("NO MATCH");
}
}
}{code}
Here is the resulting error:
{noformat}
Exception in thread "main" org.apache.commons.imaging.ImageReadException:
Invalid Block Size : 89562 > 65504Exception in thread "main"
org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
65504 at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
at
org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
at
org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:635) at
[jira] [Commented] (IMAGING-246) Invalid Block Size error prevents handling of block 1084, Macintosh NSPrintInfo
[
https://issues.apache.org/jira/browse/IMAGING-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013395#comment-17013395
]
Bruno P. Kinoshita commented on IMAGING-246:
No problem [~lwollerman] , you reported the issue with example code and an
attachment to reproduce it, and with a good issue description. I've just
updated the formatting to use the code and the noformat macros (I type the
macros, but there are some buttons in the editor that can help too).
Will try to reproduce and debug the issue later. Thanks!!!
> Invalid Block Size error prevents handling of block 1084, Macintosh
> NSPrintInfo
> ---
>
> Key: IMAGING-246
> URL: https://issues.apache.org/jira/browse/IMAGING-246
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: Liberty Wollerman
>Priority: Major
> Attachments: FallHarvestKitKat_07610.jpg
>
>
> When processing an image created on a Mac with Adobe Photoshop which contains
> embedded metadata having block 1084, an invalid block size error occurs.
> |0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific
> info for Macintosh. NSPrintInfo. It is recommened that you do not interpret
> or use this data.|
>
> Here is some simple test code that replicates what our application is trying
> to do, and recreates the error:
> {code:java}
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> public class RegexMatches {
> public static void main(String args[]) {// String to be scanned
> to find the pattern.
> String line = "This order was placed for QT3000! OK?";
> String pattern = "(.*)(\\d+)(.*)";// Create a Pattern object
> Pattern r = Pattern.compile(pattern);// Now create matcher
> object.
> Matcher m = r.matcher(line);
> if (m.find()) {
> System.out.println("Found value: " + m.group(0));
> System.out.println("Found value: " + m.group(1));
> System.out.println("Found value: " + m.group(2));
> } else {
> System.out.println("NO MATCH");
> }
> }
> }{code}
>
> Here is the resulting error:
> {noformat}
> Exception in thread "main" org.apache.commons.imaging.ImageReadException:
> Invalid Block Size : 89562 > 65504Exception in thread "main"
> org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
> 65504 at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
> at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
> at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
> at
>
> org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
> at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
> org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:635) at
> Main.getMetaData(Main.java:22) at Main.main(Main.java:17){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
