[jira] [Updated] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF
[
https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-265:
---
Fix Version/s: 1.0-alpha3
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
>
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha3
>
> Attachments: small_world.tif, small_world_split.jpg
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF
[
https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-265.
Resolution: Fixed
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
>
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: small_world.tif, small_world_split.jpg
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF
[
https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209994#comment-17209994
]
Bruno P. Kinoshita commented on IMAGING-265:
Fixed in master. Included in the changelog for the next alpha release.
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
>
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha3
>
> Attachments: small_world.tif, small_world_split.jpg
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF
[
https://issues.apache.org/jira/browse/IMAGING-265?focusedWorklogId=497067=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-497067
]
ASF GitHub Bot logged work on IMAGING-265:
--
Author: ASF GitHub Bot
Created on: 08/Oct/20 04:14
Start Date: 08/Oct/20 04:14
Worklog Time Spent: 10m
Work Description: kinow commented on pull request #98:
URL: https://github.com/apache/commons-imaging/pull/98#issuecomment-705318187
Merged. Here's what I did to merge @gwlucastrig
- checked out branch locally
- added a commit with the `src/changes/changes.xml` entry for this issue
- squashed commits
- reworded commit to match the change, using the [IMAGING-265] prefix
These are not a must-have, but really nice-to-have, as other components
follow this pattern. This helps other common developers to maintain the code.
:+1: just because you are already familiar with most of the ASF development
process, so I thought it would be interesting to share more of what happens
with the PR's/issues with you :-)
Thanks again for the contribution!
Bruno
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 497067)
Time Spent: 3h 20m (was: 3h 10m)
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
>
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: small_world.tif, small_world_split.jpg
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #98: [IMAGING-265] ArrayIndexOutOfBoundsException on reading simple GeoTIFF
kinow commented on pull request #98: URL: https://github.com/apache/commons-imaging/pull/98#issuecomment-705318187 Merged. Here's what I did to merge @gwlucastrig - checked out branch locally - added a commit with the `src/changes/changes.xml` entry for this issue - squashed commits - reworded commit to match the change, using the [IMAGING-265] prefix These are not a must-have, but really nice-to-have, as other components follow this pattern. This helps other common developers to maintain the code. :+1: just because you are already familiar with most of the ASF development process, so I thought it would be interesting to share more of what happens with the PR's/issues with you :-) Thanks again for the contribution! Bruno This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF
[
https://issues.apache.org/jira/browse/IMAGING-265?focusedWorklogId=497066=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-497066
]
ASF GitHub Bot logged work on IMAGING-265:
--
Author: ASF GitHub Bot
Created on: 08/Oct/20 04:11
Start Date: 08/Oct/20 04:11
Worklog Time Spent: 10m
Work Description: kinow closed pull request #98:
URL: https://github.com/apache/commons-imaging/pull/98
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 497066)
Time Spent: 3h 10m (was: 3h)
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
>
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: small_world.tif, small_world_split.jpg
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] kinow closed pull request #98: [IMAGING-265] ArrayIndexOutOfBoundsException on reading simple GeoTIFF
kinow closed pull request #98: URL: https://github.com/apache/commons-imaging/pull/98 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] gwlucastrig commented on pull request #98: [IMAGING-265] ArrayIndexOutOfBoundsException on reading simple GeoTIFF
gwlucastrig commented on pull request #98: URL: https://github.com/apache/commons-imaging/pull/98#issuecomment-705252894 I believe this completes the work for Imaging-265. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF
[
https://issues.apache.org/jira/browse/IMAGING-265?focusedWorklogId=497011=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-497011
]
ASF GitHub Bot logged work on IMAGING-265:
--
Author: ASF GitHub Bot
Created on: 07/Oct/20 23:55
Start Date: 07/Oct/20 23:55
Worklog Time Spent: 10m
Work Description: gwlucastrig commented on pull request #98:
URL: https://github.com/apache/commons-imaging/pull/98#issuecomment-705252894
I believe this completes the work for Imaging-265.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 497011)
Time Spent: 3h (was: 2h 50m)
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
>
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: small_world.tif, small_world_split.jpg
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IMAGING-201) Significant change in color of output image of tiff file
[
https://issues.apache.org/jira/browse/IMAGING-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209933#comment-17209933
]
Gary Lucas edited comment on IMAGING-201 at 10/7/20, 11:53 PM:
---
I investigated this further and I have a solution based on the existing Commons
Imaging API. Because the example file includes an ICC color profile, the TIFF
reading functions must use that to interpret the colors. I haven't studied
color profiles in any depth, so there may be more efficient ways of handling
this, but here's my solution.
The key is to read the ICC color profile from the file and then use it to
create a custom photometric interpreter that can be used to convert the CMYK
data from the file to RGB values used by the Java API. In the example below,
I use the high-level Imaging class for simplicity and clarity. There are
lower-level TIFF classes and methods that would give you more control and
flexibility, but they are a bit too complicated for this example.
The sample file provided by the Praful Vaishnav is rather large, 3976-by-5965
pixels. Fortunately, it was still available on dropbox. Running it through
the TIFF reader requires 19 seconds. 16 seconds of that is used by the Java
ICC_Profile.toRGB() method. Anyway, I've attached a copy of my results (size
reduced, of course) and the example code is given below.
{code:java}
import java.awt.color.ICC_ColorSpace;
import java.awt.color.ICC_Profile;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;
import java.util.HashMap;
import javax.imageio.ImageIO;
import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.Imaging;
import org.apache.commons.imaging.common.ImageBuilder;
import org.apache.commons.imaging.formats.tiff.constants.TiffConstants;
import
org.apache.commons.imaging.formats.tiff.photometricinterpreters.PhotometricInterpreter;
public class ExampleIccProfile {
public static void main(String[] args) throws ImageReadException,
IOException {
// For this demo, we have a TIFF file known to have an ICC Profile
// Use the high-level Imaging class to read it.
File file = new File(args[0]);
ICC_Profile profile = Imaging.getICCProfile(file);
// Create a custom instance of PhotometricInterpreter that
// uses the ICC Profile. Most of the constructor arguments for
// the PhotometricInterpreter are legacy elements that aren't
// actually used. But we populate them here for demonstration.
int[] bitsPerPixel = new int[]{8, 8, 8, 8};
PhotometricInterpreterICC pi
= new PhotometricInterpreterICC(
bitsPerPixel.length,
bitsPerPixel,
-1, // predictor, not used,
0, // image width,
0, // image height, not used,
profile);
// Commons Imaging uses a Java Map to pass in special processing
// options. Add the custom PhotometricInterpreter
HashMap params = new HashMap();
params.put(TiffConstants.PARAM_KEY_CUSTOM_PHOTOMETRIC_INTERPRETER, pi);
BufferedImage bImage = Imaging.getBufferedImage(file, params);
ImageIO.write(bImage, "JPEG", new File("test.jpg"));
}
// Here's the implementation of the custom Photometric Interpreter
private static class PhotometricInterpreterICC extends
PhotometricInterpreter {
private final ICC_ColorSpace iccColorSpace;
public PhotometricInterpreterICC(
final int samplesPerPixel,
final int[] bitsPerSample,
final int predictor,
final int width,
final int height,
final ICC_Profile iccProfile) {
super(samplesPerPixel, bitsPerSample, predictor, width, height);
iccColorSpace = new ICC_ColorSpace(iccProfile);
}
@Override
public void interpretPixel(
ImageBuilder imageBuilder,
int[] samples,
int x, int y) throws ImageReadException, IOException {
float[] s = new float[samplesPerPixel];
s[0] = ((samples[0] & 0xff)) / 255.0f;
s[1] = ((samples[1] & 0xff)) / 255.0f;
s[2] = ((samples[2] & 0xff)) / 255.0f;
s[3] = ((samples[3] & 0xff)) / 255.0f;
float[] f = iccColorSpace.toRGB(s);
int r = (int) (f[0] * 255 + 0.5);
int g = (int) (f[1] * 255 + 0.5);
int b = (int) (f[2] * 255 + 0.5);
int argb = 0xff00 | r) << 8) | g) << 8) | b;
imageBuilder.setRGB(x, y, argb);
}
}
}
{code}
!Imaging201_CustomPhotometricInterpreter.jpg!
was (Author: gwlucas):
In investigated this further and I have a solution based on the existing
Commons Imaging API. Because the example file includes an ICC color profile,
the TIFF reading functions must use that to interpret the
[jira] [Commented] (IMAGING-201) Significant change in color of output image of tiff file
[
https://issues.apache.org/jira/browse/IMAGING-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209933#comment-17209933
]
Gary Lucas commented on IMAGING-201:
In investigated this further and I have a solution based on the existing
Commons Imaging API. Because the example file includes an ICC color profile,
the TIFF reading functions must use that to interpret the colors. I haven't
studied color profiles in any depth, so there may be more efficient ways of
handling this, but here's my solution.
The key is to read the ICC color profile from the file and then use it to
create a custom photometric interpreter that can be used to convert the CMYK
data from the file to RGB values used by the Java API. In the example below,
I use the high-level Imaging class for simplicity and clarity. There are
lower-level TIFF classes and methods that would give you more control and
flexibility, but they are a bit too complicated for this example.
The sample file provided by the Praful Vaishnav is rather large, 3976-by-5965
pixels. Fortunately, it was still available on dropbox. Running it through
the TIFF reader requires 19 seconds. 16 seconds of that is used by the Java
ICC_Profile.toRGB() method. Anyway, I've attached a copy of my results (size
reduced, of course) and the example code is given below.
{code:java}
import java.awt.color.ICC_ColorSpace;
import java.awt.color.ICC_Profile;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;
import java.util.HashMap;
import javax.imageio.ImageIO;
import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.Imaging;
import org.apache.commons.imaging.common.ImageBuilder;
import org.apache.commons.imaging.formats.tiff.constants.TiffConstants;
import
org.apache.commons.imaging.formats.tiff.photometricinterpreters.PhotometricInterpreter;
public class ExampleIccProfile {
public static void main(String[] args) throws ImageReadException,
IOException {
// For this demo, we have a TIFF file known to have an ICC Profile
// Use the high-level Imaging class to read it.
File file = new File(args[0]);
ICC_Profile profile = Imaging.getICCProfile(file);
// Create a custom instance of PhotometricInterpreter that
// uses the ICC Profile. Most of the constructor arguments for
// the PhotometricInterpreter are legacy elements that aren't
// actually used. But we populate them here for demonstration.
int[] bitsPerPixel = new int[]{8, 8, 8, 8};
PhotometricInterpreterICC pi
= new PhotometricInterpreterICC(
bitsPerPixel.length,
bitsPerPixel,
-1, // predictor, not used,
0, // image width,
0, // image height, not used,
profile);
// Commons Imaging uses a Java Map to pass in special processing
// options. Add the custom PhotometricInterpreter
HashMap params = new HashMap();
params.put(TiffConstants.PARAM_KEY_CUSTOM_PHOTOMETRIC_INTERPRETER, pi);
BufferedImage bImage = Imaging.getBufferedImage(file, params);
ImageIO.write(bImage, "JPEG", new File("test.jpg"));
}
// Here's the implementation of the custom Photometric Interpreter
private static class PhotometricInterpreterICC extends
PhotometricInterpreter {
private final ICC_ColorSpace iccColorSpace;
public PhotometricInterpreterICC(
final int samplesPerPixel,
final int[] bitsPerSample,
final int predictor,
final int width,
final int height,
final ICC_Profile iccProfile) {
super(samplesPerPixel, bitsPerSample, predictor, width, height);
iccColorSpace = new ICC_ColorSpace(iccProfile);
}
@Override
public void interpretPixel(
ImageBuilder imageBuilder,
int[] samples,
int x, int y) throws ImageReadException, IOException {
float[] s = new float[samplesPerPixel];
s[0] = ((samples[0] & 0xff)) / 255.0f;
s[1] = ((samples[1] & 0xff)) / 255.0f;
s[2] = ((samples[2] & 0xff)) / 255.0f;
s[3] = ((samples[3] & 0xff)) / 255.0f;
float[] f = iccColorSpace.toRGB(s);
int r = (int) (f[0] * 255 + 0.5);
int g = (int) (f[1] * 255 + 0.5);
int b = (int) (f[2] * 255 + 0.5);
int argb = 0xff00 | r) << 8) | g) << 8) | b;
imageBuilder.setRGB(x, y, argb);
}
}
}
{code}
!Imaging201_CustomPhotometricInterpreter.jpg!
> Significant change in color of output image of tiff file
>
>
> Key: IMAGING-201
> URL: https://issues.apache.org/jira/browse/IMAGING-201
> Project: Commons Imaging
> Issue Type:
[jira] [Updated] (IMAGING-201) Significant change in color of output image of tiff file
[
https://issues.apache.org/jira/browse/IMAGING-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Lucas updated IMAGING-201:
---
Attachment: Imaging201_CustomPhotometricInterpreter.jpg
> Significant change in color of output image of tiff file
>
>
> Key: IMAGING-201
> URL: https://issues.apache.org/jira/browse/IMAGING-201
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1
>Reporter: Praful Vaishnav
>Priority: Major
> Attachments: Imaging201_CustomPhotometricInterpreter.jpg,
> SS_result.png, SS_source.png
>
>
> Hii.. I am reading tiff image file and using this library to convert it to
> PNG format. Resultant png file has significant change in color wrt its
> original tiff file. Below is the code :
> {code:java}
> File file = new File("C:\\original.tiff");
> BufferedImage bi = Imaging.getBufferedImage(file);
> File dstFile = new File("C:\\result.png");
> Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);
> {code}
> Reason could be :
> original image is 32 bit depth and result image is 24 bit depth. Is there any
> issue with 32 bit depth image file.
> Link for source tiff file -
> https://www.dropbox.com/s/kgqgdcygelkor8b/original.tiff?dl=0
> Attachements:
> SS_source.png - Screenshot of original tiff file
> SS_result.png - Screenshot of result png file
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF
[
https://issues.apache.org/jira/browse/IMAGING-265?focusedWorklogId=497000=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-497000
]
ASF GitHub Bot logged work on IMAGING-265:
--
Author: ASF GitHub Bot
Created on: 07/Oct/20 23:14
Start Date: 07/Oct/20 23:14
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #98:
URL: https://github.com/apache/commons-imaging/pull/98#issuecomment-695154317
[](https://coveralls.io/builds/34011743)
Coverage increased (+0.06%) to 76.389% when pulling
**a132c09fa2d08a6e4be65763e58874a8eb4fc27e on gwlucastrig:IMAGING-265** into
**5ab6b2059f9201fdec1d73991f6ffce65ae18e79 on apache:master**.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 497000)
Time Spent: 2h 50m (was: 2h 40m)
> ArrayIndexOutOfBoundsException on reading simple GeoTIFF
>
>
> Key: IMAGING-265
> URL: https://issues.apache.org/jira/browse/IMAGING-265
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha2
>Reporter: edgar soldin
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: small_world.tif, small_world_split.jpg
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> hi,
>
> we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging .
> for details you may find a ticket in our bug tracker
> [https://sourceforge.net/p/jump-pilot/bugs/498/] .
>
> the gist is: on loading the attached file getBufferedImage() fails with this
> stack
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8000Caused by:
> java.lang.ArrayIndexOutOfBoundsException: 8000 at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.interpretStrip(DataReaderStrips.java:196)
> at
> org.apache.commons.imaging.formats.tiff.datareaders.DataReaderStrips.readImageData(DataReaderStrips.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:665)
> at
> org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:254)
> at
> org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:469)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1442) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1335) at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1304) at
> com.vividsolutions.jump.workbench.imagery.graphic.CommonsImage.initImage(CommonsImage.java:108){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] coveralls edited a comment on pull request #98: [IMAGING-265] ArrayIndexOutOfBoundsException on reading simple GeoTIFF
coveralls edited a comment on pull request #98: URL: https://github.com/apache/commons-imaging/pull/98#issuecomment-695154317 [](https://coveralls.io/builds/34011743) Coverage increased (+0.06%) to 76.389% when pulling **a132c09fa2d08a6e4be65763e58874a8eb4fc27e on gwlucastrig:IMAGING-265** into **5ab6b2059f9201fdec1d73991f6ffce65ae18e79 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NET-690) Performance issue when using the FTPClient to retrieve files from z/OS and z/VM
[
https://issues.apache.org/jira/browse/NET-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated NET-690:
Fix Version/s: (was: 3.7.2)
> Performance issue when using the FTPClient to retrieve files from z/OS and
> z/VM
> ---
>
> Key: NET-690
> URL: https://issues.apache.org/jira/browse/NET-690
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.7,1
> Environment: {code:java}
> Java 8, FTP server on z/OS | z/VM{code}
>Reporter: Payal
>Priority: Major
>
> Performance issue when using the FTPClient to retrieve files from z/OS and
> z/VMPerformance issue when using the FTPClient to retrieve files from z/OS
> and z/VM
> There is a significant performance drop off when using the FTPClient to
> retrieve files from z/OS and z/VM ( I haven't tested against other operating
> systems). If I switch to using the FTPSClient I don't see the same problem.
> The following is the command output when doing a retrieve of a file from z/OS
> which is only 2.0KB in size:
> *FTPClient:*
> 2020-10-07 08:30:46.261 SENT>>> RETR
> 2020-10-07 08:30:46.291 RECD<<< 125 Sending data set TEST.FTP(PART11B)
> FIXrecfm 80
> 2020-10-07 08:32:46.342 RECD<<< 250 Transfer completed successfully.
> *FTPSClient:*
> 2020-10-07 08:30:45.813 SENT>>> RETR
> 2020-10-07 08:30:45.843 RECD<<< 125 Sending data set TEST.FTP(PART11B)
> FIXrecfm 80
> 2020-10-07 08:30:46.014 RECD<<< 250 Transfer completed successfully.
> The first transfer using the FTPClient took 2 minutes, which when switching
> to using FTPS take less than a second. This has only been an issue since
> upgrading from commons-net 3.6 to 3.7.1. It seems to consistently take 2
> minutes transfer pretty much regardless of the size of the file, so appears
> to be waiting on something or hitting a timeout of some sort.
> I have added the code I'm using to establish the FTPClient and connect to the
> host and to retrieve the file.
>
> {code:java}
> //Establish the FTPClient and connect to the host
> private FTPClient getFTPClient(String host, String userProperty, String
> passwordProperty) throws SocketException, IOException {
> FTPClient client = new FTPClient();
> client.addProtocolCommandListener(this);
> client.connect(host);
> client.login(getProperties().getProperty(userProperty),
> getProperties().getProperty(passwordProperty));
> client.enterLocalPassiveMode();
> return client;
> }
> //Retrieve file
> private void getFile(String remoteDir,String localDir, String file,
> FTPClient client) throws IOException, FileNotFoundException {
> client.changeWorkingDirectory(remoteDir);
> client.setFileType(FTP.BINARY_FILE_TYPE);
> BufferedOutputStream bo = new BufferedOutputStream(new
> FileOutputStream(localDir + file));
> client.retrieveFile(file, bo);
> bo.close();
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NET-690) Performance issue when using the FTPClient to retrieve files from z/OS and z/VM
[
https://issues.apache.org/jira/browse/NET-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209806#comment-17209806
]
Gary D. Gregory commented on NET-690:
-
Feel free to provide a PR on GitHub :-)
> Performance issue when using the FTPClient to retrieve files from z/OS and
> z/VM
> ---
>
> Key: NET-690
> URL: https://issues.apache.org/jira/browse/NET-690
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.7,1
> Environment: {code:java}
> Java 8, FTP server on z/OS | z/VM{code}
>Reporter: Payal
>Priority: Major
>
> Performance issue when using the FTPClient to retrieve files from z/OS and
> z/VMPerformance issue when using the FTPClient to retrieve files from z/OS
> and z/VM
> There is a significant performance drop off when using the FTPClient to
> retrieve files from z/OS and z/VM ( I haven't tested against other operating
> systems). If I switch to using the FTPSClient I don't see the same problem.
> The following is the command output when doing a retrieve of a file from z/OS
> which is only 2.0KB in size:
> *FTPClient:*
> 2020-10-07 08:30:46.261 SENT>>> RETR
> 2020-10-07 08:30:46.291 RECD<<< 125 Sending data set TEST.FTP(PART11B)
> FIXrecfm 80
> 2020-10-07 08:32:46.342 RECD<<< 250 Transfer completed successfully.
> *FTPSClient:*
> 2020-10-07 08:30:45.813 SENT>>> RETR
> 2020-10-07 08:30:45.843 RECD<<< 125 Sending data set TEST.FTP(PART11B)
> FIXrecfm 80
> 2020-10-07 08:30:46.014 RECD<<< 250 Transfer completed successfully.
> The first transfer using the FTPClient took 2 minutes, which when switching
> to using FTPS take less than a second. This has only been an issue since
> upgrading from commons-net 3.6 to 3.7.1. It seems to consistently take 2
> minutes transfer pretty much regardless of the size of the file, so appears
> to be waiting on something or hitting a timeout of some sort.
> I have added the code I'm using to establish the FTPClient and connect to the
> host and to retrieve the file.
>
> {code:java}
> //Establish the FTPClient and connect to the host
> private FTPClient getFTPClient(String host, String userProperty, String
> passwordProperty) throws SocketException, IOException {
> FTPClient client = new FTPClient();
> client.addProtocolCommandListener(this);
> client.connect(host);
> client.login(getProperties().getProperty(userProperty),
> getProperties().getProperty(passwordProperty));
> client.enterLocalPassiveMode();
> return client;
> }
> //Retrieve file
> private void getFile(String remoteDir,String localDir, String file,
> FTPClient client) throws IOException, FileNotFoundException {
> client.changeWorkingDirectory(remoteDir);
> client.setFileType(FTP.BINARY_FILE_TYPE);
> BufferedOutputStream bo = new BufferedOutputStream(new
> FileOutputStream(localDir + file));
> client.retrieveFile(file, bo);
> bo.close();
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NET-690) Performance issue when using the FTPClient to retrieve files from z/OS and z/VM
Payal created NET-690:
-
Summary: Performance issue when using the FTPClient to retrieve
files from z/OS and z/VM
Key: NET-690
URL: https://issues.apache.org/jira/browse/NET-690
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.7,1
Environment: {code:java}
Java 8, FTP server on z/OS | z/VM{code}
Reporter: Payal
Fix For: 3.7.2
Performance issue when using the FTPClient to retrieve files from z/OS and
z/VMPerformance issue when using the FTPClient to retrieve files from z/OS and
z/VM
There is a significant performance drop off when using the FTPClient to
retrieve files from z/OS and z/VM ( I haven't tested against other operating
systems). If I switch to using the FTPSClient I don't see the same problem.
The following is the command output when doing a retrieve of a file from z/OS
which is only 2.0KB in size:
*FTPClient:*
2020-10-07 08:30:46.261 SENT>>> RETR
2020-10-07 08:30:46.291 RECD<<< 125 Sending data set TEST.FTP(PART11B) FIXrecfm
80
2020-10-07 08:32:46.342 RECD<<< 250 Transfer completed successfully.
*FTPSClient:*
2020-10-07 08:30:45.813 SENT>>> RETR
2020-10-07 08:30:45.843 RECD<<< 125 Sending data set TEST.FTP(PART11B) FIXrecfm
80
2020-10-07 08:30:46.014 RECD<<< 250 Transfer completed successfully.
The first transfer using the FTPClient took 2 minutes, which when switching to
using FTPS take less than a second. This has only been an issue since upgrading
from commons-net 3.6 to 3.7.1. It seems to consistently take 2 minutes transfer
pretty much regardless of the size of the file, so appears to be waiting on
something or hitting a timeout of some sort.
I have added the code I'm using to establish the FTPClient and connect to the
host and to retrieve the file.
{code:java}
//Establish the FTPClient and connect to the host
private FTPClient getFTPClient(String host, String userProperty, String
passwordProperty) throws SocketException, IOException {
FTPClient client = new FTPClient();
client.addProtocolCommandListener(this);
client.connect(host);
client.login(getProperties().getProperty(userProperty),
getProperties().getProperty(passwordProperty));
client.enterLocalPassiveMode();
return client;
}
//Retrieve file
private void getFile(String remoteDir,String localDir, String file,
FTPClient client) throws IOException, FileNotFoundException {
client.changeWorkingDirectory(remoteDir);
client.setFileType(FTP.BINARY_FILE_TYPE);
BufferedOutputStream bo = new BufferedOutputStream(new
FileOutputStream(localDir + file));
client.retrieveFile(file, bo);
bo.close();
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] garydgregory merged pull request #162: Bump junit-pioneer from 0.9.2 to 1.0.0
garydgregory merged pull request #162: URL: https://github.com/apache/commons-io/pull/162 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] vadimd02 commented on pull request #26: SMB v. 2 / 3 integration based on SMBJ
vadimd02 commented on pull request #26: URL: https://github.com/apache/commons-vfs/pull/26#issuecomment-705008277 @ahbonsu @markt-asf - can you please advise if this planned to be merged ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (BCEL-343) Improve JUnit assertions
[ https://issues.apache.org/jira/browse/BCEL-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209580#comment-17209580 ] Allon Mureinik commented on BCEL-343: - Verified, closing. > Improve JUnit assertions > > > Key: BCEL-343 > URL: https://issues.apache.org/jira/browse/BCEL-343 > Project: Commons BCEL > Issue Type: Task > Components: Build >Reporter: Allon Mureinik >Priority: Major > Fix For: 6.5.1 > > > Followup to BCEL-342, based on the discussion in the PR > ([https://github.com/apache/commons-bcel/pull/68#issuecomment-703671353)] - > now that the project used JUnit Jupiter, it's worth checking if the > assertions can be improved to use String suppliers instead of string methods > and improve performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-bcel] garydgregory merged pull request #66: Bump actions/checkout from v2.3.2 to v2.3.3
garydgregory merged pull request #66: URL: https://github.com/apache/commons-bcel/pull/66 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (BCEL-343) Improve JUnit assertions
[ https://issues.apache.org/jira/browse/BCEL-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik closed BCEL-343. --- > Improve JUnit assertions > > > Key: BCEL-343 > URL: https://issues.apache.org/jira/browse/BCEL-343 > Project: Commons BCEL > Issue Type: Task > Components: Build >Reporter: Allon Mureinik >Priority: Major > Fix For: 6.5.1 > > > Followup to BCEL-342, based on the discussion in the PR > ([https://github.com/apache/commons-bcel/pull/68#issuecomment-703671353)] - > now that the project used JUnit Jupiter, it's worth checking if the > assertions can be improved to use String suppliers instead of string methods > and improve performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-bcel] garydgregory merged pull request #67: Bump actions/setup-java from v1.4.2 to v1.4.3
garydgregory merged pull request #67: URL: https://github.com/apache/commons-bcel/pull/67 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (BCEL-343) Improve JUnit assertions
[ https://issues.apache.org/jira/browse/BCEL-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved BCEL-343. -- Fix Version/s: 6.5.1 Resolution: Fixed In git master; please verify git master and close this ticket. > Improve JUnit assertions > > > Key: BCEL-343 > URL: https://issues.apache.org/jira/browse/BCEL-343 > Project: Commons BCEL > Issue Type: Task > Components: Build >Reporter: Allon Mureinik >Priority: Major > Fix For: 6.5.1 > > > Followup to BCEL-342, based on the discussion in the PR > ([https://github.com/apache/commons-bcel/pull/68#issuecomment-703671353)] - > now that the project used JUnit Jupiter, it's worth checking if the > assertions can be improved to use String suppliers instead of string methods > and improve performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (BCEL-343) Improve JUnit assertions
[ https://issues.apache.org/jira/browse/BCEL-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated BCEL-343: - Summary: Improve JUnit assertions (was: Improve assertions) > Improve JUnit assertions > > > Key: BCEL-343 > URL: https://issues.apache.org/jira/browse/BCEL-343 > Project: Commons BCEL > Issue Type: Task > Components: Build >Reporter: Allon Mureinik >Priority: Major > > Followup to BCEL-342, based on the discussion in the PR > ([https://github.com/apache/commons-bcel/pull/68#issuecomment-703671353)] - > now that the project used JUnit Jupiter, it's worth checking if the > assertions can be improved to use String suppliers instead of string methods > and improve performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-bcel] garydgregory merged pull request #69: BCEL-343 JUnit Assertion improvement
garydgregory merged pull request #69: URL: https://github.com/apache/commons-bcel/pull/69 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] mureinik edited a comment on pull request #69: BCEL-343 Assertion improvement
mureinik edited a comment on pull request #69: URL: https://github.com/apache/commons-bcel/pull/69#issuecomment-704923986 @garydgregory Fixed the formatting issues and answered wrt the usage of `j` (see inline - left that comment unresolved for your decision) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on pull request #69: BCEL-343 Assertion improvement
mureinik commented on pull request #69: URL: https://github.com/apache/commons-bcel/pull/69#issuecomment-704923986 @garydgregory Fixed the formatting issues and answered wrt the usage of `j` (see inline) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on a change in pull request #69: BCEL-343 Assertion improvement
mureinik commented on a change in pull request #69:
URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500988579
##
File path: src/test/java/org/apache/bcel/classfile/JDKClassDumpTestCase.java
##
@@ -81,7 +80,8 @@ private void compare(final JavaClass jc, final InputStream
inputStream, final St
int i = 0;
for (final int out : baos.toByteArray()) {
final int in = src.read();
-assertEquals(in, out & 0xFF, name + ": Mismatch at " + i);
+int j = i;
Review comment:
Yes - values in a lambda expression must be final or effectively final,
and `i` isn't, so I assigned it to `j`, which is (since it's scoped in the
loop's body and is never modified).
Alternatively, we can leave the message as is and not replace it with a
`Supplier`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on a change in pull request #69: BCEL-343 Assertion improvement
mureinik commented on a change in pull request #69:
URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500995873
##
File path: src/test/java/org/apache/bcel/generic/FieldAnnotationsTestCase.java
##
@@ -115,9 +115,7 @@ public void testFieldAnnotationModification()
System.err.println("With AnnotationEntrys: "
+ dumpAnnotationEntries(f.getAnnotationEntries()));
}
-assertTrue(f.getAnnotationEntries().length == 2,
-"Should be 2 AnnotationEntrys on this field, but there are "
-+ f.getAnnotationEntries().length);
+assertEquals(2, f.getAnnotationEntries().length,"Wrong number of
AnnotationEntries");
Review comment:
Fixed
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on a change in pull request #69: BCEL-343 Assertion improvement
mureinik commented on a change in pull request #69:
URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500995547
##
File path: src/test/java/org/apache/bcel/EnclosingMethodAttributeTestCase.java
##
@@ -89,8 +81,7 @@ public void testAttributeSerializtion() throws
ClassNotFoundException,
final JavaClass clazz =
getTestClass(PACKAGE_BASE_NAME+".data.AttributeTestClassEM02$1");
final ConstantPool pool = clazz.getConstantPool();
final Attribute[] encMethodAttrs = findAttribute("EnclosingMethod",
clazz);
-assertTrue(encMethodAttrs.length == 1,
-"Expected 1 EnclosingMethod attribute but found " +
encMethodAttrs.length);
+assertEquals(1, encMethodAttrs.length,"Wrong number of EnclosingMethod
attributes");
Review comment:
Fixed
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on a change in pull request #69: BCEL-343 Assertion improvement
mureinik commented on a change in pull request #69: URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500995185 ## File path: src/test/java/org/apache/bcel/generic/GeneratingAnnotatedClassesTestCase.java ## @@ -352,16 +327,14 @@ public void testTransformComplexClassToClassGen() final ClassGen cgen = new ClassGen(jc); // Check annotations are correctly preserved final AnnotationEntryGen[] annotations = cgen.getAnnotationEntries(); -assertTrue(annotations.length == 1, -"Expected one annotation but found " + annotations.length); +assertEquals(1, annotations.length,"Wrong number of annotations"); Review comment: Fixed, sorry about that. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on a change in pull request #69: BCEL-343 Assertion improvement
mureinik commented on a change in pull request #69:
URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500995426
##
File path: src/test/java/org/apache/bcel/generic/FieldAnnotationsTestCase.java
##
@@ -139,38 +137,10 @@ public void checkAnnotatedField(final JavaClass clazz,
final String fieldname,
private void checkAnnotationEntry(final AnnotationEntry a, final String
name, final String elementname,
final String elementvalue)
{
-assertTrue(a.getAnnotationType().equals(name),
-"Expected AnnotationEntry to have name " + name
-+ " but it had name " + a.getAnnotationType());
-assertTrue(a.getElementValuePairs().length == 1,
-"Expected AnnotationEntry to have one element but it had "
-+ a.getElementValuePairs().length);
+assertEquals(name, a.getAnnotationType(), "Wrong AnnotationEntry
name");
+assertEquals(1, a.getElementValuePairs().length,"Wrong number of
AnnotationEntry elements");
Review comment:
Fixed
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on a change in pull request #69: BCEL-343 Assertion improvement
mureinik commented on a change in pull request #69:
URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500988579
##
File path: src/test/java/org/apache/bcel/classfile/JDKClassDumpTestCase.java
##
@@ -81,7 +80,8 @@ private void compare(final JavaClass jc, final InputStream
inputStream, final St
int i = 0;
for (final int out : baos.toByteArray()) {
final int in = src.read();
-assertEquals(in, out & 0xFF, name + ": Mismatch at " + i);
+int j = i;
Review comment:
Yes - values in a lambda expression must be final or effectively final,
and `i` isn't, so I assigned it to `j`, which is (since it's scoped in the
loop's body).
Alternatively, we can leave the message as is and not replace it with a
`Supplier`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-bcel] mureinik commented on a change in pull request #69: BCEL-343 Assertion improvement
mureinik commented on a change in pull request #69:
URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500988579
##
File path: src/test/java/org/apache/bcel/classfile/JDKClassDumpTestCase.java
##
@@ -81,7 +80,8 @@ private void compare(final JavaClass jc, final InputStream
inputStream, final St
int i = 0;
for (final int out : baos.toByteArray()) {
final int in = src.read();
-assertEquals(in, out & 0xFF, name + ": Mismatch at " + i);
+int j = i;
Review comment:
Yes - values in a lambda expression must be final or effectively final,
and `i` isn't, so I assigned it to `j`, which is (since it's scopped in the
loop's body).
Alternatively, we can leave the message as is and not replace it with a
`Supplier`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-bcel] garydgregory commented on pull request #69: BCEL-343 Assertion improvement
garydgregory commented on pull request #69: URL: https://github.com/apache/commons-bcel/pull/69#issuecomment-704908154 https://issues.apache.org/jira/browse/BCEL-343 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] garydgregory commented on a change in pull request #69: BCEL-343 Assertion improvement
garydgregory commented on a change in pull request #69:
URL: https://github.com/apache/commons-bcel/pull/69#discussion_r500974895
##
File path: src/test/java/org/apache/bcel/classfile/JDKClassDumpTestCase.java
##
@@ -81,7 +80,8 @@ private void compare(final JavaClass jc, final InputStream
inputStream, final St
int i = 0;
for (final int out : baos.toByteArray()) {
final int in = src.read();
-assertEquals(in, out & 0xFF, name + ": Mismatch at " + i);
+int j = i;
Review comment:
Do we really need `j`?
##
File path:
src/test/java/org/apache/bcel/generic/GeneratingAnnotatedClassesTestCase.java
##
@@ -352,16 +327,14 @@ public void testTransformComplexClassToClassGen()
final ClassGen cgen = new ClassGen(jc);
// Check annotations are correctly preserved
final AnnotationEntryGen[] annotations = cgen.getAnnotationEntries();
-assertTrue(annotations.length == 1,
-"Expected one annotation but found " + annotations.length);
+assertEquals(1, annotations.length,"Wrong number of annotations");
Review comment:
Oops, add space after ","
##
File path: src/test/java/org/apache/bcel/generic/FieldAnnotationsTestCase.java
##
@@ -139,38 +137,10 @@ public void checkAnnotatedField(final JavaClass clazz,
final String fieldname,
private void checkAnnotationEntry(final AnnotationEntry a, final String
name, final String elementname,
final String elementvalue)
{
-assertTrue(a.getAnnotationType().equals(name),
-"Expected AnnotationEntry to have name " + name
-+ " but it had name " + a.getAnnotationType());
-assertTrue(a.getElementValuePairs().length == 1,
-"Expected AnnotationEntry to have one element but it had "
-+ a.getElementValuePairs().length);
+assertEquals(name, a.getAnnotationType(), "Wrong AnnotationEntry
name");
+assertEquals(1, a.getElementValuePairs().length,"Wrong number of
AnnotationEntry elements");
Review comment:
Format.
##
File path: src/test/java/org/apache/bcel/generic/FieldAnnotationsTestCase.java
##
@@ -115,9 +115,7 @@ public void testFieldAnnotationModification()
System.err.println("With AnnotationEntrys: "
+ dumpAnnotationEntries(f.getAnnotationEntries()));
}
-assertTrue(f.getAnnotationEntries().length == 2,
-"Should be 2 AnnotationEntrys on this field, but there are "
-+ f.getAnnotationEntries().length);
+assertEquals(2, f.getAnnotationEntries().length,"Wrong number of
AnnotationEntries");
Review comment:
Format.
##
File path: src/test/java/org/apache/bcel/EnclosingMethodAttributeTestCase.java
##
@@ -89,8 +81,7 @@ public void testAttributeSerializtion() throws
ClassNotFoundException,
final JavaClass clazz =
getTestClass(PACKAGE_BASE_NAME+".data.AttributeTestClassEM02$1");
final ConstantPool pool = clazz.getConstantPool();
final Attribute[] encMethodAttrs = findAttribute("EnclosingMethod",
clazz);
-assertTrue(encMethodAttrs.length == 1,
-"Expected 1 EnclosingMethod attribute but found " +
encMethodAttrs.length);
+assertEquals(1, encMethodAttrs.length,"Wrong number of EnclosingMethod
attributes");
Review comment:
Format (comma)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (BCEL-343) Improve assertions
[ https://issues.apache.org/jira/browse/BCEL-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209463#comment-17209463 ] Allon Mureinik commented on BCEL-343: - PR posted here: [https://github.com/apache/commons-bcel/pull/69] > Improve assertions > -- > > Key: BCEL-343 > URL: https://issues.apache.org/jira/browse/BCEL-343 > Project: Commons BCEL > Issue Type: Task > Components: Build >Reporter: Allon Mureinik >Priority: Major > > Followup to BCEL-342, based on the discussion in the PR > ([https://github.com/apache/commons-bcel/pull/68#issuecomment-703671353)] - > now that the project used JUnit Jupiter, it's worth checking if the > assertions can be improved to use String suppliers instead of string methods > and improve performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-bcel] mureinik opened a new pull request #69: BCEL-343 Assertion improvement
mureinik opened a new pull request #69: URL: https://github.com/apache/commons-bcel/pull/69 As a followup to #68 (BCEL-342), now that the tests are migrated to JUnit Jupiter, it's a good opportunity to go over the assertions and clean them up. The main gain from this PR is improving the readability and maintainability of the tests. There is a theoretical performance improvement here too, but my benchmarking it on my limited resources, I could not observe a meaningful difference. This PR offers the following improvements: 1. Remvoes unused methods from test classes 1. Removes unnescesary casts from test classes 1. Simplifies the idiom of `assertTrue(!condition, message)` to `assertTrue(condtion, message)` in order to make the tests easier to understand 1. Simplifies the idiom of `assertTrue(x.equals(y), message)` to `assertEquals(x, y, message)` in order to make the tests easier to understand. As a side bonus, most of these messages were constructed dynamically with the values of `x` and `y`, and using `assertEquals` allowed relying on JUnit's existing functionality to display them in case of failure instead of reinventing the wheel. This not only shortens the code by removing boilerplate logical, but also theoritically improves performance as this string needs to be constructed only in case of a test failure. 1. Simplifies the idiom of `assertTrue(primitiveX == primitiveY, message)` to `assertEquals(x, y, message)`, for similar benefits as the previous point. 1. Simplifies the idiom of `if(!x.equals(y)) fail(message)` to `assertEquals(x, y, message)`, for similar benefits as the previous point. 1. Simplifies the idiom of catching an exception and explicitly failing to allowing the test methods to throw those exceptions and have the test runner handle it. 1. In the remaining cases where an assertion had a non-constant string message it was replaced with a `Supplier` that supplies the same message so that it's only evaluated in case of an assertion failure. 1. Some minor typos in assertion messages were fixed where noticed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MATH-1555) Wrong declaration of ATan2 class
Laurent Galluccio created MATH-1555:
---
Summary: Wrong declaration of ATan2 class
Key: MATH-1555
URL: https://issues.apache.org/jira/browse/MATH-1555
Project: Commons Math
Issue Type: Bug
Reporter: Laurent Galluccio
If i check the content of ATan2 class, the value method is coded like this
public double value(double x, double y) {
return FastMath.atan2(x, y);
}
with
*x* Abscissa for which the function value should be computed.
*y* Ordinate for which the function value should be computed.
But the FastMath.atan2 method is declared like this
/**
* Two arguments arctangent function
* @param y ordinate
* @param x abscissa
* @return phase angle of point (x,y) between \{@code -PI} and \{@code PI}
*/
public static double atan2(double y, double x)
Which means that ordinate and abscissa are inverted. This should be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] coveralls commented on pull request #162: Bump junit-pioneer from 0.9.2 to 1.0.0
coveralls commented on pull request #162: URL: https://github.com/apache/commons-io/pull/162#issuecomment-704717567 [](https://coveralls.io/builds/33986333) Coverage decreased (-0.06%) to 89.471% when pulling **99bd982d211ef1fb65678bb284f9a94efc024b34 on dependabot/maven/org.junit-pioneer-junit-pioneer-1.0.0** into **3a24a8ec1b146d9c7f382f95810c9015cd002c94 on master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
