On Tue, 4 Nov 2025 01:27:18 GMT, Sergey Bylokhov <[email protected]> wrote:
>> I see that none of the code path under this API uses BandedSampleModel.
>>
>> We can continue to create DataBuffer to hold >Integer.MAX_VALUE and use it
>> to create a Raster with BandedSampleModel and then create a BufferedImage
>> out of it.
>>
>>
>> import java.awt.Transparency;
>> import java.awt.color.ColorSpace;
>> import java.awt.image.BandedSampleModel;
>> import java.awt.image.BufferedImage;
>> import java.awt.image.ColorModel;
>> import java.awt.image.ComponentColorModel;
>> import java.awt.image.DataBuffer;
>> import java.awt.image.DataBufferByte;
>> import java.awt.image.Raster;
>> import java.awt.image.WritableRaster;
>>
>> public class BandedBufferedImage {
>> public static void main (String[] args) {
>> int width = 1;
>> int height = Integer.MAX_VALUE - 5;
>> int numBands = 3; // For RGB
>> int dataType = DataBuffer.TYPE_BYTE; // 8-bit per band
>>
>> // Create arrays for bank indices and band offsets
>> int[] bankIndices = new int[numBands];
>> int[] bandOffsets = new int[numBands];
>> for (int i = 0; i < numBands; i++) {
>> bankIndices[i] = i; // Each band in its own bank
>> bandOffsets[i] = 0; // Offset within each bank
>> }
>>
>> BandedSampleModel sampleModel = new BandedSampleModel(
>> dataType, width, height, width, bankIndices, bandOffsets
>> );
>> DataBuffer dataBuffer = new DataBufferByte(width * height, numBands);
>> WritableRaster raster = Raster.createWritableRaster(sampleModel,
>> dataBuffer, null);
>> ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB);
>> int[] bits = {8, 8, 8}; // 8 bits per color component (R, G, B)
>> ColorModel colorModel = new ComponentColorModel(cs, bits, false,
>> false, Transparency.OPAQUE, dataType);
>> BufferedImage bufferedImage = new BufferedImage(colorModel, raster,
>> false, null);
>> }
>> }
>>
>>
>> So there are no restrictions on these values. Even if someone extends
>> ComponentSampleModel and divides data into separate bands they can continue
>> to do so.
>
>>I see that none of the code path under this API uses BandedSampleModel.
>
> This discussion is about the possibility of changing that in the future. The
> current change prevents us from implementing those for large images(even by
> simply reusing BandedSampleModel instead of new class), since it includes
> strict limits and the TCK will enforce them. So, if we decide to change it
> later, we’ll also need to update the specification, which means the change
> can’t be backported.
>
>>But that seems nearly impossible. There's too many things in the spec. and
>>implementation that would need revisision.
>
> What things? I don’t think we have any limits, except that we still need to
> implement it. Right now, we don’t define that behavior clearly. So, later,
> the user will get the correct large image when they ask for it, instead of
> getting an error. But the current patch is one of the thing which will
> prevent that, no?
The spec update in question only applies to the pre-defined types.
I see no circumstance in which we'd ever modify the implementation of these.
I actually tried this (meaning BandedSampleModel) months ago now, for the
3BYTE_BGR case which is the one of those with the biggest current constraint.
ie. I changed the implementation of that case and found that printing, Image
I/O and IIRC at least one
other thing I can't remember now assumed the current implementation.
They'd need to be re-worked first. I don't see this ever happening.
If internal code makes assumption, external code likely does too.
If we did add a new pre-defined type that can exceed these limits because it
used a banded raster, then as part
of adding that, updating the spec for this case would be part of that. And that
could never be backported anyway.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2557863299
