[jira] [Work logged] (FILEUPLOAD-340) Make commons-fileupload a proper JPMS module
[ https://issues.apache.org/jira/browse/FILEUPLOAD-340?focusedWorklogId=649848&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649848 ] ASF GitHub Bot logged work on FILEUPLOAD-340: - Author: ASF GitHub Bot Created on: 13/Sep/21 06:46 Start Date: 13/Sep/21 06:46 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #112: URL: https://github.com/apache/commons-fileupload/pull/112#issuecomment-917889852 [](https://coveralls.io/builds/42817598) Coverage remained the same at 78.163% when pulling **2175f3cad65dc9a3e16490c5a2834caeff51d1ad on martin-g:340-better-name-for-jpms** into **5855c053f99b00602a239c0cda6bed5e1fa89622 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649848) Time Spent: 3h 50m (was: 3h 40m) > Make commons-fileupload a proper JPMS module > > > Key: FILEUPLOAD-340 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-340 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Martin Tzvetanov Grigorov >Priority: Major > Fix For: 2.0 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > It would be nice if 2.0 provides module-info.class for Java 9+ JPMS. > > At the moment the project uses JDK 1.8 for the builds. > To add module-info.java it would have to use JDK 9+ (probably 11) with > -release=1.8. > An easy way to introduce module-info.java is by using > [Moditect|https://github.com/moditect/moditect#adding-a-module-descriptor-to-the-project-jar] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-fileupload] coveralls commented on pull request #112: FILEUPLOAD-340 Give a better name for the JPMS module
coveralls commented on pull request #112: URL: https://github.com/apache/commons-fileupload/pull/112#issuecomment-917889852 [](https://coveralls.io/builds/42817598) Coverage remained the same at 78.163% when pulling **2175f3cad65dc9a3e16490c5a2834caeff51d1ad on martin-g:340-better-name-for-jpms** into **5855c053f99b00602a239c0cda6bed5e1fa89622 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-747) Make commons-io a proper JPMS module
[ https://issues.apache.org/jira/browse/IO-747?focusedWorklogId=649847&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649847 ] ASF GitHub Bot logged work on IO-747: - Author: ASF GitHub Bot Created on: 13/Sep/21 06:45 Start Date: 13/Sep/21 06:45 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #268: URL: https://github.com/apache/commons-io/pull/268#issuecomment-912416268 [](https://coveralls.io/builds/42817604) Coverage decreased (-0.2%) to 89.073% when pulling **518ca0ba7b1ca3801b3cb4d629e1d3dc515d0370 on martin-g:io-747-make-commons-io-proper-jpms-module** into **70f3ce0b23de3180cb7e821e6792f086616e951a 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649847) Time Spent: 1h 20m (was: 1h 10m) > Make commons-io a proper JPMS module > > > Key: IO-747 > URL: https://issues.apache.org/jira/browse/IO-747 > Project: Commons IO > Issue Type: Task >Affects Versions: 2.12.0 >Reporter: Martin Tzvetanov Grigorov >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > It would be nice if commons-io provides module-info.class for Java 9+ JPMS. > > At the moment the project uses JDK 1.8 for the builds. > To add module-info.java it would have to use JDK 9+ (probably 11) with > -release=8. > An easy way to introduce module-info.java is by using > [Moditect|https://github.com/moditect/moditect#adding-a-module-descriptor-to-the-project-jar] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] coveralls edited a comment on pull request #268: IO-747 Make commons-io a proper JPMS module
coveralls edited a comment on pull request #268: URL: https://github.com/apache/commons-io/pull/268#issuecomment-912416268 [](https://coveralls.io/builds/42817604) Coverage decreased (-0.2%) to 89.073% when pulling **518ca0ba7b1ca3801b3cb4d629e1d3dc515d0370 on martin-g:io-747-make-commons-io-proper-jpms-module** into **70f3ce0b23de3180cb7e821e6792f086616e951a 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (FILEUPLOAD-340) Make commons-fileupload a proper JPMS module
[ https://issues.apache.org/jira/browse/FILEUPLOAD-340?focusedWorklogId=649836&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649836 ] ASF GitHub Bot logged work on FILEUPLOAD-340: - Author: ASF GitHub Bot Created on: 13/Sep/21 06:20 Start Date: 13/Sep/21 06:20 Worklog Time Spent: 10m Work Description: martin-g opened a new pull request #112: URL: https://github.com/apache/commons-fileupload/pull/112 Set javac's --release to 8 when releasing -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649836) Time Spent: 3h 40m (was: 3.5h) > Make commons-fileupload a proper JPMS module > > > Key: FILEUPLOAD-340 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-340 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Martin Tzvetanov Grigorov >Priority: Major > Fix For: 2.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > It would be nice if 2.0 provides module-info.class for Java 9+ JPMS. > > At the moment the project uses JDK 1.8 for the builds. > To add module-info.java it would have to use JDK 9+ (probably 11) with > -release=1.8. > An easy way to introduce module-info.java is by using > [Moditect|https://github.com/moditect/moditect#adding-a-module-descriptor-to-the-project-jar] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-fileupload] martin-g opened a new pull request #112: FILEUPLOAD-340 Give a better name for the JPMS module
martin-g opened a new pull request #112: URL: https://github.com/apache/commons-fileupload/pull/112 Set javac's --release to 8 when releasing -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-build-plugin] dependabot[bot] opened a new pull request #41: Bump spotbugs from 4.3.0 to 4.4.1
dependabot[bot] opened a new pull request #41: URL: https://github.com/apache/commons-build-plugin/pull/41 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.3.0 to 4.4.1. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases";>spotbugs's releases. SpotBugs 4.4.1 CHANGELOG https://github.com/spotbugs/spotbugs/blob/4.4.1/CHANGELOG.md";>https://github.com/spotbugs/spotbugs/blob/4.4.1/CHANGELOG.md CHECKSUM file checksum (sha256) spotbugs-4.4.1-javadoc.jar 7021a519365315a5fc0f98a0d2c3ed2b73eb20e61baf5b937453b6d085fa02ef spotbugs-4.4.1-sources.jar 4e6f932cf21f826d30873b0d51c250d5fc5307fd177ec782d38d82f1019c711d spotbugs-4.4.1.tgz 341873c7c4a73508aca6f32f03339aad38c926703accb2e799b5b632b0832bd9 spotbugs-4.4.1.zip 414152869130c22646ff0e6898bba09e9e20d6ade87eeebe912e645b578b9385 spotbugs-annotations-4.4.1-javadoc.jar cd290d907c4ab7a0ef0fcdacbe9059d8fa15a9de2b98f6ab9f5e02625f9ef557 spotbugs-annotations-4.4.1-sources.jar b338136e3e82d585348cde58a8fe3a678e16f51a35c31c1463e05fefef557aad spotbugs-annotations.jar fa5d3b17d585868c74c0e25b3c57c17282f9a3328c73ea5259bfd9ac99c6933a spotbugs-ant-4.4.1-javadoc.jar eb5600fbe8c01fb9d2f0bf33a079ba7f60ca1ffd0fc41bb7f21a1728d7823e9b spotbugs-ant-4.4.1-sources.jar c74dec42c0ed0dd1ae02a7410d8e0f0dbbee23e8e7da4a21910863677fcdbc8e spotbugs-ant.jar 9233e48d37882ae4e7a42e9f42ef4c63d6f802cf8f3b03ba575bee26e5032367 spotbugs.jar 48c53d2fdefbcd7292a05e23b50dbaab29047e3c87096e5129e4e7a627c354a3 test-harness-4.4.1-javadoc.jar 01c8e43294e9c2a394dcdb5224441e65bc9023a414efcd974b7af92ce10ce60a test-harness-4.4.1-sources.jar 2c1f5ef929453f3b682c7eb7c1e22db3082b5f74c5a5be439be5dc31dd7a31aa test-harness-4.4.1.jar 55d3a590b81ffec48293a76c45c0695914b405bf9f02bfb930e3ab99b5867d4f test-harness-core-4.4.1-javadoc.jar 74b76f75cb4e4a8504d6ff09ca8fcff6d0dba19b24979998ae214b230e44c018 test-harness-core-4.4.1-sources.jar f320f5eb4069e9686b760b2a6a0760989753225f9e9ce1226e3258ec64795d8a test-harness-core-4.4.1.jar cbec03867e077079d011e85f9932fb230fae3d909f741cffaa4c8097e91fdf40 test-harness-jupiter-4.4.1-javadoc.jar ad8111b37ab5ff2d33415fbb8bd559526259f316028a4129182a98e5966631e8 test-harness-jupiter-4.4.1-sources.jar 210353a57016e26b1a654d936a15f039613fa1ac532d485c1b1d03902f6c6315 test-harness-jupiter-4.4.1.jar 17e8d78d1868f86e63f3e5e3d878e86f3d7fb1b8cf1a8d5f89c982bfd3e2 SpotBugs 4.4.0 CHANGELOG https://github.com/spotbugs/spotbugs/blob/4.4.0/CHANGELOG.md";>https://github.com/spotbugs/spotbugs/blob/4.4.0/CHANGELOG.md CHECKSUM file checksum (sha256) spotbugs-4.4.0-javadoc.jar c25c0a3056ccf1ce9ae4c182ab73f6c9626d9031a30bf48857941d6c56ba3cc7 spotbugs-4.4.0-sources.jar 7b9b931b258f1db321fc5fb2e00946594dea976ad51a79a7f3ae48cac17d6c6e spotbugs-4.4.0.tgz 126b952cf248c92fbb7ba07462a71b3400bd1726fed96e179d8a50edd3e40745 spotbugs-4.4.0.zip f5f8b9aba1f3c87a508fbcb6045dcdc748e1ca4ce16803d6676417c9d82fb862 spotbugs-annotations-4.4.0-javadoc.jar 33a7ccc8917b9c5d2a6b133dceb5b212c0079986232a876471df4d7eb843bc8a spotbugs-annotations-4.4.0-sources.jar b338136e3e82d585348cde58a8fe3a678e16f51a35c31c1463e05fefef557aad spotbugs-annotations.jar 383fe580c90e1fea94a3387a8245e096beb792efdca7e04a0bbb4a8cbb81dea2 spotbugs-ant-4.4.0-javadoc.jar da10c9d3273d4367d8c940eec20e2799eba9ae54b920c506478236c241b75a55 spotbugs-ant-4.4.0-sources.jar c74dec42c0ed0dd1ae02a7410d8e0f0dbbee23e8e7da4a21910863677fcdbc8e spotbugs-ant.jar 9233e48d37882ae4e7a42e9f42ef4c63d6f802cf8f3b03ba575bee26e5032367 spotbugs.jar eb02e80126a4cdfb997fe90a1a2c6ff128b114cc7daab77ed3a773bef3adc2ca test-harness-4.4.0-javadoc.jar 4aee854334bb0dbcfd4697443abc0594a96c8c7db12e9e5408839fad4bf75162 test-harness-4.4.0-sources.jar 2c1f5ef929453f3b682c7eb7c1e22db3082b5f74c5a5be439be5dc31dd7a31aa test-harness-4.4.0.jar 55d3a590b81ffec48293a76c45c0695914b405bf9f02bfb930e3ab99b5867d4f test-harness-core-4.4.0-javadoc.jar 76c8694c8051dbc3f5e989448f3746f6da5374e24db22a022b5c2ffe73336f01 ... (truncated) Changelog Sourced from https://github.com/spotbugs/spotbugs/blob/master/CHANGELOG.md";>spotbugs's changelog. 4.4.1 - 2021-09-07 Changed Bump gson from 2.8.7 to 2.8.8 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1658";>#1658) Lower ExitCodes logger to debug level (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1661";>#1661) Fixed SARIF format to be compatible with
[GitHub] [commons-build-plugin] dependabot[bot] commented on pull request #40: Bump spotbugs from 4.3.0 to 4.4.0
dependabot[bot] commented on pull request #40: URL: https://github.com/apache/commons-build-plugin/pull/40#issuecomment-917874163 Superseded by #41. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-build-plugin] dependabot[bot] closed pull request #40: Bump spotbugs from 4.3.0 to 4.4.0
dependabot[bot] closed pull request #40: URL: https://github.com/apache/commons-build-plugin/pull/40 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] dependabot[bot] opened a new pull request #222: Bump maven-pmd-plugin from 3.14.0 to 3.15.0
dependabot[bot] opened a new pull request #222: URL: https://github.com/apache/commons-compress/pull/222 Bumps [maven-pmd-plugin](https://github.com/apache/maven-pmd-plugin) from 3.14.0 to 3.15.0. Commits https://github.com/apache/maven-pmd-plugin/commit/7a738884d38c3f7baee4d493940bdd063c06ca80";>7a73888 [maven-release-plugin] prepare release maven-pmd-plugin-3.15.0 https://github.com/apache/maven-pmd-plugin/commit/3ffd4d3762028b1b0a8f714297a21de37d0c5649";>3ffd4d3 [MPMD-308] Set Maven 3.1.0 as minimum version https://github.com/apache/maven-pmd-plugin/commit/5ae53f135b46102e7b749c834173cdc97678f834";>5ae53f1 [MPMD-283] Create a real aggregate goal https://github.com/apache/maven-pmd-plugin/commit/995edef0572010eb126a1e6a0b2982b60ad01d1f";>995edef (doc) Add example "Using a different ruleset for tests" https://github.com/apache/maven-pmd-plugin/commit/45a5e545ba3f53ccbe61dc5971ee5b623fa75cf7";>45a5e54 [MPMD-322] Display when PMD/CPD is skipped https://github.com/apache/maven-pmd-plugin/commit/b8fc018ef11b72bfa1306f0a85eea7370902079e";>b8fc018 [MPMD-321] Display PMD version that is being used also for pmd:pmd and https://github.com/apache/maven-pmd-plugin/commit/251f954faf6201efc4bed6396026fd0a59b8c5d1";>251f954 [MPMD-320] Correctly decode filename paths in classpath for toolchain https://github.com/apache/maven-pmd-plugin/commit/38701dab48b91e9a44611b7cf5b586a7778a6439";>38701da [MPMD-312] The rule BooleanInstantiation is deprecated https://github.com/apache/maven-pmd-plugin/commit/bf682a7db1d183662974885774819226c38222e8";>bf682a7 [MPMD-312] Upgrade to PMD 6.38.0 https://github.com/apache/maven-pmd-plugin/commit/89ce9fe4151dbf891ae677a21d019322fd90017e";>89ce9fe [MPMD-312] Upgrade to PMD 6.37.0 Additional commits viewable in https://github.com/apache/maven-pmd-plugin/compare/maven-pmd-plugin-3.14.0...maven-pmd-plugin-3.15.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] dependabot[bot] closed pull request #20: Bump junit-jupiter-api from 5.4.2 to 5.7.2
dependabot[bot] closed pull request #20: URL: https://github.com/apache/commons-scxml/pull/20 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] dependabot[bot] commented on pull request #20: Bump junit-jupiter-api from 5.4.2 to 5.7.2
dependabot[bot] commented on pull request #20: URL: https://github.com/apache/commons-scxml/pull/20#issuecomment-917751614 Superseded by #26. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] coveralls commented on pull request #272: Bump spotbugs from 4.4.0 to 4.4.1
coveralls commented on pull request #272: URL: https://github.com/apache/commons-io/pull/272#issuecomment-917750982 [](https://coveralls.io/builds/42813482) Coverage decreased (-0.04%) to 89.073% when pulling **def557329e395136fc7fbbb81d4440983952c40b on dependabot/maven/com.github.spotbugs-spotbugs-4.4.1** into **d82131ca63ccb4d5d40e9e8aa016e165d492c238 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (IMAGING-256) ArrayIndexOutOfBounds exception in JpegXmpRewriter.updateXmpXml()
[
https://issues.apache.org/jira/browse/IMAGING-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-256:
---
Fix Version/s: 1.0
> ArrayIndexOutOfBounds exception in JpegXmpRewriter.updateXmpXml()
> -
>
> Key: IMAGING-256
> URL: https://issues.apache.org/jira/browse/IMAGING-256
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha1
>Reporter: David Ekholm
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Fix For: 0.94-incubator, 1.0
>
> Attachments: Overhead_16_reduced.jpg
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Got the attached image passed to me. It triggers the following exception:
> {noformat}
> java.lang.IndexOutOfBoundsException: Range [65535, 65535 + 65535) out of
> bounds for length 77353
> at
> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromIndexSize(Preconditions.java:82)
> at
> java.base/jdk.internal.util.Preconditions.checkFromIndexSize(Preconditions.java:343)
> at java.base/java.util.Objects.checkFromIndexSize(Objects.java:425)
> at
> java.base/java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:129)
> at
> org.apache.commons.imaging.formats.jpeg.xmp.JpegXmpRewriter.writeXmpSegment(JpegXmpRewriter.java:200)
> at
> org.apache.commons.imaging.formats.jpeg.xmp.JpegXmpRewriter.updateXmpXml(JpegXmpRewriter.java:184)
> at
> org.apache.commons.imaging.formats.jpeg.xmp.JpegXmpRewriter.updateXmpXml(JpegXmpRewriter.java:124)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-310:
---
Fix Version/s: 1.0-alpha3
> JpegImageParser: Grayscale JPEG file with app14Segment returns
> ColorType.UNKNOWN
>
>
> Key: IMAGING-310
> URL: https://issues.apache.org/jira/browse/IMAGING-310
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: John Phillips
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha3
>
> Attachments: sample-grayscale-with-app14segment.jpg
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In org.apache.commons.imaging.formats.jpeg. the logic to determine colorType
> (lines 825-970) does not account for a Grayscale image when there is an app14
> segment present.
> When the number of components is 1 or 2, the colorType should always be
> Grayscale. None of the other logic would change that.
> It seems to me that the switch (numberOfComponents) statement should be moved
> to the top of this bit of code, and the rest of the logic should handled
> under Case 3 & 4:
> {noformat}
> // See
> http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
> ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
> switch (numberOfComponents) {
> case 1:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> break;
>
> case 2:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> transparent = true;
> break;
>
> case 3:
> case 4:
> // Some images have both JFIF/APP0 and APP14.
> // JFIF is meant to win but in them APP14 is clearly right, so make it
> win.
> if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
> etc.
> {noformat}
> Attached sample-grayscale-with-app14segment.jpg, which can be used to
> demonstrate the issue.
> I've modified the code locally, but I'm a newbie at submitting
> pull-requests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-310:
---
Assignee: Bruno P. Kinoshita
> JpegImageParser: Grayscale JPEG file with app14Segment returns
> ColorType.UNKNOWN
>
>
> Key: IMAGING-310
> URL: https://issues.apache.org/jira/browse/IMAGING-310
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: John Phillips
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: sample-grayscale-with-app14segment.jpg
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In org.apache.commons.imaging.formats.jpeg. the logic to determine colorType
> (lines 825-970) does not account for a Grayscale image when there is an app14
> segment present.
> When the number of components is 1 or 2, the colorType should always be
> Grayscale. None of the other logic would change that.
> It seems to me that the switch (numberOfComponents) statement should be moved
> to the top of this bit of code, and the rest of the logic should handled
> under Case 3 & 4:
> {noformat}
> // See
> http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
> ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
> switch (numberOfComponents) {
> case 1:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> break;
>
> case 2:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> transparent = true;
> break;
>
> case 3:
> case 4:
> // Some images have both JFIF/APP0 and APP14.
> // JFIF is meant to win but in them APP14 is clearly right, so make it
> win.
> if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
> etc.
> {noformat}
> Attached sample-grayscale-with-app14segment.jpg, which can be used to
> demonstrate the issue.
> I've modified the code locally, but I'm a newbie at submitting
> pull-requests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] coveralls commented on pull request #271: Bump junit-bom from 5.8.0-RC1 to 5.8.0
coveralls commented on pull request #271: URL: https://github.com/apache/commons-io/pull/271#issuecomment-917746252 [](https://coveralls.io/builds/42813392) Coverage remained the same at 89.116% when pulling **be489525e7fc048c6b047b76d81fe760146a4a24 on dependabot/maven/org.junit-junit-bom-5.8.0** into **d82131ca63ccb4d5d40e9e8aa016e165d492c238 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] dependabot[bot] opened a new pull request #272: Bump spotbugs from 4.4.0 to 4.4.1
dependabot[bot] opened a new pull request #272: URL: https://github.com/apache/commons-io/pull/272 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.4.0 to 4.4.1. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases";>spotbugs's releases. SpotBugs 4.4.1 CHANGELOG https://github.com/spotbugs/spotbugs/blob/4.4.1/CHANGELOG.md";>https://github.com/spotbugs/spotbugs/blob/4.4.1/CHANGELOG.md CHECKSUM file checksum (sha256) spotbugs-4.4.1-javadoc.jar 7021a519365315a5fc0f98a0d2c3ed2b73eb20e61baf5b937453b6d085fa02ef spotbugs-4.4.1-sources.jar 4e6f932cf21f826d30873b0d51c250d5fc5307fd177ec782d38d82f1019c711d spotbugs-4.4.1.tgz 341873c7c4a73508aca6f32f03339aad38c926703accb2e799b5b632b0832bd9 spotbugs-4.4.1.zip 414152869130c22646ff0e6898bba09e9e20d6ade87eeebe912e645b578b9385 spotbugs-annotations-4.4.1-javadoc.jar cd290d907c4ab7a0ef0fcdacbe9059d8fa15a9de2b98f6ab9f5e02625f9ef557 spotbugs-annotations-4.4.1-sources.jar b338136e3e82d585348cde58a8fe3a678e16f51a35c31c1463e05fefef557aad spotbugs-annotations.jar fa5d3b17d585868c74c0e25b3c57c17282f9a3328c73ea5259bfd9ac99c6933a spotbugs-ant-4.4.1-javadoc.jar eb5600fbe8c01fb9d2f0bf33a079ba7f60ca1ffd0fc41bb7f21a1728d7823e9b spotbugs-ant-4.4.1-sources.jar c74dec42c0ed0dd1ae02a7410d8e0f0dbbee23e8e7da4a21910863677fcdbc8e spotbugs-ant.jar 9233e48d37882ae4e7a42e9f42ef4c63d6f802cf8f3b03ba575bee26e5032367 spotbugs.jar 48c53d2fdefbcd7292a05e23b50dbaab29047e3c87096e5129e4e7a627c354a3 test-harness-4.4.1-javadoc.jar 01c8e43294e9c2a394dcdb5224441e65bc9023a414efcd974b7af92ce10ce60a test-harness-4.4.1-sources.jar 2c1f5ef929453f3b682c7eb7c1e22db3082b5f74c5a5be439be5dc31dd7a31aa test-harness-4.4.1.jar 55d3a590b81ffec48293a76c45c0695914b405bf9f02bfb930e3ab99b5867d4f test-harness-core-4.4.1-javadoc.jar 74b76f75cb4e4a8504d6ff09ca8fcff6d0dba19b24979998ae214b230e44c018 test-harness-core-4.4.1-sources.jar f320f5eb4069e9686b760b2a6a0760989753225f9e9ce1226e3258ec64795d8a test-harness-core-4.4.1.jar cbec03867e077079d011e85f9932fb230fae3d909f741cffaa4c8097e91fdf40 test-harness-jupiter-4.4.1-javadoc.jar ad8111b37ab5ff2d33415fbb8bd559526259f316028a4129182a98e5966631e8 test-harness-jupiter-4.4.1-sources.jar 210353a57016e26b1a654d936a15f039613fa1ac532d485c1b1d03902f6c6315 test-harness-jupiter-4.4.1.jar 17e8d78d1868f86e63f3e5e3d878e86f3d7fb1b8cf1a8d5f89c982bfd3e2 Changelog Sourced from https://github.com/spotbugs/spotbugs/blob/master/CHANGELOG.md";>spotbugs's changelog. 4.4.1 - 2021-09-07 Changed Bump gson from 2.8.7 to 2.8.8 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1658";>#1658) Lower ExitCodes logger to debug level (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1661";>#1661) Fixed SARIF format to be compatible with Github code scanning API requirements (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1630";>#1630) Fixed Fixed immutable classes in java.net.* as being flagged as EI (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1653";>#1653 Classes containing only static methods with setter-like names are no longer considered as mutable (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1601";>#1601) Handle all immutable collections in the Guava library as immutable (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1601";>#1601) Classes annotated with https://github.com/Immutable";>@Immutable or https://github.com/jdk";>@jdk.internal.ValueBased are considered as immutable (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1601";>#1601) All classes in packages java.time and java.math are now correctly handled as immutable (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1601";>#1601) Commits https://github.com/spotbugs/spotbugs/commit/fca34060e81294274a9c1796895d823069f2985d";>fca3406 build: set group even to the root project https://github.com/spotbugs/spotbugs/commit/8da782560086dded1d2766e670b1e92d2db5b372";>8da7825 release v4.4.1 https://github.com/spotbugs/spotbugs/commit/69a2ae83470af289ce089180c4d8db0a33419e70";>69a2ae8 build(deps): bump com.github.spotbugs from 4.7.3 to 4.7.4 https://github.com/spotbugs/spotbugs/commit/9d2884d30a186921d2003ca6eb7c058ca839e89b";>9d2884d Add field "text" to the object message in result (SARIF) (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1631";>#1631) https://github.com/spotbugs/spotbugs/commit/3a111bce56fc6d5a255f146785b41ea3b549461c";>3a111bc Classes annotated with https://github.com/Immutable";>@Immutable or https://g
[jira] [Work logged] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?focusedWorklogId=649800&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649800
]
ASF GitHub Bot logged work on IMAGING-310:
--
Author: ASF GitHub Bot
Created on: 13/Sep/21 00:30
Start Date: 13/Sep/21 00:30
Worklog Time Spent: 10m
Work Description: kinow commented on a change in pull request #163:
URL: https://github.com/apache/commons-imaging/pull/163#discussion_r706933392
##
File path:
src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
##
@@ -824,44 +824,44 @@ public ImageInfo getImageInfo(final ByteSource
byteSource, final Maphttp://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
-// Some images have both JFIF/APP0 and APP14.
-// JFIF is meant to win but in them APP14 is clearly right, so make it
win.
-if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
-final int colorTransform = app14Segment.getAdobeColorTransform();
-switch (colorTransform) {
-case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
-if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.RGB;
-} else if (numberOfComponents == 4) {
-colorType = ImageInfo.ColorType.CMYK;
+switch (numberOfComponents) {
+case 1:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+break;
+case 2:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+transparent = true;
+break;
+case 3:
+case 4:
+// Some images have both JFIF/APP0 and APP14.
+// JFIF is meant to win but in them APP14 is clearly right, so
make it win.
+if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
+final int colorTransform =
app14Segment.getAdobeColorTransform();
+switch (colorTransform) {
+case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
+if (numberOfComponents == 3) {
+colorType = ImageInfo.ColorType.RGB;
+} else if (numberOfComponents == 4) {
+colorType = ImageInfo.ColorType.CMYK;
+}
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
+colorType = ImageInfo.ColorType.YCbCr;
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
+colorType = ImageInfo.ColorType.YCCK;
+break;
+default:
+break;
}
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
-colorType = ImageInfo.ColorType.YCbCr;
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
-colorType = ImageInfo.ColorType.YCCK;
-break;
-default:
-break;
-}
-} else if (jfifSegment != null) {
-if (numberOfComponents == 1) {
-colorType = ImageInfo.ColorType.GRAYSCALE;
-} else if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.YCbCr;
-}
-} else {
-switch (numberOfComponents) {
-case 1:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-break;
-case 2:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-transparent = true;
-break;
-case 3:
-case 4:
+} else if (jfifSegment != null) {
+if (numberOfComponents == 1) {
Review comment:
This condition is now impossible since we are in the switch-case for
`numberOfComponents == 3 | 4`.
I think the previous logic was closer to the documentation from [Oracle on
Java/colors
metadata](https://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color):
> If a JFIF APP0 marker segment is present, the colorspace is known to be
either grayscale or YCbCr. If an APP2 marker segment containing an embedded ICC
profile is also present, then the YCbCr is converted to RGB according to the
formulas given in the JFIF spec, and the ICC profile is assumed to refer to the
resulting RGB space.
@jephillips34 what about this fix (diff from `master`)?
```diff
diff --git
a/src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
b/src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
index 288c2398..1cc0fcae 100644
---
a/src/main/java/org/apache/common
[GitHub] [commons-imaging] kinow commented on a change in pull request #163: IMAGING-310 JpegImageParser.getImageInfo() Refactor colorType logic to first look at numberOfComponents
kinow commented on a change in pull request #163:
URL: https://github.com/apache/commons-imaging/pull/163#discussion_r706933392
##
File path:
src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
##
@@ -824,44 +824,44 @@ public ImageInfo getImageInfo(final ByteSource
byteSource, final Maphttp://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
-// Some images have both JFIF/APP0 and APP14.
-// JFIF is meant to win but in them APP14 is clearly right, so make it
win.
-if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
-final int colorTransform = app14Segment.getAdobeColorTransform();
-switch (colorTransform) {
-case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
-if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.RGB;
-} else if (numberOfComponents == 4) {
-colorType = ImageInfo.ColorType.CMYK;
+switch (numberOfComponents) {
+case 1:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+break;
+case 2:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+transparent = true;
+break;
+case 3:
+case 4:
+// Some images have both JFIF/APP0 and APP14.
+// JFIF is meant to win but in them APP14 is clearly right, so
make it win.
+if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
+final int colorTransform =
app14Segment.getAdobeColorTransform();
+switch (colorTransform) {
+case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
+if (numberOfComponents == 3) {
+colorType = ImageInfo.ColorType.RGB;
+} else if (numberOfComponents == 4) {
+colorType = ImageInfo.ColorType.CMYK;
+}
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
+colorType = ImageInfo.ColorType.YCbCr;
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
+colorType = ImageInfo.ColorType.YCCK;
+break;
+default:
+break;
}
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
-colorType = ImageInfo.ColorType.YCbCr;
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
-colorType = ImageInfo.ColorType.YCCK;
-break;
-default:
-break;
-}
-} else if (jfifSegment != null) {
-if (numberOfComponents == 1) {
-colorType = ImageInfo.ColorType.GRAYSCALE;
-} else if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.YCbCr;
-}
-} else {
-switch (numberOfComponents) {
-case 1:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-break;
-case 2:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-transparent = true;
-break;
-case 3:
-case 4:
+} else if (jfifSegment != null) {
+if (numberOfComponents == 1) {
Review comment:
This condition is now impossible since we are in the switch-case for
`numberOfComponents == 3 | 4`.
I think the previous logic was closer to the documentation from [Oracle on
Java/colors
metadata](https://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color):
> If a JFIF APP0 marker segment is present, the colorspace is known to be
either grayscale or YCbCr. If an APP2 marker segment containing an embedded ICC
profile is also present, then the YCbCr is converted to RGB according to the
formulas given in the JFIF spec, and the ICC profile is assumed to refer to the
resulting RGB space.
@jephillips34 what about this fix (diff from `master`)?
```diff
diff --git
a/src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
b/src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
index 288c2398..1cc0fcae 100644
---
a/src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
+++
b/src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java
@@ -834,6 +834,8 @@ public class JpegImageParser extends ImageParser
implements XmpEmbeddable {
colorType = ImageInfo.ColorType.RGB;
} else if (numberOfComponents == 4) {
colorType = ImageInfo.ColorType.CMYK;
+
[GitHub] [commons-io] dependabot[bot] opened a new pull request #271: Bump junit-bom from 5.8.0-RC1 to 5.8.0
dependabot[bot] opened a new pull request #271: URL: https://github.com/apache/commons-io/pull/271 Bumps [junit-bom](https://github.com/junit-team/junit5) from 5.8.0-RC1 to 5.8.0. Release notes Sourced from https://github.com/junit-team/junit5/releases";>junit-bom's releases. JUnit 5.8.0 = Platform 1.8.0 + Jupiter 5.8.0 + Vintage 5.8.0 See http://junit.org/junit5/docs/5.8.0/release-notes/";>Release Notes. Commits https://github.com/junit-team/junit5/commit/709fd6e1d6d311a5950e0a957283ac37530e41fd";>709fd6e Release 5.8 https://github.com/junit-team/junit5/commit/fa7405528ecdf5a274b050d117ffb2738df0c426";>fa74055 Use text block https://github.com/junit-team/junit5/commit/d36ea28cf16b59db91499d8c63fd4d409c0b9900";>d36ea28 Declare service in module descriptor https://github.com/junit-team/junit5/commit/6c0bf0229a552c926d584fea7c5b2826d464ca21";>6c0bf02 Fix modular user guide tests by reading module jdk.httpserver https://github.com/junit-team/junit5/commit/b6dff0d53e6fdc9036d4a35b84fa76ef16e6b0fd";>b6dff0d Add LauncherSessionListener example to user guide https://github.com/junit-team/junit5/commit/439084d2fd72d6f891d09847d6c5f26de26e4b0b";>439084d Polish documentation for 5.8 GA https://github.com/junit-team/junit5/commit/fa021ed31335335ae64fb5dc8f3c94e4c59aa775";>fa021ed Document published dependency scope change as potentially breaking https://github.com/junit-team/junit5/commit/efb980c4e9b24f0639f62ed91835ebf2f7b921e1";>efb980c Polishing https://github.com/junit-team/junit5/commit/0bd6feb4910cbf0a4facbbeeddd06ce6318d179d";>0bd6feb Remove link to package private class in Javadoc https://github.com/junit-team/junit5/commit/75538a7262f8fe44a085d061d37be8f3792eb241";>75538a7 Document that autoCloseArguments in https://github.com/ParameterizedTest";>@ParameterizedTest is a potentially break... Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.8.0-RC1...r5.8.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[ https://issues.apache.org/jira/browse/IMAGING-285?focusedWorklogId=649795&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649795 ] ASF GitHub Bot logged work on IMAGING-285: -- Author: ASF GitHub Bot Created on: 12/Sep/21 23:25 Start Date: 12/Sep/21 23:25 Worklog Time Spent: 10m Work Description: kinow commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917731260 I think it'd be better if you did these changes @gwlucastrig . I only created the PR to change the base (it was kinow/commons-imaging). -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649795) Time Spent: 1h 40m (was: 1.5h) > Decoding of Rational Numbers broken when large values present > - > > Key: IMAGING-285 > URL: https://issues.apache.org/jira/browse/IMAGING-285 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha2 >Reporter: John Andrade >Priority: Major > Attachments: DJI_0267 cropped.JPG > > Original Estimate: 1h > Time Spent: 1h 40m > Remaining Estimate: 0h > > Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have > attached a file where the conversion fails. I used the > getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the > TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by > a few miles. > I've traced the source and I believe the issue is with how the RationalNumber > class uses two 32-bit signed integers for the numerator and denominator. The > definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as > if the RationalNumber class already expects this as it has a non-public > static method called factoryMethod to create a RationalNumber from two 64-bit > numbers. > This error is introduced in the ByteConversions class, specifically the > toRational method where it uses the regular RationalNumber constructor and > thus ensures any rational numbers that have numerator or denominator greater > than the max signed 32-bit value will produce invalid values. > I am attaching a JPEG that has this problem. I had to crop it to reduce the > size, but the EXIF data was preserved. > The EXIF GPS data contained in the JPEG is: > GpsLatitudeRef: "N" > GpsLatitude: 38, 1, 36, 1, 4120083230, 7000 > GpsLongitudeRef: "W" > GpsLongitude: 90, 1, 12, 1, 2379156648, 7000 > According to the properties of the image (right-clicking on Windows 10), the > L/L of the image is: > Latitude: 38: 36: 58.85833 > Longitude: 90: 12: 33.98795... (Windows doesn't show E/W) > These values convert to: > 38.616349536627 > -90.2094410978095 > When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast > methods, I get the following values: > 38.5993060156 > -90.19239757679365 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[ https://issues.apache.org/jira/browse/IMAGING-285?focusedWorklogId=649796&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649796 ] ASF GitHub Bot logged work on IMAGING-285: -- Author: ASF GitHub Bot Created on: 12/Sep/21 23:25 Start Date: 12/Sep/21 23:25 Worklog Time Spent: 10m Work Description: kinow commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917731327 While on it, you can rebase/squash too :grimacing: then it should be ready to merge. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649796) Time Spent: 1h 50m (was: 1h 40m) > Decoding of Rational Numbers broken when large values present > - > > Key: IMAGING-285 > URL: https://issues.apache.org/jira/browse/IMAGING-285 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha2 >Reporter: John Andrade >Priority: Major > Attachments: DJI_0267 cropped.JPG > > Original Estimate: 1h > Time Spent: 1h 50m > Remaining Estimate: 0h > > Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have > attached a file where the conversion fails. I used the > getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the > TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by > a few miles. > I've traced the source and I believe the issue is with how the RationalNumber > class uses two 32-bit signed integers for the numerator and denominator. The > definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as > if the RationalNumber class already expects this as it has a non-public > static method called factoryMethod to create a RationalNumber from two 64-bit > numbers. > This error is introduced in the ByteConversions class, specifically the > toRational method where it uses the regular RationalNumber constructor and > thus ensures any rational numbers that have numerator or denominator greater > than the max signed 32-bit value will produce invalid values. > I am attaching a JPEG that has this problem. I had to crop it to reduce the > size, but the EXIF data was preserved. > The EXIF GPS data contained in the JPEG is: > GpsLatitudeRef: "N" > GpsLatitude: 38, 1, 36, 1, 4120083230, 7000 > GpsLongitudeRef: "W" > GpsLongitude: 90, 1, 12, 1, 2379156648, 7000 > According to the properties of the image (right-clicking on Windows 10), the > L/L of the image is: > Latitude: 38: 36: 58.85833 > Longitude: 90: 12: 33.98795... (Windows doesn't show E/W) > These values convert to: > 38.616349536627 > -90.2094410978095 > When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast > methods, I get the following values: > 38.5993060156 > -90.19239757679365 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #164: IMAGING-285 RationalNumber to support unsigned int format
kinow commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917731327 While on it, you can rebase/squash too :grimacing: then it should be ready to merge. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] kinow commented on pull request #164: IMAGING-285 RationalNumber to support unsigned int format
kinow commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917731260 I think it'd be better if you did these changes @gwlucastrig . I only created the PR to change the base (it was kinow/commons-imaging). -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[ https://issues.apache.org/jira/browse/IMAGING-285?focusedWorklogId=649793&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649793 ] ASF GitHub Bot logged work on IMAGING-285: -- Author: ASF GitHub Bot Created on: 12/Sep/21 23:13 Start Date: 12/Sep/21 23:13 Worklog Time Spent: 10m Work Description: gwlucastrig commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917728774 Is the plan for you to make these changes or should I. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649793) Time Spent: 1.5h (was: 1h 20m) > Decoding of Rational Numbers broken when large values present > - > > Key: IMAGING-285 > URL: https://issues.apache.org/jira/browse/IMAGING-285 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha2 >Reporter: John Andrade >Priority: Major > Attachments: DJI_0267 cropped.JPG > > Original Estimate: 1h > Time Spent: 1.5h > Remaining Estimate: 0h > > Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have > attached a file where the conversion fails. I used the > getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the > TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by > a few miles. > I've traced the source and I believe the issue is with how the RationalNumber > class uses two 32-bit signed integers for the numerator and denominator. The > definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as > if the RationalNumber class already expects this as it has a non-public > static method called factoryMethod to create a RationalNumber from two 64-bit > numbers. > This error is introduced in the ByteConversions class, specifically the > toRational method where it uses the regular RationalNumber constructor and > thus ensures any rational numbers that have numerator or denominator greater > than the max signed 32-bit value will produce invalid values. > I am attaching a JPEG that has this problem. I had to crop it to reduce the > size, but the EXIF data was preserved. > The EXIF GPS data contained in the JPEG is: > GpsLatitudeRef: "N" > GpsLatitude: 38, 1, 36, 1, 4120083230, 7000 > GpsLongitudeRef: "W" > GpsLongitude: 90, 1, 12, 1, 2379156648, 7000 > According to the properties of the image (right-clicking on Windows 10), the > L/L of the image is: > Latitude: 38: 36: 58.85833 > Longitude: 90: 12: 33.98795... (Windows doesn't show E/W) > These values convert to: > 38.616349536627 > -90.2094410978095 > When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast > methods, I get the following values: > 38.5993060156 > -90.19239757679365 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] gwlucastrig commented on pull request #164: IMAGING-285 RationalNumber to support unsigned int format
gwlucastrig commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917728774 Is the plan for you to make these changes or should I. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[
https://issues.apache.org/jira/browse/IMAGING-285?focusedWorklogId=649792&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649792
]
ASF GitHub Bot logged work on IMAGING-285:
--
Author: ASF GitHub Bot
Created on: 12/Sep/21 23:11
Start Date: 12/Sep/21 23:11
Worklog Time Spent: 10m
Work Description: gwlucastrig commented on a change in pull request #164:
URL: https://github.com/apache/commons-imaging/pull/164#discussion_r706926789
##
File path: src/main/java/org/apache/commons/imaging/common/RationalNumber.java
##
@@ -73,8 +124,41 @@ private static long gcd(final long a, final long b) {
return gcd(b, a % b);
}
+/**
+ * Negates the value of the RationalNumber. If the numerator of this
+ * instance has its high-order bit set, then its value is too large
+ * to be treated as a Java 32-bit signed integer. In such a case, the
+ * only way that a RationalNumber instance can be negated is to
+ * sacrifice one bit of precision by dividing both the numerator and
+ * the denominator by 2. However, if that computation would result
Review comment:
by the computed greatest common denominator.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 649792)
Time Spent: 1h 20m (was: 1h 10m)
> Decoding of Rational Numbers broken when large values present
> -
>
> Key: IMAGING-285
> URL: https://issues.apache.org/jira/browse/IMAGING-285
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: John Andrade
>Priority: Major
> Attachments: DJI_0267 cropped.JPG
>
> Original Estimate: 1h
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have
> attached a file where the conversion fails. I used the
> getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the
> TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by
> a few miles.
> I've traced the source and I believe the issue is with how the RationalNumber
> class uses two 32-bit signed integers for the numerator and denominator. The
> definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as
> if the RationalNumber class already expects this as it has a non-public
> static method called factoryMethod to create a RationalNumber from two 64-bit
> numbers.
> This error is introduced in the ByteConversions class, specifically the
> toRational method where it uses the regular RationalNumber constructor and
> thus ensures any rational numbers that have numerator or denominator greater
> than the max signed 32-bit value will produce invalid values.
> I am attaching a JPEG that has this problem. I had to crop it to reduce the
> size, but the EXIF data was preserved.
> The EXIF GPS data contained in the JPEG is:
> GpsLatitudeRef: "N"
> GpsLatitude: 38, 1, 36, 1, 4120083230, 7000
> GpsLongitudeRef: "W"
> GpsLongitude: 90, 1, 12, 1, 2379156648, 7000
> According to the properties of the image (right-clicking on Windows 10), the
> L/L of the image is:
> Latitude: 38: 36: 58.85833
> Longitude: 90: 12: 33.98795... (Windows doesn't show E/W)
> These values convert to:
> 38.616349536627
> -90.2094410978095
> When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast
> methods, I get the following values:
> 38.5993060156
> -90.19239757679365
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #164: IMAGING-285 RationalNumber to support unsigned int format
gwlucastrig commented on a change in pull request #164:
URL: https://github.com/apache/commons-imaging/pull/164#discussion_r706926789
##
File path: src/main/java/org/apache/commons/imaging/common/RationalNumber.java
##
@@ -73,8 +124,41 @@ private static long gcd(final long a, final long b) {
return gcd(b, a % b);
}
+/**
+ * Negates the value of the RationalNumber. If the numerator of this
+ * instance has its high-order bit set, then its value is too large
+ * to be treated as a Java 32-bit signed integer. In such a case, the
+ * only way that a RationalNumber instance can be negated is to
+ * sacrifice one bit of precision by dividing both the numerator and
+ * the denominator by 2. However, if that computation would result
Review comment:
by the computed greatest common denominator.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[
https://issues.apache.org/jira/browse/IMAGING-285?focusedWorklogId=649791&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649791
]
ASF GitHub Bot logged work on IMAGING-285:
--
Author: ASF GitHub Bot
Created on: 12/Sep/21 23:10
Start Date: 12/Sep/21 23:10
Worklog Time Spent: 10m
Work Description: gwlucastrig commented on a change in pull request #164:
URL: https://github.com/apache/commons-imaging/pull/164#discussion_r706926641
##
File path: src/main/java/org/apache/commons/imaging/common/RationalNumber.java
##
@@ -73,8 +124,41 @@ private static long gcd(final long a, final long b) {
return gcd(b, a % b);
}
+/**
+ * Negates the value of the RationalNumber. If the numerator of this
+ * instance has its high-order bit set, then its value is too large
+ * to be treated as a Java 32-bit signed integer. In such a case, the
+ * only way that a RationalNumber instance can be negated is to
+ * sacrifice one bit of precision by dividing both the numerator and
+ * the denominator by 2. However, if that computation would result
+ * in a zero denominator, then the value cannot be negated and an
+ * exception is thrown.
+ * @return a valid instance with a negated value.
+ */
public RationalNumber negate() {
-return new RationalNumber(-numerator, divisor);
+long n = numerator;
+long d = divisor;
+if (unsignedType) {
+// An instance of an unsigned type can be negated if and only if
+// its high-order bit (the sign bit) is clear. If the bit is set,
+// it is necessary to adjust the
Review comment:
numerator and denominator values.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 649791)
Time Spent: 1h 10m (was: 1h)
> Decoding of Rational Numbers broken when large values present
> -
>
> Key: IMAGING-285
> URL: https://issues.apache.org/jira/browse/IMAGING-285
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: John Andrade
>Priority: Major
> Attachments: DJI_0267 cropped.JPG
>
> Original Estimate: 1h
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have
> attached a file where the conversion fails. I used the
> getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the
> TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by
> a few miles.
> I've traced the source and I believe the issue is with how the RationalNumber
> class uses two 32-bit signed integers for the numerator and denominator. The
> definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as
> if the RationalNumber class already expects this as it has a non-public
> static method called factoryMethod to create a RationalNumber from two 64-bit
> numbers.
> This error is introduced in the ByteConversions class, specifically the
> toRational method where it uses the regular RationalNumber constructor and
> thus ensures any rational numbers that have numerator or denominator greater
> than the max signed 32-bit value will produce invalid values.
> I am attaching a JPEG that has this problem. I had to crop it to reduce the
> size, but the EXIF data was preserved.
> The EXIF GPS data contained in the JPEG is:
> GpsLatitudeRef: "N"
> GpsLatitude: 38, 1, 36, 1, 4120083230, 7000
> GpsLongitudeRef: "W"
> GpsLongitude: 90, 1, 12, 1, 2379156648, 7000
> According to the properties of the image (right-clicking on Windows 10), the
> L/L of the image is:
> Latitude: 38: 36: 58.85833
> Longitude: 90: 12: 33.98795... (Windows doesn't show E/W)
> These values convert to:
> 38.616349536627
> -90.2094410978095
> When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast
> methods, I get the following values:
> 38.5993060156
> -90.19239757679365
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #164: IMAGING-285 RationalNumber to support unsigned int format
gwlucastrig commented on a change in pull request #164:
URL: https://github.com/apache/commons-imaging/pull/164#discussion_r706926641
##
File path: src/main/java/org/apache/commons/imaging/common/RationalNumber.java
##
@@ -73,8 +124,41 @@ private static long gcd(final long a, final long b) {
return gcd(b, a % b);
}
+/**
+ * Negates the value of the RationalNumber. If the numerator of this
+ * instance has its high-order bit set, then its value is too large
+ * to be treated as a Java 32-bit signed integer. In such a case, the
+ * only way that a RationalNumber instance can be negated is to
+ * sacrifice one bit of precision by dividing both the numerator and
+ * the denominator by 2. However, if that computation would result
+ * in a zero denominator, then the value cannot be negated and an
+ * exception is thrown.
+ * @return a valid instance with a negated value.
+ */
public RationalNumber negate() {
-return new RationalNumber(-numerator, divisor);
+long n = numerator;
+long d = divisor;
+if (unsignedType) {
+// An instance of an unsigned type can be negated if and only if
+// its high-order bit (the sign bit) is clear. If the bit is set,
+// it is necessary to adjust the
Review comment:
numerator and denominator values.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[
https://issues.apache.org/jira/browse/IMAGING-285?focusedWorklogId=649789&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649789
]
ASF GitHub Bot logged work on IMAGING-285:
--
Author: ASF GitHub Bot
Created on: 12/Sep/21 23:08
Start Date: 12/Sep/21 23:08
Worklog Time Spent: 10m
Work Description: gwlucastrig commented on a change in pull request #164:
URL: https://github.com/apache/commons-imaging/pull/164#discussion_r706926284
##
File path:
src/main/java/org/apache/commons/imaging/formats/tiff/fieldtypes/FieldTypeRational.java
##
@@ -31,11 +31,19 @@ public FieldTypeRational(final int type, final String name)
{
@Override
public Object getValue(final TiffField entry) {
final byte[] bytes = entry.getByteArrayValue();
+boolean unsignedType = true;
+if(entry.getFieldType()==RATIONAL){
+unsignedType = true;
+}else if(entry.getFieldType()==SRATIONAL){
+unsignedType = false;
+}
Review comment:
That will work. There are only the two conditions.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 649789)
Remaining Estimate: 0h (was: 10m)
Time Spent: 1h (was: 50m)
> Decoding of Rational Numbers broken when large values present
> -
>
> Key: IMAGING-285
> URL: https://issues.apache.org/jira/browse/IMAGING-285
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
>Affects Versions: 1.0-alpha2
>Reporter: John Andrade
>Priority: Major
> Attachments: DJI_0267 cropped.JPG
>
> Original Estimate: 1h
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have
> attached a file where the conversion fails. I used the
> getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the
> TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by
> a few miles.
> I've traced the source and I believe the issue is with how the RationalNumber
> class uses two 32-bit signed integers for the numerator and denominator. The
> definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as
> if the RationalNumber class already expects this as it has a non-public
> static method called factoryMethod to create a RationalNumber from two 64-bit
> numbers.
> This error is introduced in the ByteConversions class, specifically the
> toRational method where it uses the regular RationalNumber constructor and
> thus ensures any rational numbers that have numerator or denominator greater
> than the max signed 32-bit value will produce invalid values.
> I am attaching a JPEG that has this problem. I had to crop it to reduce the
> size, but the EXIF data was preserved.
> The EXIF GPS data contained in the JPEG is:
> GpsLatitudeRef: "N"
> GpsLatitude: 38, 1, 36, 1, 4120083230, 7000
> GpsLongitudeRef: "W"
> GpsLongitude: 90, 1, 12, 1, 2379156648, 7000
> According to the properties of the image (right-clicking on Windows 10), the
> L/L of the image is:
> Latitude: 38: 36: 58.85833
> Longitude: 90: 12: 33.98795... (Windows doesn't show E/W)
> These values convert to:
> 38.616349536627
> -90.2094410978095
> When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast
> methods, I get the following values:
> 38.5993060156
> -90.19239757679365
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #164: IMAGING-285 RationalNumber to support unsigned int format
gwlucastrig commented on a change in pull request #164:
URL: https://github.com/apache/commons-imaging/pull/164#discussion_r706926284
##
File path:
src/main/java/org/apache/commons/imaging/formats/tiff/fieldtypes/FieldTypeRational.java
##
@@ -31,11 +31,19 @@ public FieldTypeRational(final int type, final String name)
{
@Override
public Object getValue(final TiffField entry) {
final byte[] bytes = entry.getByteArrayValue();
+boolean unsignedType = true;
+if(entry.getFieldType()==RATIONAL){
+unsignedType = true;
+}else if(entry.getFieldType()==SRATIONAL){
+unsignedType = false;
+}
Review comment:
That will work. There are only the two conditions.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?focusedWorklogId=649757&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649757
]
ASF GitHub Bot logged work on IMAGING-310:
--
Author: ASF GitHub Bot
Created on: 12/Sep/21 21:28
Start Date: 12/Sep/21 21:28
Worklog Time Spent: 10m
Work Description: kinow commented on pull request #163:
URL: https://github.com/apache/commons-imaging/pull/163#issuecomment-917713704
Rebased onto master and squashed commits. Let's start reviewing 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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 649757)
Time Spent: 50m (was: 40m)
> JpegImageParser: Grayscale JPEG file with app14Segment returns
> ColorType.UNKNOWN
>
>
> Key: IMAGING-310
> URL: https://issues.apache.org/jira/browse/IMAGING-310
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: John Phillips
>Priority: Major
> Attachments: sample-grayscale-with-app14segment.jpg
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In org.apache.commons.imaging.formats.jpeg. the logic to determine colorType
> (lines 825-970) does not account for a Grayscale image when there is an app14
> segment present.
> When the number of components is 1 or 2, the colorType should always be
> Grayscale. None of the other logic would change that.
> It seems to me that the switch (numberOfComponents) statement should be moved
> to the top of this bit of code, and the rest of the logic should handled
> under Case 3 & 4:
> {noformat}
> // See
> http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
> ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
> switch (numberOfComponents) {
> case 1:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> break;
>
> case 2:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> transparent = true;
> break;
>
> case 3:
> case 4:
> // Some images have both JFIF/APP0 and APP14.
> // JFIF is meant to win but in them APP14 is clearly right, so make it
> win.
> if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
> etc.
> {noformat}
> Attached sample-grayscale-with-app14segment.jpg, which can be used to
> demonstrate the issue.
> I've modified the code locally, but I'm a newbie at submitting
> pull-requests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #163: IMAGING-310 JpegImageParser.getImageInfo() Refactor colorType logic to first look at numberOfComponents
kinow commented on pull request #163: URL: https://github.com/apache/commons-imaging/pull/163#issuecomment-917713704 Rebased onto master and squashed commits. Let's start reviewing 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?focusedWorklogId=649756&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649756
]
ASF GitHub Bot logged work on IMAGING-310:
--
Author: ASF GitHub Bot
Created on: 12/Sep/21 21:26
Start Date: 12/Sep/21 21:26
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #163:
URL: https://github.com/apache/commons-imaging/pull/163#issuecomment-917713359
[](https://coveralls.io/builds/42812432)
Coverage remained the same at 76.839% when pulling
**fcfafb6efebb52d5f4566344970ba551350b5c69 on
jephillips34:IMAGING-310-JpegImageParser-colorType** into
**b6b4e9c739ffc22fa0cdad3d54dd203682a47960 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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 649756)
Time Spent: 40m (was: 0.5h)
> JpegImageParser: Grayscale JPEG file with app14Segment returns
> ColorType.UNKNOWN
>
>
> Key: IMAGING-310
> URL: https://issues.apache.org/jira/browse/IMAGING-310
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: John Phillips
>Priority: Major
> Attachments: sample-grayscale-with-app14segment.jpg
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In org.apache.commons.imaging.formats.jpeg. the logic to determine colorType
> (lines 825-970) does not account for a Grayscale image when there is an app14
> segment present.
> When the number of components is 1 or 2, the colorType should always be
> Grayscale. None of the other logic would change that.
> It seems to me that the switch (numberOfComponents) statement should be moved
> to the top of this bit of code, and the rest of the logic should handled
> under Case 3 & 4:
> {noformat}
> // See
> http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
> ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
> switch (numberOfComponents) {
> case 1:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> break;
>
> case 2:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> transparent = true;
> break;
>
> case 3:
> case 4:
> // Some images have both JFIF/APP0 and APP14.
> // JFIF is meant to win but in them APP14 is clearly right, so make it
> win.
> if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
> etc.
> {noformat}
> Attached sample-grayscale-with-app14segment.jpg, which can be used to
> demonstrate the issue.
> I've modified the code locally, but I'm a newbie at submitting
> pull-requests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] coveralls commented on pull request #163: IMAGING-310 JpegImageParser.getImageInfo() Refactor colorType logic to first look at numberOfComponents
coveralls commented on pull request #163: URL: https://github.com/apache/commons-imaging/pull/163#issuecomment-917713359 [](https://coveralls.io/builds/42812432) Coverage remained the same at 76.839% when pulling **fcfafb6efebb52d5f4566344970ba551350b5c69 on jephillips34:IMAGING-310-JpegImageParser-colorType** into **b6b4e9c739ffc22fa0cdad3d54dd203682a47960 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?focusedWorklogId=649753&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649753 ] ASF GitHub Bot logged work on IMAGING-312: -- Author: ASF GitHub Bot Created on: 12/Sep/21 21:21 Start Date: 12/Sep/21 21:21 Worklog Time Spent: 10m Work Description: kinow commented on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917712496 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649753) Time Spent: 1h (was: 50m) > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha3 > > Attachments: Imaging312.png > > Time Spent: 1h > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?focusedWorklogId=649752&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649752 ] ASF GitHub Bot logged work on IMAGING-312: -- Author: ASF GitHub Bot Created on: 12/Sep/21 21:20 Start Date: 12/Sep/21 21:20 Worklog Time Spent: 10m Work Description: kinow merged pull request #168: URL: https://github.com/apache/commons-imaging/pull/168 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649752) Time Spent: 50m (was: 40m) > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha3 > > Attachments: Imaging312.png > > Time Spent: 50m > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #168: IMAGING-312 Corrected handling of ExtraSamples tag
kinow commented on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917712496 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] kinow merged pull request #168: IMAGING-312 Corrected handling of ExtraSamples tag
kinow merged pull request #168: URL: https://github.com/apache/commons-imaging/pull/168 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?focusedWorklogId=649751&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649751 ] ASF GitHub Bot logged work on IMAGING-312: -- Author: ASF GitHub Bot Created on: 12/Sep/21 21:18 Start Date: 12/Sep/21 21:18 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917691980 [](https://coveralls.io/builds/42812407) Coverage increased (+0.002%) to 76.839% when pulling **a767b9d2b32a68247f25fd6428baeb473027c7e0 on gwlucastrig:IMAGING-312** into **4b923bb3f845f5bf63fc10972ba6541c8101a4e2 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649751) Time Spent: 40m (was: 0.5h) > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha3 > > Attachments: Imaging312.png > > Time Spent: 40m > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] coveralls edited a comment on pull request #168: IMAGING-312 Corrected handling of ExtraSamples tag
coveralls edited a comment on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917691980 [](https://coveralls.io/builds/42812407) Coverage increased (+0.002%) to 76.839% when pulling **a767b9d2b32a68247f25fd6428baeb473027c7e0 on gwlucastrig:IMAGING-312** into **4b923bb3f845f5bf63fc10972ba6541c8101a4e2 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] kinow commented on a change in pull request #155: Remove redundant local variable.
kinow commented on a change in pull request #155:
URL: https://github.com/apache/commons-imaging/pull/155#discussion_r706913932
##
File path:
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
##
@@ -262,23 +261,22 @@ public boolean visitSegment(final int marker, final
byte[] markerBytes,
} else if (marker == JpegConstants.DHT_MARKER) {
final DhtSegment dhtSegment = new DhtSegment(marker, segmentData);
for (final HuffmanTable element : dhtSegment.huffmanTables) {
Review comment:
Sorry, came to review this one today, and realized I had an old comment
pending to be submitted.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-imaging] kinow commented on a change in pull request #155: Remove redundant local variable.
kinow commented on a change in pull request #155:
URL: https://github.com/apache/commons-imaging/pull/155#discussion_r665701393
##
File path:
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
##
@@ -262,23 +261,22 @@ public boolean visitSegment(final int marker, final
byte[] markerBytes,
} else if (marker == JpegConstants.DHT_MARKER) {
final DhtSegment dhtSegment = new DhtSegment(marker, segmentData);
for (final HuffmanTable element : dhtSegment.huffmanTables) {
Review comment:
We can rename this one to `table` too @arturobernalg
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IMAGING-285) Decoding of Rational Numbers broken when large values present
[ https://issues.apache.org/jira/browse/IMAGING-285?focusedWorklogId=649747&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649747 ] ASF GitHub Bot logged work on IMAGING-285: -- Author: ASF GitHub Bot Created on: 12/Sep/21 21:14 Start Date: 12/Sep/21 21:14 Worklog Time Spent: 10m Work Description: kinow commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917711623 ping @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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649747) Remaining Estimate: 10m (was: 20m) Time Spent: 50m (was: 40m) > Decoding of Rational Numbers broken when large values present > - > > Key: IMAGING-285 > URL: https://issues.apache.org/jira/browse/IMAGING-285 > Project: Commons Imaging > Issue Type: Bug > Components: imaging.common.* >Affects Versions: 1.0-alpha2 >Reporter: John Andrade >Priority: Major > Attachments: DJI_0267 cropped.JPG > > Original Estimate: 1h > Time Spent: 50m > Remaining Estimate: 10m > > Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have > attached a file where the conversion fails. I used the > getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the > TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by > a few miles. > I've traced the source and I believe the issue is with how the RationalNumber > class uses two 32-bit signed integers for the numerator and denominator. The > definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as > if the RationalNumber class already expects this as it has a non-public > static method called factoryMethod to create a RationalNumber from two 64-bit > numbers. > This error is introduced in the ByteConversions class, specifically the > toRational method where it uses the regular RationalNumber constructor and > thus ensures any rational numbers that have numerator or denominator greater > than the max signed 32-bit value will produce invalid values. > I am attaching a JPEG that has this problem. I had to crop it to reduce the > size, but the EXIF data was preserved. > The EXIF GPS data contained in the JPEG is: > GpsLatitudeRef: "N" > GpsLatitude: 38, 1, 36, 1, 4120083230, 7000 > GpsLongitudeRef: "W" > GpsLongitude: 90, 1, 12, 1, 2379156648, 7000 > According to the properties of the image (right-clicking on Windows 10), the > L/L of the image is: > Latitude: 38: 36: 58.85833 > Longitude: 90: 12: 33.98795... (Windows doesn't show E/W) > These values convert to: > 38.616349536627 > -90.2094410978095 > When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast > methods, I get the following values: > 38.5993060156 > -90.19239757679365 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #164: IMAGING-285 RationalNumber to support unsigned int format
kinow commented on pull request #164: URL: https://github.com/apache/commons-imaging/pull/164#issuecomment-917711623 ping @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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-312. Fix Version/s: 1.0-alpha3 Assignee: Bruno P. Kinoshita Resolution: Fixed > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha3 > > Attachments: Imaging312.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413798#comment-17413798 ] Bruno P. Kinoshita commented on IMAGING-312: Hi [~gwlucas] , Excellent issue description, thanks a lot. I had a look at the TIFF spec rev 6.0 this morning. I think the specification could do a much better job at saying that when that field is 0 it must be ignored. I read it as values greater than 0 are used to choose what to do about the extra data... but since it didn't explicitly say "if 0 then ignore the extra data" I think I understand why a developer would forget to handle cases where ExtraSamples is to be ignored, even if we have the extra data. I think we should go with your solution and choose later - based on user feedback - whether we need a parameter to enable/disable it, or maybe raise an exception in some special situations. Thanks! Bruno > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Priority: Major > Attachments: Imaging312.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?focusedWorklogId=649734&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649734 ] ASF GitHub Bot logged work on IMAGING-312: -- Author: ASF GitHub Bot Created on: 12/Sep/21 19:34 Start Date: 12/Sep/21 19:34 Worklog Time Spent: 10m Work Description: gwlucastrig commented on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917696748 Now that the code has passed all checks, I believe it is ready for review. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649734) Time Spent: 0.5h (was: 20m) > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Priority: Major > Attachments: Imaging312.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] gwlucastrig commented on pull request #168: IMAGING-312 Corrected handling of ExtraSamples tag
gwlucastrig commented on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917696748 Now that the code has passed all checks, I believe it is ready for review. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?focusedWorklogId=649729&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649729 ] ASF GitHub Bot logged work on IMAGING-312: -- Author: ASF GitHub Bot Created on: 12/Sep/21 19:04 Start Date: 12/Sep/21 19:04 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917691980 [](https://coveralls.io/builds/42811554) Coverage increased (+0.002%) to 76.839% when pulling **1bd10e603c561fad8c1680da46bef26cbfc25b09 on gwlucastrig:IMAGING-312** into **4b923bb3f845f5bf63fc10972ba6541c8101a4e2 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649729) Time Spent: 20m (was: 10m) > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Priority: Major > Attachments: Imaging312.png > > Time Spent: 20m > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] coveralls commented on pull request #168: IMAGING-312 Corrected handling of ExtraSamples tag
coveralls commented on pull request #168: URL: https://github.com/apache/commons-imaging/pull/168#issuecomment-917691980 [](https://coveralls.io/builds/42811554) Coverage increased (+0.002%) to 76.839% when pulling **1bd10e603c561fad8c1680da46bef26cbfc25b09 on gwlucastrig:IMAGING-312** into **4b923bb3f845f5bf63fc10972ba6541c8101a4e2 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?focusedWorklogId=649728&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649728 ] ASF GitHub Bot logged work on IMAGING-312: -- Author: ASF GitHub Bot Created on: 12/Sep/21 18:58 Start Date: 12/Sep/21 18:58 Worklog Time Spent: 10m Work Description: gwlucastrig opened a new pull request #168: URL: https://github.com/apache/commons-imaging/pull/168 While this change addresses the special case of pre-multiplied alpha, there may be some system and JVM-version dependent issues. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 649728) Remaining Estimate: 0h Time Spent: 10m > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Priority: Major > Attachments: Imaging312.png > > Time Spent: 10m > Remaining Estimate: 0h > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] gwlucastrig opened a new pull request #168: IMAGING-312 Corrected handling of ExtraSamples tag
gwlucastrig opened a new pull request #168: URL: https://github.com/apache/commons-imaging/pull/168 While this change addresses the special case of pre-multiplied alpha, there may be some system and JVM-version dependent issues. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413677#comment-17413677 ] Gary Lucas commented on IMAGING-312: Here's an example comparing the image cited above as rendered by Windows Photo Viewer and the new version of the Commons Imaging API that I will be submitting in a couple of days. You can see the effect of misinterpreting the 4th byte for each pixel as giving alpha values. In reality, the metadata in the TIFF file indicates that the 4th byte should be ignored. !Imaging312.png! > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Priority: Major > Attachments: Imaging312.png > > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMAGING-312) Alpha-channel setting not interpreted from ExtraSamples tag
[ https://issues.apache.org/jira/browse/IMAGING-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Lucas updated IMAGING-312: --- Attachment: Imaging312.png > Alpha-channel setting not interpreted from ExtraSamples tag > --- > > Key: IMAGING-312 > URL: https://issues.apache.org/jira/browse/IMAGING-312 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 > Environment: >Reporter: Gary Lucas >Priority: Major > Attachments: Imaging312.png > > > Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB > samples but do not define alpha. In some cases, these images are treated as > semi-transparent when they should be opaque. Commons Imaging is not unique > in this regard... Windows Photo Viewer does the same thing. > The TIFF specification allows RGB images to be encoded with 4-bytes per > pixel. It would be natural to assume (as Commons Imaging does) that the 4th > byte is the alpha channel and that it would have values of 0xff in the case > where pixels were opaque. However, the interpretation of the 4th byte depends > on information in the TIFF "ExtraSamples" tag. > It turns out that there are images in-the-wild that use 4 bytes, but populate > the 4th byte with junk values. For example, there are a number of older > aerial photographs from the US Geological Survey (USGS) that do this. These > images give an ExtraSamples tag with a value of zero. But the TIFF > specification calls for images to be treated as having alpha channels only if > the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples > has a value of 0, the 4th byte is to be ignored. > So while the USGS TIFF files are in compliance with the TIFF specification, > they use an unintuitive behavior. Because the Commons Imaging library > assumes that the 4th byte would be specified with valid-alpha values, it does > not render the images correctly. > There are many examples of this phenomenon on the USGS Earth Explorer > website. One specific example: > * High Resolution Orthoimagery > * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir > * Entity: 2818289_18TYL425825 > * File: 18tyl425825.tif > *Proposed Fix* > I propose to do the following: > * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is > true if and only if the ExtraSamples tag is supplied and contains values 1 or > 2. > * Provide a hasAlpha accessor for the ImageBuilder class (is should really > have one anyway) > * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha > when processing RGB images that have 4 samples per pixel samples. > *Concerns* > At this time, I am not sure what to do if an RGB TIFF image uses 4-samples > per pixel but the ExtraSamples tag is not provided. At this time, I have not > seen an example of this, but my collection of sample TIFF files is rather > narrow and I would not rule it out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMAGING-266) Read integer data from GeoTIFFS
[
https://issues.apache.org/jira/browse/IMAGING-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413674#comment-17413674
]
Gary Lucas commented on IMAGING-266:
Well, it took a couple of tries, but I have just submitted changes to address
this issue. This new feature allows developers to use the Commons Imaging API
to access the extensive set of high-resolution, global elevation data available
through the Shuttle Radar Topography Mission (SRTM) as well as many other
geophysical data sources.
Here's an example image produced from a TIFF file that contains elevation data
for a 1-degree square in the vicinity of Auckland, New Zealand. The original
TIFF file gives a 3601-by-3601 grid of elevation data points at a 1 second of
arc spacing (about 30 meters). This image shown below is reduced to 25 percent
of the original size.
!Imaging266_SRTM.jpg!
The image above was produced using a modified version of my DemoCOG
application. I've written a web article describing the techniques used for
rendering numerical data from GeoTIFFs. If you are interested, you can read it
at [https://gwlucastrig.github.io/gridfour/notes/ElevationGeoTiff1.html]
An earlier version of the Imaging API implemented a method called
getFloatingPointRasterData() to read data from TIFF files that contained
floating-point data. However, the elevation data in SRTM products is stored in
a short-integer format. So the access method has been changed to handle both
floating-point and integral data types and its name has been changed to
getRasterData().
The example code below shows how to use the API:
{code:java}
import java.io.File;
import org.apache.commons.imaging.FormatCompliance;
import org.apache.commons.imaging.common.bytesource.ByteSourceFile;
import org.apache.commons.imaging.formats.tiff.TiffContents;
import org.apache.commons.imaging.formats.tiff.TiffDirectory;
import org.apache.commons.imaging.formats.tiff.TiffRasterData;
import org.apache.commons.imaging.formats.tiff.TiffRasterDataType;
import org.apache.commons.imaging.formats.tiff.TiffReader;
public class ExampleRasterReader {
public static void main(String[] args) throws Exception {
File target = new File(args[0]);
ByteSourceFile byteSource = new ByteSourceFile(target);
// Establish a TiffReader. This is just a simple constructor that
// does not actually access the file. So the application cannot
// obtain the byteOrder, or other details, until the contents has
// been read.
TiffReader tiffReader = new TiffReader(true);
// Read the directories in the TIFF file. Directories are the
// main data element of a TIFF file. They usually include an image
// element, but sometimes just carry metadata. This example
// reads all the directories in the file. Typically, reading
// the directories is not a time-consuming operation.
TiffContents contents = tiffReader.readDirectories(
byteSource,
true, // indicates that application should read image data, if
present
FormatCompliance.getDefault());
// Read the first Image File Directory (IFD) in the file. A practical
// implementation could use any of the directories in the file.
// By convention, the main payload (image or raster data) is
// stored in the first TIFF directory with optional thumbnail images
// or metadata directories to follow.
TiffDirectory directory = contents.directories.get(0);
// Check that the first directory in the file has raster data.
if (!directory.hasTiffRasterData()) {
System.out.println(
"Specified directory does not contain raster data");
System.exit(-1);
}
// read all the raster data for the first directory.
// The return value may carry short integers or single-precision
// floating point values. The optional parameter, which is set to
// null in this example, could be used to fetch only a subset
// of the overall data.
TiffRasterData raster = directory.getRasterData(null);
// THe data type may be integral or floating point.
TiffRasterDataType rasterDataType = raster.getDataType();
System.out.println("Data type for raster: " + rasterDataType.name());
int width = raster.getWidth();
int height = raster.getHeight();
int nSamples = 0;
double sumSamples = 0;
if (rasterDataType == TiffRasterDataType.INTEGER) {
// data type is integral, so we use getIntValue()
for (int y = 0; y < height; y++) {
for (int x = 0; x < width; x++) {
int sample = raster.getIntValue(x, y);
if (sample > 0) {
nSamples++;
[jira] [Updated] (IMAGING-266) Read integer data from GeoTIFFS
[ https://issues.apache.org/jira/browse/IMAGING-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Lucas updated IMAGING-266: --- Attachment: Imaging266_SRTM.jpg > Read integer data from GeoTIFFS > > > Key: IMAGING-266 > URL: https://issues.apache.org/jira/browse/IMAGING-266 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.0-alpha3 >Reporter: Gary Lucas >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha3 > > Attachments: Imaging266_SRTM.jpg > > Time Spent: 5.5h > Remaining Estimate: 0h > > I recently discovered that there is a large amount of digital elevation data > available in the form of 16-bit integer coded data in GeoTIFF files (TIFF > files with geographic tags). I propose to enhance the Commons Imaging API to > read these files. This work will be similar to the work I did for reading > floating-point raster data under ISSUE-251. > Available data include the nearly-global coverage of one-second of arc > elevation data produced from the Shuttle Radar Topography Mission (SRTM) and > other sources. These products give grids of elevation data with a 30 meter > cell spacing for most of the world's land masses. They are available at NASA > Earthdata and Japan Space Systems websites, see > [https://asterweb.jpl.nasa.gov/gdem.asp|https://asterweb.jpl.nasa.gov/gdem.asp] > There is also a ocean bathymetry data set available in this format at > [http://www.shadedrelief.com/blue-earth/] > This new feature will continue to expand the usefulness of the Commons > Imaging API in accessing GeoTIFF products. > Request for Feedback > So far, the data products I've found (ASTER and Blue Earth Bathymetry) give > elevation and ocean depth data in meters recorded as a short integer. I > haven't found an example of where the 32-bit integer format is used. For > now, I am planning on only coding the 16-bit integer variation. Does anyone > know if the 32-bit version is worth supporting? My criteria for determining > that would be based on whether there is a significant number of projects > using that format (life is too short to chase rarely used data formats). > Currently, one of the code-analysis operations conducted by the Commons > Imaging build process is coverage by JUnit tests. Lacking any test data for > the 32-bit case, I am reluctant to include it in the code base because it > would mean putting uncovered code into the distribution. > Also, I am wondering about the best design for the access API. The current > TiffImageParser class has a method called getFloatingPointRasterData() that > returns an instance of TiffRasterData. TiffRasterData is pretty much > hard-wired to floating point data. I am thinking of creating a new method > called getIntegerRasterData() that would return an instance of a new class > called TiffIntegerRasterData. Does this seem reasonable? I considered trying > to combine both kinds of results into a unified class and method, but it > seems more unwieldy than useful. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
