[OpenJDK 2D-Dev] BufferedImage.getTileGridXOffset() not compliant with its specification?

[Martin Desruisseaux]

Hello Sergey

Le 22/02/2020 à 21:01, Sergey Bylokhov a écrit :

> I am not sure that the problem is in the implementation, probably the 
> word
> "origin" in the "Returns the x offset of the tile grid relative to the 
> origin,"
> should be clarified.
>
> Is the "origin" refer the original bufferedimage or the sub-image.
> Note the spec of the getSubimage():
>      * The returned {@code BufferedImage} shares the same
>      * data array as the original image.


Thanks for your reply. Yes the meaning of "origin" in this sentence is 
not clear. But the fact that the two images share the same data array is 
invisible from all (as far as I know) RenderedImage / BufferedImage API, 
with the current implementation of BufferedImage.getTileGridX/YOffset() 
methods being the only exception I'm aware of (this exception would not 
exist if implementation of those two methods were conform to their 
specification). We could said that the data array sharing is an 
implementation details (admittedly an important one). Usually we have to 
go down to SampleModel and DataBuffer API before the layout details of 
data arrays become visible. What current 
BufferedImage.getTileGridX/YOffset() implementations are doing is to 
expose (by mistake I think) a SampleModel details.

My understanding is that the origin cited in the specification is the 
origin of current image, not the origin of a parent or source image. 
Otherwise given that RenderedImage.getSources() can return an arbitrary 
amount of source (or parent) images, which one would define the origin?

But anyway, while I agree that the first part of the sentence has 
ambiguity because of different possible interpretations of "origin", the 
second part of the sentence is much clearer:

      i.e., the X coordinate of the upper-left pixel of tile (0, 0).
    (Note that tile (0, 0) may not actually exist.)

With this sentence, getTileGridXOffset() can be related to getMinX(), 
getMinTileX() and getNumXTiles() as below:

  * The pixel coordinates of the pixel in the upper-left corner of the
    image is (minX, minY).
  * The tile indices of the tile in the upper-left corner of the image
    is (minTileX, minTileY).
  * Suppose that (minTileX, minTileY) = (-2, 0). The tile at indices (0,
    0) is located two tiles on the right of the tile in the upper-left
    corner. Consequently the pixel coordinate in the upper-left corner
    of that tile is greater than minX by 2*tileWidth.

So we can write:

    tileGridXOffset = minX - minTileX * tileWidth

(Note: Java Advanced Imaging was also doing this mathematics if my 
memory serves me right.)

In BufferedImage implementation, getMinTileX() and getNumTileX() are 
hard-coded to 0 and 1 respectively, while getMinX() and getTileWidth() 
delegate to raster methods. If we substitute variables in above formulas 
by BufferedImage implementations we get:

    tileGridXOffset = raster.getMinX() - 0 * raster.getTileWidth()

which simplify as:

    tileGridXOffset = raster.getMinX()

Where raster.getMinX() always returns 0 in BufferedImage case, 
consistently with BufferedImage javadoc which said getTileGridXOffset() 
value is always zero.

     Regards,

         Martin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200222/94559921/attachment.htm>