[jira] [Created] (MATH-1548) Inefficient computation of SOM quality standard indicators
Gilles Sadowski created MATH-1548:
-
Summary: Inefficient computation of SOM quality standard indicators
Key: MATH-1548
URL: https://issues.apache.org/jira/browse/MATH-1548
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.6.1
Reporter: Gilles Sadowski
Assignee: Gilles Sadowski
Fix For: 4.0
Package {{o.a.c.m.ml.neuralnet.twod.util}} contain classes for defining various
measures of the quality of a self-organizing feature map (SOM).
The current design can be quite inefficient when the number of data and/or the
number of neurons are large, since the same procedures (e.g. finding the neuron
whose features most closely matches some data) are repeated for each quality
indicator.
It is proposed to compute all "standard" indicators at once (in class
{{NeuronSquareMesh2D}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MATH-1547) Flexible ranking of neural net units
Gilles Sadowski created MATH-1547:
-
Summary: Flexible ranking of neural net units
Key: MATH-1547
URL: https://issues.apache.org/jira/browse/MATH-1547
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.6.1
Reporter: Gilles Sadowski
Assignee: Gilles Sadowski
Fix For: 4.0
Class {{MapUtils}} (in package {{o.a.c.m.ml.neuralnet}}) contains methods
{{findBest}} and {{findBestAndSecondBest}}.
It is proposed to create a new {{MapRanking}} class, to provide a method for
ranking all (or a user-defined number of the best) neurons.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #81: Prevent exception in TIFF when reading EXIF directory
kinow commented on pull request #81: URL: https://github.com/apache/commons-imaging/pull/81#issuecomment-649874452 Looks good! >Unfortunately, I do not have a test file to contribute at this time. The one I've used for testing is the public-domain "Natural Earth Data" medium-size Cross-blended Hypsometric Tints file at https://www.naturalearthdata.com/downloads/10m-raster-data/10m-cross-blend-hypso/ Unfortunately, this file is just too large to bundle with the commons-imaging software distribution. Couldn't we resize/trim the data of this file? >I will see if I can produce a test file sometime in the next few days. >Also, an item off topic... I was wondering when you thought you might be posting the Alpha 2 release of the library to maven central. I have been working on a wiki article that describes the new features and would like to coordinate posting it. Was planning on doing that a few weeks ago when I had a whole week off, but ended up doing other chores that had piled up during our lock down in New Zealand. In theory we can do that any time now, I just need a few hours in a weekend to sync repositories, and follow the release process to start the vote in the ASF mailing list. Would you like to finish this PR so that it's included in alpha2 too? Otherwise we can aim at this weekend, or the next one? Thanks @gwlucastrig ! 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] coveralls commented on pull request #81: Prevent exception in TIFF when reading EXIF directory
coveralls commented on pull request #81: URL: https://github.com/apache/commons-imaging/pull/81#issuecomment-649829931 [](https://coveralls.io/builds/31695551) Coverage increased (+0.007%) to 76.311% when pulling **f06437a5e51d1ab0265870a4011bde997262225d on gwlucastrig:imaging-258** into **db764328b665ea7f7d0d9bcb966d8e4305e0132c 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
[GitHub] [commons-imaging] gwlucastrig opened a new pull request #81: Prevent exception in TIFF when reading EXIF directory
gwlucastrig opened a new pull request #81: URL: https://github.com/apache/commons-imaging/pull/81 This change addresses JIRA Issue 258 in which files containing EXIF sub-directories caused the TiffReader to throw an ImageReadException. The library now reads the directory successfully. Unfortunately, I do not have a test file to contribute at this time. The one I've used for testing is the public-domain "Natural Earth Data" medium-size Cross-blended Hypsometric Tints file at https://www.naturalearthdata.com/downloads/10m-raster-data/10m-cross-blend-hypso/ Unfortunately, this file is just too large to bundle with the commons-imaging software distribution. I will see if I can produce a test file sometime in the next few days. Also, an item off topic... I was wondering when you thought you might be posting the Alpha 2 release of the library to maven central. I have been working on a wiki article that describes the new features and would like to coordinate posting it. 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] (GEOMETRY-50) Overflow in Vector norm and distance
[
https://issues.apache.org/jira/browse/GEOMETRY-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145827#comment-17145827
]
Alex Herbert commented on GEOMETRY-50:
--
SafeNorm will not return the same value as Math.hypot. When there is no
overflow or underflow potential then SafeNorm reduces to a
sqrt(sum_of_squares). Math.hypot scales the input values, lossless, to avoid
over/underflow and computes the sum_of_squares using extended precision with a
quad length (128 bit) number for intermediate parts before reducing to a double
(64 bit) number to pass to the sqrt. The result is rescaled, again lossless.
This means it will have a lower average error and a lower max error to the true
value than a simple sum_of_squares. Note that not in every case is it more
accurate.
When SafeNorm has to scale numbers for under/overflow it is not lossless (scale
by an exponent change only). The rescale at the end is also not lossless. The
method's strength is that it can compute for any length vector. But the cost is
the potential for a relatively large error from the true result.
I would use Math.hypot over SafeNorm for 2D. I'd suggest benchmarking the 3D
variant suggested above against SafeNorm. It should have a lower error than
using SafeNorm but I do not know about the speed.
My conclusion in [Numbers-143] was that Math.hypot was slow, even from Java 9
onwards when it was rewritten to avoid a JNI call and run purely in Java. The
JDK are tied to using the computation from the fdlibm implementation for the
high precision sum of squares so that the method produces the same values as it
always has done. I changed this to a different computation for a noticeable
performance improvement and no loss of accuracy.
Currently the method is private in {{o.a.c.numbers.complex.Complex}}. That
package thus has the license from fdlibm in the NOTICE due to adaption of the
original source.
What do you think to the idea of promoting the method to a public API in
Numbers given it is of wider scope than just complex numbers? As a first step
it may be of some interest to borrow the code for a quick benchmark against
SafeNorm for 2D.
I'm going to ponder about how it could be adapted to 3D by accepting 3 args,
e.g. {{hypot(x, y, z)}}.
> Overflow in Vector norm and distance
>
>
> Key: GEOMETRY-50
> URL: https://issues.apache.org/jira/browse/GEOMETRY-50
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Major
> Labels: beta1
>
> In Euclidean Vector classes (Vector2D, Vector3D), norm() and distance() rely
> on Math.sqrt(), which can overflow if the components of the vectors are
> large. Instead, they should rely on SafeNorm.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-50) Overflow in Vector norm and distance
[
https://issues.apache.org/jira/browse/GEOMETRY-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145044#comment-17145044
]
Baljit Singh commented on GEOMETRY-50:
--
No objection. Thoughts on using {{Math.hypot}} for 3D: {{mag = Math.hypot(x,
Math.hypot(y, z))}}
Performance will not be so great on Java 8.
> Overflow in Vector norm and distance
>
>
> Key: GEOMETRY-50
> URL: https://issues.apache.org/jira/browse/GEOMETRY-50
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Major
> Labels: beta1
>
> In Euclidean Vector classes (Vector2D, Vector3D), norm() and distance() rely
> on Math.sqrt(), which can overflow if the components of the vectors are
> large. Instead, they should rely on SafeNorm.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-50) Overflow in Vector norm and distance
[
https://issues.apache.org/jira/browse/GEOMETRY-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145040#comment-17145040
]
Matt Juntunen commented on GEOMETRY-50:
---
If no one has any other ideas here, I propose to keep using {{Math.hypot}} for
the 2D norm computation since it seems slightly more accurate and use
{{SafeNorm}} for the 3D version. Any objections?
> Overflow in Vector norm and distance
>
>
> Key: GEOMETRY-50
> URL: https://issues.apache.org/jira/browse/GEOMETRY-50
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Major
> Labels: beta1
>
> In Euclidean Vector classes (Vector2D, Vector3D), norm() and distance() rely
> on Math.sqrt(), which can overflow if the components of the vectors are
> large. Instead, they should rely on SafeNorm.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[
https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145035#comment-17145035
]
Matt Juntunen commented on GEOMETRY-95:
---
I added another batch of updates related to 3D models and CSG:
https://github.com/apache/commons-geometry/pull/80.
The changes include:
- Expanded IO functionality in examples-io.
- Addition of {{Mesh}} interfaces and one {{SimpleTriangleMesh}} implementation
class. I initially had this in the examples-io module for use with OBJ files
but it proved to be very useful so I moved it to commons-geometry-euclidean.
- Addition of {{PartitionedRegionBuilder[23]D}} classes to aid in construction
of BSP trees with models containing large numbers of facets.
- Addition of {{Planes.extrude()}} methods based on the use case from Sven
Rathgeber mentioned in the dev mailing list.
Feedback is welcome.
> CSG Examples
>
>
> Key: GEOMETRY-95
> URL: https://issues.apache.org/jira/browse/GEOMETRY-95
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: beta1
>
> Adding Constructive Solid Geometry examples and userguide entries to help new
> users to the library use these features.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-63) Review "SonarQube" report
[ https://issues.apache.org/jira/browse/GEOMETRY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145015#comment-17145015 ] Matt Juntunen commented on GEOMETRY-63: --- Github PR 79 (https://github.com/apache/commons-geometry/pull/79) merged in commit 015f466c1f25a5bcd993bb436692b7922ef23a61. > Review "SonarQube" report > - > > Key: GEOMETRY-63 > URL: https://issues.apache.org/jira/browse/GEOMETRY-63 > Project: Apache Commons Geometry > Issue Type: Task >Reporter: Gilles Sadowski >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > https://sonarcloud.io/dashboard?id=commons-geometry -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] asfgit merged pull request #79: GEOMETRY-63: Fix some SonarQube smells
asfgit merged pull request #79: URL: https://github.com/apache/commons-geometry/pull/79 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-geometry] singhbaljit commented on pull request #79: GEOMETRY-63: Fix some SonarQube smells
singhbaljit commented on pull request #79: URL: https://github.com/apache/commons-geometry/pull/79#issuecomment-649551543 There is also https://jqno.nl/equalsverifier 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-geometry] singhbaljit commented on a change in pull request #79: GEOMETRY-63: Fix some SonarQube smells
singhbaljit commented on a change in pull request #79:
URL: https://github.com/apache/commons-geometry/pull/79#discussion_r445525532
##
File path:
commons-geometry-core/src/test/java/org/apache/commons/geometry/core/precision/EpsilonDoublePrecisionContextTest.java
##
@@ -199,13 +199,13 @@ public void testEquals() {
EpsilonDoublePrecisionContext c = new
EpsilonDoublePrecisionContext(1e-6);
// act/assert
-Assert.assertFalse(a.equals(null));
-Assert.assertFalse(a.equals(new Object()));
-Assert.assertFalse(a.equals(b));
-Assert.assertFalse(b.equals(a));
+Assert.assertNotEquals(null, a);
+Assert.assertNotEquals(new Object(), a);
Review comment:
Undid the tests for null checks.
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-geometry] darkma773r commented on a change in pull request #79: GEOMETRY-63: Fix some SonarQube smells
darkma773r commented on a change in pull request #79:
URL: https://github.com/apache/commons-geometry/pull/79#discussion_r445520548
##
File path:
commons-geometry-core/src/test/java/org/apache/commons/geometry/core/precision/EpsilonDoublePrecisionContextTest.java
##
@@ -199,13 +199,13 @@ public void testEquals() {
EpsilonDoublePrecisionContext c = new
EpsilonDoublePrecisionContext(1e-6);
// act/assert
-Assert.assertFalse(a.equals(null));
-Assert.assertFalse(a.equals(new Object()));
-Assert.assertFalse(a.equals(b));
-Assert.assertFalse(b.equals(a));
+Assert.assertNotEquals(null, a);
+Assert.assertNotEquals(new Object(), a);
Review comment:
JUnit applies its own null checks in the `assertEquals` and
`assertNotEquals` methods, meaning that we end up missing those branches in our
code. This seems to be why the code coverage decreased. Let's revert these
changes on this and all of the other `equals()` method tests and see if the
code coverage goes back up.
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-geometry] darkma773r commented on pull request #79: GEOMETRY-63: Fix some SonarQube smells
darkma773r commented on pull request #79: URL: https://github.com/apache/commons-geometry/pull/79#issuecomment-649505999 Apologies, Baljit! I didn't realize that you had a pull request open. I'll take a look now. 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-geometry] darkma773r opened a new pull request #80: GEOMETRY-95: 3D IO and related classes
darkma773r opened a new pull request #80: URL: https://github.com/apache/commons-geometry/pull/80 Batch of changes to better support working with 3D models: - adding 3D mesh classes - adding PartitionedRegionBuilder[23]D to build performant BSP trees from models with large numbers of facets - adding Planes.extrude() methods - expanding functionality in examples-io module 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] [Comment Edited] (NET-684) Most images aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144763#comment-17144763 ] JRRR edited comment on NET-684 at 6/25/20, 8:59 AM: I uploaded the code. There's only a single public FTP server I can test it with ([DLP Test|https://dlptest.com/ftp-test/]) as the others I've found either instantly delete uploaded files again or simply block file upload but even this one deletes uploaded files after 30 minutes. That's why I can't run any long tests but so far the downloaded files have all been okay. Most of the testing I've done with two different FTP servers in the same network: A Windows 10 one (images are affected more often) and a Linux one (images are still affected but less often) and the problem occurs with both. Uploading/downloading the files to/from them with an app like Filezilla works fine. was (Author: jrrr): I uploaded the code. There's only a single public FTP server I can test it with ([DLP Test|https://dlptest.com/ftp-test/]) as the others I've found either instantly delete uploaded files again or simply block file upload but even this one deletes uploaded files after 30 minutes. That's why I can't run any long tests but so far the downloaded files have all been okay. Most of the testing I've done with two different FTP servers in the same network: A Windows 10 one (images are affected more often) and a Linux one (images are still affected but less often) and the problem occurs with both. Uploading/downloading the files to/from them with an app like Filezilla works fine. > Most images aren't downloaded completely from an FTP server > --- > > Key: NET-684 > URL: https://issues.apache.org/jira/browse/NET-684 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Win 10, Java 8, Android Studio 3.6.1, target Android > SDK=27 >Reporter: JRRR >Priority: Major > Attachments: DownloadProblem.java > > > Downloading images from an FTP server succeeds but the resulting images are > incomplete (black/transparent parts at the bottom) or faulty (wrong > colors/visual artifacts) most of the time. > > You can find examples and full code in > [this|http://mail-archives.apache.org/mod_mbox/commons-user/202005.mbox/%3C000b01d6341c%246a66f7f0%243f34e7d0%24%40simutech.at%3E] > mailing list thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (NET-684) Most images aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144763#comment-17144763 ] JRRR edited comment on NET-684 at 6/25/20, 8:59 AM: I uploaded the code. There's only a single public FTP server I can test it with ([DLP Test|https://dlptest.com/ftp-test/]) as the others I've found either instantly delete uploaded files again or simply block file upload but even this one deletes uploaded files after 30 minutes. That's why I can't run any long tests but so far the downloaded files have all been okay. Most of the testing I've done with two different FTP servers in the same network: A Windows 10 one (images are affected more often) and a Linux one (images are still affected but less often) and the problem occurs with both. Uploading/downloading the files to/from them with an app like Filezilla works fine. was (Author: jrrr): I uploaded the code. There's only a single public FTP server I can test it with [DLP Test|https://dlptest.com/ftp-test/] as the others I've found either instantly delete uploaded files again or simply block file upload but even this one deletes uploaded files after 30 minutes. That's why I can't run any long tests but so far the downloaded files have all been okay. Most of the testing I've done with two different FTP servers in the same network: A Windows 10 one (images are affected more often) and a Linux one (images are still affected but less often) and the problem occurs with both. Uploading/downloading the files to/from them with an app like Filezilla works fine. > Most images aren't downloaded completely from an FTP server > --- > > Key: NET-684 > URL: https://issues.apache.org/jira/browse/NET-684 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Win 10, Java 8, Android Studio 3.6.1, target Android > SDK=27 >Reporter: JRRR >Priority: Major > Attachments: DownloadProblem.java > > > Downloading images from an FTP server succeeds but the resulting images are > incomplete (black/transparent parts at the bottom) or faulty (wrong > colors/visual artifacts) most of the time. > > You can find examples and full code in > [this|http://mail-archives.apache.org/mod_mbox/commons-user/202005.mbox/%3C000b01d6341c%246a66f7f0%243f34e7d0%24%40simutech.at%3E] > mailing list thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (NET-684) Most images aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144763#comment-17144763 ] Julia Ruzicka edited comment on NET-684 at 6/25/20, 8:55 AM: - I uploaded the code. There's only a single public FTP server I can test it with [DLP Test|https://dlptest.com/ftp-test/] as the others I've found either instantly delete uploaded files again or simply block file upload but even this one deletes uploaded files after 30 minutes. That's why I can't run any long tests but so far the downloaded files have all been okay. Most of the testing I've done with two different FTP servers in the same network: A Windows 10 one (images are affected more often) and a Linux one (images are still affected but less often) and the problem occurs with both. Uploading/downloading the files to/from them with an app like Filezilla works fine. was (Author: jrrr): I uploaded the code. There's only a single public FTP server I can test it with ([DLP Test|[https://dlptest.com/ftp-test/])] as the others I've found either instantly delete uploaded files again or simply block file upload but even this one deletes uploaded files after 30 minutes. That's why I can't run any long tests but so far the downloaded files have all been okay. Most of the testing I've done with two different FTP servers in the same network: A Windows 10 one (images are affected more often) and a Linux one (images are still affected but less often) and the problem occurs with both. Uploading/downloading the files to/from them with an app like Filezilla works fine. > Most images aren't downloaded completely from an FTP server > --- > > Key: NET-684 > URL: https://issues.apache.org/jira/browse/NET-684 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Win 10, Java 8, Android Studio 3.6.1, target Android > SDK=27 >Reporter: Julia Ruzicka >Priority: Major > Attachments: DownloadProblem.java > > > Downloading images from an FTP server succeeds but the resulting images are > incomplete (black/transparent parts at the bottom) or faulty (wrong > colors/visual artifacts) most of the time. > > You can find examples and full code in > [this|http://mail-archives.apache.org/mod_mbox/commons-user/202005.mbox/%3C000b01d6341c%246a66f7f0%243f34e7d0%24%40simutech.at%3E] > mailing list thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NET-684) Most images aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144763#comment-17144763 ] Julia Ruzicka commented on NET-684: --- I uploaded the code. There's only a single public FTP server I can test it with ([DLP Test|[https://dlptest.com/ftp-test/])] as the others I've found either instantly delete uploaded files again or simply block file upload but even this one deletes uploaded files after 30 minutes. That's why I can't run any long tests but so far the downloaded files have all been okay. Most of the testing I've done with two different FTP servers in the same network: A Windows 10 one (images are affected more often) and a Linux one (images are still affected but less often) and the problem occurs with both. Uploading/downloading the files to/from them with an app like Filezilla works fine. > Most images aren't downloaded completely from an FTP server > --- > > Key: NET-684 > URL: https://issues.apache.org/jira/browse/NET-684 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Win 10, Java 8, Android Studio 3.6.1, target Android > SDK=27 >Reporter: Julia Ruzicka >Priority: Major > Attachments: DownloadProblem.java > > > Downloading images from an FTP server succeeds but the resulting images are > incomplete (black/transparent parts at the bottom) or faulty (wrong > colors/visual artifacts) most of the time. > > You can find examples and full code in > [this|http://mail-archives.apache.org/mod_mbox/commons-user/202005.mbox/%3C000b01d6341c%246a66f7f0%243f34e7d0%24%40simutech.at%3E] > mailing list thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NET-684) Most images aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Ruzicka updated NET-684: -- Attachment: DownloadProblem.java > Most images aren't downloaded completely from an FTP server > --- > > Key: NET-684 > URL: https://issues.apache.org/jira/browse/NET-684 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Win 10, Java 8, Android Studio 3.6.1, target Android > SDK=27 >Reporter: Julia Ruzicka >Priority: Major > Attachments: DownloadProblem.java > > > Downloading images from an FTP server succeeds but the resulting images are > incomplete (black/transparent parts at the bottom) or faulty (wrong > colors/visual artifacts) most of the time. > > You can find examples and full code in > [this|http://mail-archives.apache.org/mod_mbox/commons-user/202005.mbox/%3C000b01d6341c%246a66f7f0%243f34e7d0%24%40simutech.at%3E] > mailing list thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
