[jira] [Commented] (SANSELAN-66) Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
[
https://issues.apache.org/jira/browse/SANSELAN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232424#comment-13232424
]
Piyush Kapoor commented on SANSELAN-66:
---
Thanks for committing my patch
> Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
> ---
>
> Key: SANSELAN-66
> URL: https://issues.apache.org/jira/browse/SANSELAN-66
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: TIFF
> Environment: Windows 7 64 bit
>Reporter: Piyush Kapoor
> Labels: patch
> Fix For: 1.0
>
> Attachments: BinaryFileParser.java.patch, tiffimage.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> We have a very large Tiff image tha uses 16 bits for each pixel (bits per
> sample total = 48) . The class
> org.apache.commons.sanselan.common.Bitinputstream didn't have support for
> Endianness of the Tiff format . I added that support in the patch and image
> worked absolutely fine.
> The image is very large . If you want i can upload it (140 mb).Otherwise here
> is the patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANSELAN-69) Incorrect reading Physical Width/Height Inch from PNG files
[
https://issues.apache.org/jira/browse/SANSELAN-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
VVD updated SANSELAN-69:
Description:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
was:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
PhysicalWidthInch = (float) ((double) Width
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
PhysicalHeightInch = (float) ((double) Height
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
> Incorrect reading Physical Width/Height Inch from PNG files
> ---
>
> Key: SANSELAN-69
> URL: https://issues.apache.org/jira/browse/SANSELAN-69
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: PNG
>Affects Versions: 0.97, 1.0, 1.1, 1.x
>Reporter: VVD
> Labels: patch
>
> Width: 3509
> Physical Width Dpi: 300
> Physical Width Inch: 1052697.9
> Height: 2481
> Physical Height Dpi: 300
> Physical Height Inch: 744298.5
> {code}
> PngImageParser.java (620):
> PhysicalWidthInch = (float) ((double) Width
> -* (double) pngChunkpHYs.PixelsPerUnitXAxis *
> meters_per_inch);
> +/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
> meters_per_inch));
> PngImageParser.java (625):
> PhysicalHeightInch = (float) ((double) Height
> -* (double) pngChunkpHYs.PixelsPerUnitYAxis *
> meters_per_inch);
> +/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
> meters_per_inch));
> {code}
> After this patch I got correct values:
> Width: 3509
> Physical Width Dpi: 300
> Physical Width Inch: 11.69667
> Height: 2481
> Physical Height Dpi: 300
> Physical Height Inch: 8.2700024
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANSELAN-69) Incorrect reading Physical Width/Height Inch from PNG files
Incorrect reading Physical Width/Height Inch from PNG files
---
Key: SANSELAN-69
URL: https://issues.apache.org/jira/browse/SANSELAN-69
Project: Commons Sanselan
Issue Type: Bug
Components: Format: PNG
Affects Versions: 0.97, 1.0, 1.1, 1.x
Reporter: VVD
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
PhysicalWidthInch = (float) ((double) Width
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
PhysicalHeightInch = (float) ((double) Height
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CONFIGURATION-472) SubnodeConfigurations returned by XMLConfiguration should convert added nodes to XML nodes.
[ https://issues.apache.org/jira/browse/CONFIGURATION-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raimund Klein closed CONFIGURATION-472. --- Resolution: Cannot Reproduce Hello Oliver, Sorry for the late response. I haven't had any time to look into this again, maybe it was a misuse on my side after all. Since I haven't been working on the project I encountered the behavior in for months, this issue might as well be closed. > SubnodeConfigurations returned by XMLConfiguration should convert added nodes > to XML nodes. > --- > > Key: CONFIGURATION-472 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-472 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Raimund Klein >Priority: Minor > > Problem description: XMLConfiguration's configuration(s)At return regular > SubnodeConfigurations which can't "really" be used for adding nodes as these > won't be converted into XMLConfiguration's internal XMLNodes. More precisely, > when using the SubnodeConfiguration for adding, accesses to the main > XMLConfiguration can run into ClassCastExceptions later on. > Workaround: Add the created nodes directly to the main XMLConfiguration (e.g. > with the appropriate XPath), as this configuration's add methods convert > these into the internal form. > Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a > subclass of SubnodeConfiguration whose add methods will perform the same node > conversion. Consequently, this new class' SubnodeConfigurations returned by > configuration(s)At should be instances of the very same class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-295) FileUtils.isSymlinks misses symlink folders
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcos Vinícius da Silva updated IO-295: Attachment: IO-295-1.patch A new patch. Moved the shell execution code to a new package protected class ExecUtils. > FileUtils.isSymlinks misses symlink folders > --- > > Key: IO-295 > URL: https://issues.apache.org/jira/browse/IO-295 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows 7 64 bit, Oracle Java 7 >Reporter: Ron Gross > Attachments: IO-295-1.patch, IO-295.patch > > > I created a symlink folder via mklink. > Then, while debugging, I noticed that FileUtils.isSymlink() returns false on > this directory, while Java 7's Files.isSymbolicLink() returns true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-130) Base64InputStream.skip skips underlying stream, not output
[
https://issues.apache.org/jira/browse/CODEC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232340#comment-13232340
]
Gary D. Gregory commented on CODEC-130:
---
Ok, I see. If the BaseNCodecInputStream class is going to be changed, you need:
- A test for Base64CodecInputStream (which you provided)
- A test for Base32CodecInputStream (missing)
- 100% code (I hope) coverage of the new skip method in BaseNCodecInputStream
> Base64InputStream.skip skips underlying stream, not output
> --
>
> Key: CODEC-130
> URL: https://issues.apache.org/jira/browse/CODEC-130
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: James Pickering
>Priority: Minor
> Attachments: base64snippet.java
>
>
> Base64InputStream.skip() skips within underlying stream, leading to
> unexpected behaviour.
> The following code will reproduce the issue:
> @Test
> public void testSkip() throws Throwable {
> InputStream ins =
> new
> ByteArrayInputStream("".getBytes("ISO-8859-1"));//should decode to
> {0, 0, 0, 255, 255, 255}
> Base64InputStream instance = new Base64InputStream(ins);
> assertEquals(3L, instance.skip(3L)); //should skip 3 decoded characters,
> or 4 encoded characters
> assertEquals(255, instance.read()); //Currently returns 3, as it is
> decoding "A/", not "//"
> }
> The following code, if added to Base64InputStream, or (BaseNCodecInputStream
> in the dev build) would resolve the issue:
> @Override
> public long skip(long n) throws IOException {
> //delegate to read()
> long bytesRead = 0;
> while ((bytesRead < n) && (read() != -1)) {
> bytesRead++;
> }
> return bytesRead;
> }
> More efficient code may be possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-132) BeiderMorseEncoder OOM issues
[
https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232327#comment-13232327
]
Thomas Neidhart commented on CODEC-132:
---
I have tested it with junit-benchmarks and my results are as follows:
With HashSet:
{noformat}
BeiderMorseEncoderTest.testAllChars: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 2.85 [+- 0.01], round.gc: 0.00 [+- 0.00], GC.calls: 1213, GC.time:
0.29, time.total: 43.66, time.warmup: 15.20, time.bench: 28.45
BeiderMorseEncoderTest.testAsciiEncodeNotEmpty1Letter: [measured 10 out of 15
rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 1, GC.time: 0.00,
time.total: 0.06, time.warmup: 0.02, time.bench: 0.04
BeiderMorseEncoderTest.testAsciiEncodeNotEmpty2Letters: [measured 10 out of 15
rounds, threads: 1 (sequential)]
round: 0.18 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 72, GC.time: 0.02,
time.total: 2.79, time.warmup: 0.98, time.bench: 1.82
BeiderMorseEncoderTest.testEncodeAtzNotEmpty: [measured 10 out of 15 rounds,
threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.02, time.warmup: 0.01, time.bench: 0.01
BeiderMorseEncoderTest.testEncodeGna: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testInvalidLangIllegalArgumentException: [measured 10
out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testInvalidLangIllegalStateException: [measured 10 out
of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testInvalidLanguageIllegalArgumentException: [measured
10 out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testLongestEnglishSurname: [measured 10 out of 15
rounds, threads: 1 (sequential)]
round: 0.01 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 1, GC.time: 0.00,
time.total: 0.10, time.warmup: 0.04, time.bench: 0.07
BeiderMorseEncoderTest.testNegativeIndexForRuleMatchIndexOutOfBoundsException:
[measured 10 out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testOOM: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 0.01 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 2, GC.time: 0.00,
time.total: 0.12, time.warmup: 0.04, time.bench: 0.08
BeiderMorseEncoderTest.testSetConcat: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSetNameTypeAsh: [measured 10 out of 15 rounds,
threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSetRuleTypeExact: [measured 10 out of 15 rounds,
threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSetRuleTypeToRulesIllegalArgumentException:
[measured 10 out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSpeedCheck: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.41 [+- 0.01], round.gc: 0.00 [+- 0.00], GC.calls: 91, GC.time: 0.04,
time.total: 6.13, time.warmup: 2.04, time.bench: 4.09
BeiderMorseEncoderTest.testSpeedCheck2: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.28 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 48, GC.time: 0.01,
time.total: 4.14, time.warmup: 1.38, time.bench: 2.76
BeiderMorseEncoderTest.testSpeedCheck3: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.54 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 140, GC.time: 0.05,
time.total: 8.09, time.warmup: 2.69, time.bench: 5.39
BeiderMorseEncoderTest.testEncodeEmpty: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testEncodeNull: [measured 10 out of 15 rounds, threads:
1 (s
[jira] [Commented] (CODEC-132) BeiderMorseEncoder OOM issues
[ https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232323#comment-13232323 ] Gary D. Gregory commented on CODEC-132: --- What is the performance impact of this change? > BeiderMorseEncoder OOM issues > - > > Key: CODEC-132 > URL: https://issues.apache.org/jira/browse/CODEC-132 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Robert Muir > Fix For: 1.7 > > Attachments: CODEC-132.patch, CODEC-132_test.patch > > > In Lucene/Solr, we integrated this encoder into the latest release. > Our tests use a variety of random strings, and we have recent jenkins failures > from some input streams (of length <= 10), using huge amounts of memory (e.g. > > 64MB), > resulting in OOM. > I've created a test case (length is 30 here) that will OOM with -Xmx256M. > I haven't dug into this much as to what's causing it, but I suspect there > might be a bug > revolving around certain punctuation characters: we didn't see this happening > until > we beefed up our random string generation to start producing "html-like" > strings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-132) BeiderMorseEncoder OOM issues
[ https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232322#comment-13232322 ] Thomas Neidhart commented on CODEC-132: --- Applied a minor change due to the referred test in lucene: use a LinkedHashSet instead of a HashSet to make ordering of phonemes deterministic > BeiderMorseEncoder OOM issues > - > > Key: CODEC-132 > URL: https://issues.apache.org/jira/browse/CODEC-132 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Robert Muir > Fix For: 1.7 > > Attachments: CODEC-132.patch, CODEC-132_test.patch > > > In Lucene/Solr, we integrated this encoder into the latest release. > Our tests use a variety of random strings, and we have recent jenkins failures > from some input streams (of length <= 10), using huge amounts of memory (e.g. > > 64MB), > resulting in OOM. > I've created a test case (length is 30 here) that will OOM with -Xmx256M. > I haven't dug into this much as to what's causing it, but I suspect there > might be a bug > revolving around certain punctuation characters: we didn't see this happening > until > we beefed up our random string generation to start producing "html-like" > strings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-295) FileUtils.isSymlinks misses symlink folders
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232280#comment-13232280 ] Sebb commented on IO-295: - It's far from ideal using a command shell for this, but if it is the only way it might be worth it. The class FileSystemUtils currently uses the same approach for getting the system free space, so if it is necessary to use a shell, we can re-use the process code from that class. > FileUtils.isSymlinks misses symlink folders > --- > > Key: IO-295 > URL: https://issues.apache.org/jira/browse/IO-295 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows 7 64 bit, Oracle Java 7 >Reporter: Ron Gross > Attachments: IO-295.patch > > > I created a symlink folder via mklink. > Then, while debugging, I noticed that FileUtils.isSymlink() returns false on > this directory, while Java 7's Files.isSymbolicLink() returns true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANSELAN-68) Incorrect reading Physical Width/Height Dpi and Physical Width/Height from TIFF files
Incorrect reading Physical Width/Height Dpi and Physical Width/Height from TIFF
files
-
Key: SANSELAN-68
URL: https://issues.apache.org/jira/browse/SANSELAN-68
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Affects Versions: 1.0, 1.1, 1.x
Reporter: VVD
Width: 3509
Physical Width Dpi: 4650
Physical Width Inch: 1169.667
Height: 2481
Physical Height Dpi: 4650
Physical Height Inch: 827.00024
{code}
TiffImageParser.java (196):
-case 3: // Meter
-unitsPerInch = 0.0254;
+case 3: // Centimeter
+unitsPerInch = 2.54;
(c) http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
TiffImageParser.java (218):
-physicalWidthDpi = (int) (XResolutionPixelsPerUnit /
unitsPerInch);
+physicalWidthDpi = (int) Math.round(XResolutionPixelsPerUnit *
unitsPerInch);
TiffImageParser.java (226):
-physicalHeightDpi = (int) (YResolutionPixelsPerUnit /
unitsPerInch);
+physicalHeightDpi = (int) Math.round(YResolutionPixelsPerUnit
* unitsPerInch);
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
May be need to patch writing of tiff image too - don't know.
P.S. GIMP show values: 300,000, 300,000, 11,697, 8,270.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-686) Add methods negate() / reciprocal() to the FieldElement interface
[
https://issues.apache.org/jira/browse/MATH-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-686.
--
Fixed in 3.0.
> Add methods negate() / reciprocal() to the FieldElement interface
> -
>
> Key: MATH-686
> URL: https://issues.apache.org/jira/browse/MATH-686
> Project: Commons Math
> Issue Type: New Feature
>Reporter: Sébastien Brisard
>Priority: Trivial
> Fix For: 3.0
>
>
> As discussed on the mailing list, it is proposed to add two methods to the
> {{FieldElement}} interface
> * {{negate()}} : returns the additive inverse of {{this}} element.
> * {{reciprocal()}} : returns the multiplicative inverse of {{this}} element.
> Several name couples have been proposed by Phil
> # {{negate}}, {{invert}}
> # {{opposite}}, {{reciprocal}}
> # {{additiveInverse}}, {{multiplicativeInverse}}
> Looking at the classes implementing this interface in the core CM library, we
> find that
> * {{Complex}}, {{Dfp}}, {{BigFraction}} and {{Fraction}} already have a
> {{negate()}} method.
> * Besides, {{BigFraction}} and {{Fraction}} already have a {{reciprocal()}}
> method.
> So the best naming option would seem to be (for the time being) a mixture of
> what Phil proposed. I realize it's not completely satisfactory because one is
> a noun and one a verb. Do we want to have good grammar, or preserve what's
> already implemented? I tend to favour the first option (consistently change
> the name of existing methods).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-661) Simplify interface FieldDecompositionSolver
[
https://issues.apache.org/jira/browse/MATH-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-661.
--
Fixed in 3.0.
> Simplify interface FieldDecompositionSolver
> ---
>
> Key: MATH-661
> URL: https://issues.apache.org/jira/browse/MATH-661
> Project: Commons Math
> Issue Type: Task
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Trivial
> Labels: linear
>
> In accordance with MATH-660, {{T[] FieldDecompositionSolver.solve(T[] b)}}
> should be removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-669) UnivariateRealIntegrator throws ConvergenceException
[
https://issues.apache.org/jira/browse/MATH-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-669.
--
Fixed in 3.0.
> UnivariateRealIntegrator throws ConvergenceException
>
>
> Key: MATH-669
> URL: https://issues.apache.org/jira/browse/MATH-669
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Fix For: 3.0
>
>
> {{ConvergenceException}} is a checked exception, which goes against the
> developer's guide. It occurs in the {{throws}} clause of some methods in
> package o.a.c.m.analysis.integration. It seems that these occurences are
> remnants from previous versions, where exceptions were probably checked. This
> exception is actually never thrown : it is safe to remove it from the
> {{throws}} clause.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-646.
--
Fixed in 3.0.
> Unmodifiable views of RealVector
>
>
> Key: MATH-646
> URL: https://issues.apache.org/jira/browse/MATH-646
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
> Labels: linear, vector
> Attachments: MATH-646.patch, MATH-646.patch
>
>
> The issue has been discussed on the [mailing
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/].
> Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
> I chose not to nest it in {{AbstractRealVector}} because it would make the
> corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
> Maybe you'd like it to be {{private}} as well? A static method is provided in
> {{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
> {{RealVector}}.
> Tests are also provided. Since iterating through different implementations of
> {{RealVector}} is actually different, a test is provided for
> {{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
> {{OpenMapRealVector}}. These tests both derive from the same abstract test
> class. Hope everything works fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-633) AbstractRealMatrix extends RealLinearOperator
[
https://issues.apache.org/jira/browse/MATH-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-633.
--
Fixed in 3.0.
> AbstractRealMatrix extends RealLinearOperator
> -
>
> Key: MATH-633
> URL: https://issues.apache.org/jira/browse/MATH-633
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Fix For: 3.0
>
>
> This proposal has already been discussed on the
> [forum|http://mail-archives.apache.org/mod_mbox/commons-dev/201107.mbox/<4e1bc61e.8090...@m4x.org>].
> Since the issues raised by the implementation of {{RealLinearOperator}} are
> now solved, I propose to add {{extends RealLinearOperator}} to the
> declaration of {{AbstractRealMatrix}}. As far as I know, this no longer
> raises any error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-684) Add method multiply(int) to FieldElement
[ https://issues.apache.org/jira/browse/MATH-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard closed MATH-684. -- Fixed in 3.0. > Add method multiply(int) to FieldElement > > > Key: MATH-684 > URL: https://issues.apache.org/jira/browse/MATH-684 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Sébastien Brisard > > As discussed on the ML. n * x := x + x + ... + x (n times) is always > meaningful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-662) DecompositionSolver: merging unique "...Impl" classes with their interface
[
https://issues.apache.org/jira/browse/MATH-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-662.
--
Fixed in 3.0.
> DecompositionSolver: merging unique "...Impl" classes with their interface
> --
>
> Key: MATH-662
> URL: https://issues.apache.org/jira/browse/MATH-662
> Project: Commons Math
> Issue Type: Task
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>Priority: Trivial
> Labels: linear
>
> From the ML
> {quote}
> Hi.
> The "...Decomposition" interfaces in package "linear" have a unique
> implementation. Should the "...Impl" classes be renamed (removing the
> interfaces)?
> Regards,
> Gilles
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-659) Remove solve(double[][]) from DecompositionSolver
[
https://issues.apache.org/jira/browse/MATH-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-659.
--
Fixed in 3.0.
> Remove solve(double[][]) from DecompositionSolver
> -
>
> Key: MATH-659
> URL: https://issues.apache.org/jira/browse/MATH-659
> Project: Commons Math
> Issue Type: Task
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>Priority: Trivial
> Labels: linear
> Fix For: 3.0
>
>
> Following MATH-653, where {{double[]}} were removed from {{RealVector}}, and
> {{double[] solve(double[])}} was removed from {{DecompositionSolver}}, the
> method {{double[][] solve(double[][])}} should be removed from
> {{DecompositionSolver}}. {{RealMatrix solve(RealMatrix)}} should be called
> instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard closed MATH-699. -- Fixed in 3.0. > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Fix For: 3.0 > > Attachments: AbstractContinuousDistributionTest.java, > inv-cum-new-impl.zip > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-673) FieldLUDecomposition.Solver is missing appropriate testing
[ https://issues.apache.org/jira/browse/MATH-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard closed MATH-673. -- Fixed in 3.0. > FieldLUDecomposition.Solver is missing appropriate testing > -- > > Key: MATH-673 > URL: https://issues.apache.org/jira/browse/MATH-673 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard > Fix For: 3.0 > > > I could not find any unit test for this class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-715) PascalDistribution returns wrong values of mean and variance
[
https://issues.apache.org/jira/browse/MATH-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-715.
--
Fixed in 3.0.
> PascalDistribution returns wrong values of mean and variance
>
>
> Key: MATH-715
> URL: https://issues.apache.org/jira/browse/MATH-715
> Project: Commons Math
> Issue Type: Bug
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Fix For: 3.0
>
>
> The header of the Javadoc states that the random variable (say X) being
> represented by this {{o.a.c.m.distribution.PascalDistribution}} is the number
> of *failures*. The current Javadoc is slightly confusing, because it refers
> to the Wikipedia website, where the opposite convention is adopted (X is the
> number of *successes*) : different formulas therefore apply for the mean and
> variance of X. The javadoc should be made clearer, for example by inclusion
> of full formulas. Also the parameters differing from the Wikipedia reference
> should not have the same name
> * {{p}} is the probability of success in both cases: OK,
> * {{r}} is the number of failures in Wikipedia, but the number of successes
> in CM. This could be renamed (say) {{s}}.
> Finally, with the current notations of CM, the mean of X is given by
> {{mean(X) = r * (1 - p) / p}}, while the currently implemented formula is {{r
> * p / (1 - p)}}, which is actually the formula corresponding to the Wikipedia
> convention.
> The following piece of code shows that the current implementation is faulty
> {code:java}
> public class PascalDistributionDemo {
>public static void main(String[] args) {
>final int r = 10;
>final double p = 0.2;
>final int numTerms = 1000;
>final PascalDistribution distribution = new PascalDistribution(r, p);
>double mean = 0.;
>for (int k = numTerms - 1; k >= 0; k--) {
>mean += k * distribution.probability(k);
>}
>// The following prints 40.12
>System.out.println("Estimate of the mean = " + mean);
>// The following prints 2.5
>System.out.println("CM implementation = " +
> distribution.getNumericalMean());
>// The following prints 2.5
>System.out.println("r * p / (1 - p) = " + (r * p / (1 - p)));
>// The following prints 40.0
>System.out.println("r * (1 - p) / p = " + (r * (1 - p) / p));
>}
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-711) Merge xxxDistribution and xxxDistributionImpl in package distribution
[
https://issues.apache.org/jira/browse/MATH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-711.
--
Fixed in 3.0.
> Merge xxxDistribution and xxxDistributionImpl in package distribution
> -
>
> Key: MATH-711
> URL: https://issues.apache.org/jira/browse/MATH-711
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>
> This ticket follows the general trend aiming at removing unnecessary
> interfaces. In this package, the concerned interfaces are
> (/) {{BetaDistribution}}: done in r1205739
> (/) {{BinomialDistribution}}: done in r1205963
> (/) {{CauchyDistribution}}: done in r1206053
> (/) {{ChiSquaredDistribution}}: done in r1206060
> (/) {{ExponentialDistribution}}: done in r1206399
> (/) {{FDistribution}}: done in r1206399
> (/) {{GammaDistribution}}: done in r1206399
> (/) {{HypergeometricDistribution}}: done in r1206406
> (/) {{KolmogorovSmirnovDistribution}}: done in r1206425
> (/) {{NormalDistribution}}: done in r1206421
> (/) {{PascalDistribution}}: done in r1206421
> (/) {{PoissonDistribution}}: done in r1206434
> (/) {{TDistribution}}: done in r1206434
> (/) {{WeibullDistribution}}: done in r1206434
> (/) {{ZipfDistribution}}: done in r1206451
> Corresponding implementations {{xxxDistributionImpl}} will be renamed
> {{xxxDistribution}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-743.
--
Fixed in 3.0.
> Use enums in package transform
> --
>
> Key: MATH-743
> URL: https://issues.apache.org/jira/browse/MATH-743
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: api-change, enum, transform
> Fix For: 3.0
>
>
> As discussed on the mailing-list, enums could be used in the package
> {{transform}}
> # An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
> inverse transform is to be computed. This will replace the pair
> {{transform}}/{{inverseTransform}}
> # An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
> in each transform class, in order to specify the normalization that should be
> used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
> replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-735) Improvements to linear iterative solvers
[
https://issues.apache.org/jira/browse/MATH-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-735.
--
Fixed in 3.0.
> Improvements to linear iterative solvers
>
>
> Key: MATH-735
> URL: https://issues.apache.org/jira/browse/MATH-735
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: event, linear, solver
>
> Before we release version 3.0, I would like to perform some changes to the
> general framework for linear iterative solvers.
> # Remove interface {{InvertibleRealLinearOperator}}: this was only proposed
> for handling preconditioners. Let {{M}} be this preconditioner. In the course
> of the iterations, only matrix-vector products of the form {{M^(-1) . y}} are
> needed, never direct products {{M . x}}. So it's just as simple to provide
> {{M^(-1)}} as a standard {{RealLinearOperator}}, rather than {{M}} as an
> {{InvertibleRealLinearOperator}}. This removes a little bit of clutter in the
> class hierarchy.
> # {{o.a.c.m.util.IterationEvent}} should at the very least have a method to
> get the current iteration number. Overwise, I find myself keeping track of
> the number of times
> {{o.a.c.m.util.IterationManager.fireIterationPerformedEvent(IterationEvent)}}
> is called, which is both ugly and painfull.
> # {{o.a.c.m.util.linear.IterativeLinearSolverEvent}} should have a method to
> access the norm of the residual. I was reluctant to specify such a method in
> the interface at the start, because I was not sure any iterative solver
> provides an updated estimate of this quantity at each iteration. In fact,
> I've realized that most (if not all) solvers do, and it's quite nice to be
> able to access this value while monitoring the progress of the inversion
> (through {{o.a.c.m.utils.IterationListener}}). Otherwise, one has to compute
> {{b - A . x}} inside the listener, which *doubles* the cost of each iteration!
> # {{o.a.c.m.util.linear.IterativeLinearSolverEvent}} should have a method to
> access the residual (the vector itself, not only its norm). I'm not sure
> *all* solvers can do that, so this should be an optional feature, which might
> be useful. I see two different possible implementations
> ## specify {{RealVector
> o.a.c.m.util.linear.IterativeLinearSolverEvent.getResidual()}} as an optional
> feature (potentially throwing {{UnsupportedOperationException}}), together
> with a method {{boolean
> o.a.c.m.util.linear.IterativeLinearSolverEvent.providesResidual()}}. I think
> some of us do not like {{UnsupportedOperationException}}, but this would be
> similar to what was done in
> {{RealLinearOperator.operateTranspose(RealVector)}}.
> ## create a new interface {{RealVector
> o.a.c.m.util.linear.IterativeLinearSolverWithResidualEvent}}. This is similar
> to what is done currently, see {{o.a.c.m.linear.ProvidesResidual}}.
> I would love to have some feedback on the last point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments
[ https://issues.apache.org/jira/browse/IO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232219#comment-13232219 ] Manoj Mokashi commented on IO-305: -- I tested copying a 500MB tar archive with diffent buffersizes, and it does make a difference. e.g. buffersize => time in millis: 4096=>129954,*16=>71734,*64=91328 4096=>120406,*16=>80219,*64=69687 btw, accessing buffer.length inside the loop seems to affect performance for bigger lengths. As seen in the 1st statistics, the *64 method actually takes longer than *16. In the 2nd set i have used a buffersize var outside the loop as its constant. I guess the results will vary as per avail memory, OS, disk types etc. But it does make a difference to specify buffer size. wrt IO-308, i agree that passing a buffer would be even better. > New copy() method in IOUtils that takes additional offset, length and > buffersize arguments > -- > > Key: IO-305 > URL: https://issues.apache.org/jira/browse/IO-305 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Reporter: Manoj Mokashi >Priority: Minor > Fix For: 2.2 > > Attachments: IOUtils.java, IOUtilsTest.java > > > /** > * Copy from input to output stream > * @param is : input stream > * @param os : output stream > * @param offset : number of bytes to skip from input before copying > * -ve values are ignored > * @param len : number of bytes to copy. -1 means all > * @param bufferSize : buffer size to use for copying > * @throws IOException > */ > public static void copy( InputStream is, OutputStream os, int offset, int > len, int bufferSize) throws IOException > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
