On Sat, 29 Mar 2025 04:20:06 GMT, Phil Race wrote:
> LGTM but off-line I'll send some additional testing suggestions, to be 99.9%
> vs 99% sure
The change passed the suggestions on the usual platforms.
-
PR Comment: https://git.openjdk.org/jdk/pull/24283#issuecomment-2770652531
On Thu, 27 Mar 2025 22:13:00 GMT, Brian Burkhalter wrote:
> In the respective constructors, set the value of the initial stream position
> to the current file position.
This pull request has now been integrated.
Changeset: afcad8ca
Author: Brian Burkhalter
URL:
On Thu, 27 Mar 2025 22:13:00 GMT, Brian Burkhalter wrote:
> In the respective constructors, set the value of the initial stream position
> to the current file position.
No new failures are observed in CI tiers 1-3. The new test fails without but
passes with the proposed source c
In the respective constructors, set the value of the initial stream position to
the current file position.
-
Commit messages:
- 5043343: FileImageInputStream and FileImageOutputStream do not properly
track streamPos for RandomAccessFile
Changes: https://git.openjdk.org/jdk/pull/24
Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms in
the conversion of `RATIONAL` and `SRATIONAL` field values to a string. Also,
add a test.
-
Commit messages:
- 8152293: Incomplete fraction reduction in getValueAsString() for
TIFFTag.TIFF_RATIONAL, TIFF
On Thu, 20 Mar 2025 20:35:11 GMT, Brian Burkhalter wrote:
> Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms
> in the conversion of `RATIONAL` and `SRATIONAL` field values to a string.
> Also, add a test.
The corresponding issue is closed as Won't Fix
On Thu, 20 Mar 2025 20:35:11 GMT, Brian Burkhalter wrote:
> Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms
> in the conversion of `RATIONAL` and `SRATIONAL` field values to a string.
> Also, add a test.
This pull request has been closed without being i
On Thu, 20 Mar 2025 20:35:11 GMT, Brian Burkhalter wrote:
> Remove from `TIFFField.getValueAsString` the rudimentary reduction in terms
> in the conversion of `RATIONAL` and `SRATIONAL` field values to a string.
> Also, add a test.
If this change is deemed acceptable, then a CSR will
On Tue, 4 Mar 2025 03:41:10 GMT, Jeremy Wood wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed wa
On Tue, 4 Mar 2025 22:48:43 GMT, Brian Burkhalter wrote:
>>> > @mickleness please create a
>>> > [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue
>>> > [JDK-8160327](https://bugs.openjdk.org/browse/JDK-8160327) with the
>>> >
On Tue, 4 Mar 2025 20:24:51 GMT, Phil Race wrote:
> I created https://bugs.openjdk.org/browse/JDK-8351218
I intended to do that this afternoon.
> @bplb please fill it in and I'll review it.
> FWIW I don't think Jeremy has a JBS account .. so you'll have to do it.
Will do.
-
PR Co
On Tue, 4 Mar 2025 03:38:37 GMT, Jeremy wrote:
>>> Regarding the CSR proposal: that proposal looks accurate to me. I have no
>>> experience with CSR proposals/wording.
>>
>> If you are agreed on my proposed wording, please include the HTML change in
>> the PR and I will then create and manage
On Mon, 3 Mar 2025 22:56:10 GMT, Brian Burkhalter wrote:
>> Regarding the CSR proposal: that proposal looks accurate to me. I have no
>> experience with CSR proposals/wording.
>
>> Regarding the CSR proposal: that proposal looks accurate to me. I have no
>> ex
On Mon, 3 Mar 2025 22:52:27 GMT, Jeremy wrote:
> Regarding the CSR proposal: that proposal looks accurate to me. I have no
> experience with CSR proposals/wording.
If you are agreed on my proposed wording, please include the HTML change in the
PR and I will then create and manage the CSR.
---
On Mon, 3 Mar 2025 22:23:51 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Mon, 3 Mar 2025 19:38:56 GMT, Kevin Rushforth wrote:
>> I think I've finished all the pending edits I had in mind.
>>
>> Regarding ownership of images:
>> One sample image comes from Brian, the rest come from me.
>>
>> A few questions remain on my end:
>>
>> 1. The PR bot somehow flagged t
On Wed, 26 Feb 2025 09:23:47 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Sat, 1 Mar 2025 17:58:44 GMT, Jeremy wrote:
>> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java
>> line 182:
>>
>>> 180: // file shows it can also sometimes be 0x6. I've
>>> also observed it to be
>>> 181: // undefined, 0
On Mon, 3 Mar 2025 18:52:45 GMT, Brian Burkhalter wrote:
>> Yes, it probably is endianness, or endianness-related. My first design
>> question is: should we care? Currently this PR infers whether we're looking
>> for a JPEG or TIFF thumbnail based on other fields.
On Sat, 22 Feb 2025 00:19:44 GMT, Brian Burkhalter wrote:
>> I don't know how to initiate a CSR. Is that something I can initiate, or
>> does that require a more senior sponsor?
>>
>> I'm not done with the test files yet. (I'll make a note in this PR
On Fri, 21 Feb 2025 23:28:26 GMT, Jeremy wrote:
> I don't know how to initiate a CSR. Is that something I can initiate, or does
> that require a more senior sponsor?
I can do that, probably next week. We will need to update the JPEG metadata
documentation.
-
PR Comment: https://g
On Fri, 21 Feb 2025 02:31:42 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Tue, 18 Feb 2025 17:06:21 GMT, Brian Burkhalter wrote:
> [...] reading both JFIF and Exif thumbnails [...]
Note that
`test/jdk/javax/imageio/plugins/jpeg/jdk_8160327-jfif-jfif-and-exif-thumbnail-sharpshot-iphone.jpg`
contains both a JFIF and an Exif thumbnail and they are _differe
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Fri, 14 Feb 2025 21:41:24 GMT, Phil Race wrote:
>> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
>> line 1653:
>>
>>> 1651: if (exifMarkerSegment != null
>>> 1652: && exifMarkerSegment.getNumThumbnails() == 1) {
>>> 1653:
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy wrote:
>> This adds support for parsing thumbnails in an APP1 Exif marker.
>>
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In
>> that previous work the only additional meta info he parsed was the
On Thu, 13 Feb 2025 20:50:07 GMT, Phil Race wrote:
>> Jeremy has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8160327: fixing typo so `thumbnailPos` can be zero
>>
>> The `thumbnailLength` cannot be zero, but the position can be.
>
>
On Thu, 13 Feb 2025 23:19:35 GMT, Jeremy wrote:
> I can scan all the JPEGs on my machine and see if I find one with properties
> that match other 2 jpeg files we may not have permission to share
> (exif-rgb-thumbnail, sharpshot-iphone).
At a minimum the test images should cover:
1. compressed
On Thu, 13 Feb 2025 21:04:29 GMT, Phil Race wrote:
> Brian Burkhalter attached at least 3 of them, so I need him to speak up about
> where they came from.
The only one I can attribute at the moment is SV650.jpg, which is a photo of my
motorcycle taken by me with my own camera. It'
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Thu, 19 Sep 2024 22:12:28 GMT, Phil Race wrote:
> fix legal notices
Looks okay.
-
Marked as reviewed by bpb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21095#pullrequestreview-2316841147
On Thu, 4 May 2023 10:14:10 GMT, Martin Desruisseaux wrote:
> The `BufferedImage` Javadoc does not mention any constraint about the data
> type. In practice, `BufferedImage` with floating point values can be rendered
> by Java2D as well as integers, provided that a compatible `ColorModel` was
On Thu, 7 Dec 2023 19:47:22 GMT, Phil Race wrote:
> The conversion methods in this class return the wrong array.
Looks fine.
Probably corrects a faux pas of mine from about 18 years ago.
-
Marked as reviewed by bpb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17024#pul
On Mon, 26 Jun 2023 18:38:26 GMT, Jonathan Gibbons wrote:
> Please review a trivial update to normalize an `@since` tag.
+1
-
Marked as reviewed by bpb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14663#pullrequestreview-1499189002
On Tue, 4 Apr 2023 00:23:07 GMT, Roger Riggs wrote:
>> Update classes in the java.desktop module to use the
>> jdk.internal.util.OperatingSystem enum instead of the `os.name` system
>> property to select OS specific behaviors.
>
> Roger Riggs has updated the pull request with a new target base
On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg wrote:
> This PR suggests improving performance by using the newly introduced class
> `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for
> little en
42 matches
Mail list logo
