Image tiling chunk

[svgeesus]

Raised by: Henrik Andersson
Originally raised: 8 Nov 2015

I am proposing a new chunk. The purpose of it is to track how an image
may be repeated (tiled).

An image can be repeated by tiling it to draw it on a larger viewport
without scaling it.

What would need to be tracked is just two flags, duplicated two to
account for x and y separately.

The first flag is if the image can be repeated in the given direction.
The second flag is if the image should be repeated using reflection.

Reflection means that the image will be mirrored every other repetition.

Overall, this only requires four bits, which easily fits in an octet.

[Crissov]

If we do that, PNG could also get …

• a flag for the preferred scaling method: pixelated/blocky or blurred/smooth. Interpolation preference #21
• flags for fitting preference: scale to fill, stretch to fill, crop to fill, tile to fill, pad top/right/bottom/left to fill.
• view boxes for various aspect ratios (possibly with coordinates outside the actual image area).

[Crissov]

This proposal is about using the whole image as a tile that gets repeated to fill an area. PNG files are also frequently used the other way around: as sprite sheets, where only a (rectangular) part of the image is actually being used when it is embedded somewhere. #25 It might be sensible to improve both use cases with the same mechanism.

[randy408]

An image can be repeated by tiling it to draw it on a larger viewport without scaling it.

Android has a "9Patch" npTc chunk: https://ibotpeaches.github.io/Apktool/documentation/#9patch-images
https://android.googlesource.com/platform/frameworks/base/+/56a2301/include/androidfw/ResourceTypes.h

[ace-dent]

While this interests me (see 8x8 here), I'm not sure of the benefits in terms of improved compression or usability.

For small repeating patterns (multiply image):
I'd like to be able to define a single unit with my png bitmap, and then specify the window view size (e.g. 4x2 repeats). However, most patterns are smaller than Deflate's window so the repeated tiles should be well compressed without this added complexity.

For large sprite sheets (divide image):
Rather than specifying the view window as a multiple, I may want to set some divisor(s). e.g. slice my spritesheet up according to 1x wide, 8x high- showing a smaller viewport with a single sprite.

It's not clear how or where this added metadata would solve a problem; these issues have already been addressed by css and other technologies...

[Crissov]

Android include/androidfw/ResourceTypes.h

PNG Extensions

New private chunks that may be placed in PNG images.

Nine-Patch

This chunk specifies how to split an image into segments for scaling.

There are J horizontal and K vertical segments.
These segments divide the image into J*K regions as follows (where J=4 and K=3):

      F0   S0    F1     S1
   +-----+----+------+-------+
 S2|  0  |  1 |  2   |   3   |
   +-----+----+------+-------+
   |     |    |      |       |
   |     |    |      |       |
 F2|  4  |  5 |  6   |   7   |
   |     |    |      |       |
   |     |    |      |       |
   +-----+----+------+-------+
 S3|  8  |  9 |  10  |   11  |
   +-----+----+------+-------+

Each horizontal and vertical segment is considered to be either stretchable (marked by the Sx labels) or fixed (marked by the Fy labels), in the horizontal or vertical axis, respectively.
In the above example, the first is horizontal segment (F0) is fixed, the next is stretchable and then they continue to alternate.
Note that the segment list for each axis can begin or end with a stretchable or fixed segment.

The relative sizes of the stretchy segments indicates the relative amount of stretchiness of the regions bordered by the segments.
For example, regions 3, 7 and 11 above will take up more horizontal space than regions 1, 5 and 9 since the horizontal segment associated with the first set of regions is larger than the other set of regions.
The ratios of the amount of horizontal (or vertical) space taken by any two stretchable slices is exactly the ratio of their corresponding segment lengths.

xDivs and yDivs are arrays of horizontal and vertical pixel indices.
The first pair of Divs (in either array) indicate the starting and ending points of the first stretchable segment in that axis.
The next pair specifies the next stretchable segment, etc.
So in the above example xDiv[0] and xDiv[1] specify the horizontal coordinates for the regions labeled 1, 5 and 9.
xDiv[2] and xDiv[3] specify the coordinates for regions 3, 7 and 11.
Note that the leftmost slices always start at x=0 and the rightmost slices always end at the end of the image.
So, for example, the regions 0, 4 and 8 (which are fixed along the X axis) start at x value 0 and go to xDiv[0] and slices 2, 6 and 10 start at xDiv[1] and end at xDiv[2].

The colors array contains hints for each of the regions.
They are ordered according left-to-right and top-to-bottom as indicated above.
For each segment that is a solid color the array entry will contain that color value; otherwise it will contain NO_COLOR.
Segments that are completely transparent will always have the value TRANSPARENT_COLOR.

The PNG chunk type is npTc.

[henke37]

That's a nice one, but I think it is out of scope for this issue. Please create a new one.