Index
- Getpic stitcher lite
- TilePic reader
- TilePic stitcher(GUI & CLI)
- Parameter retrieval (batch-file)
- Changelog
- What is TilePic anyway?
- TilePic file format header
Getpic stitcher lite
| Name: | Getpic stitcher lite |
| Author: | Rob Verhoeven |
| Version: | 1.1 |
| Date: | 15-03-2016 |
| License: | GNU Lesser General Public License |
| OS: | MS Windows (32 bit) |
| Programming environment: | Visual Studio 2013 |
| Description: | Small program to build a Jpeg from a Jpeg tiles, using a GUI a Windows environment. These tiles are accessed from an online source as Jpeg tiles from a TilePic file, which are accessible through a web based 'getpic' script. The parameters for the TilePic file and online location are read from an online XML or JSON file. |
| Available at: | http://sourceforge.net/projects/tilepicreader/ |
| 3rd Party dependencies: | Newtonsoft Json.NET |
| Screenshot(s): |  |
TilePic reader
| Name: | TilePic reader |
| Author: | Rob Verhoeven |
| Version: | 2.4 |
| Date: | 21-06-2011 |
| License: | GNU Lesser General Public License |
| OS: | MS Windows (32 bit) |
| Programming environment: | Delphi 2007 |
| Description: | Small program to extract the contents of a TilePic file through a GUI in a Windows environment. |
| Available at: | http://sourceforge.net/projects/tilepicreader/ |
| Notes: | Only handles TilePics of version 10 (the only version, to my knowledge). |
| Currently supports TilePics made up out of BMP, JPEG, PNG or TIF. Can easily be extended to handle any image type implemented in Delphi that descends from TGraphic. | |
| Some applicable file extensions: tpc, tjp, tpg, ttx | |
| Contains a self-made procedure for converting Modified UTF-8 to UTF-8. | |
| 3rd Party dependencies: | Delphi Unicode Label Nikolaj Lynge Olsson (included, free software) |
| ImageFileLib 1.16 (without JPEG and JasPerLib) Michael Vinther (available at above url, semi-free software [refer to the package's own documentation for the conditions]) |
|
| Screenshot(s): |  |
TilePic stitcher
| Name: | TilePic 'getpic' Stitcher | |||
| Author: | Rob Verhoeven | |||
| Version: | 2.4 | |||
| Date: | 21-06-2011 | |||
| License: | GNU Lesser General Public License | |||
| OS: | MS Windows (32 bit) | |||
| Programming environment: | Delphi 2007 | |||
| Description: | Small program to build a Jpeg from a Jpeg tiles, using either a GUI or CLI in a Windows environment. These tiles can be either local or online files, e.g. Jpeg tiles from a TilePic file, accessible through the (web based) 'getpic' script. | |||
| Available at: | http://sourceforge.net/projects/tilepicreader/ | |||
| 3rd Party dependencies: | CCR Exif v1.1.2 Chris Rolliston (open source) |
|||
| TGJPGCommentInfoP 1.0 Thomas Goetz (open source) |
||||
| RegExp Studio v0.952 (open source) |
||||
| Screenshot(s): |
|
Parameter retrieval (batch file)
| Name: | GpsMkIni |
| Author: | Robert J. Holmgren |
| Version: | 1.0 |
| Date: | 19-05-2011 |
| License: | GNU Lesser General Public License |
| OS: | MS Windows (32 bit) |
| Programming environment: | DOS (MS Windows) batch file |
| Description: | Its purpose is to generate an initialization file, with all required parameters, for TilePic stitcher. |
| Available at: | http://sourceforge.net/projects/tilepicreader/ |
| 3rd Party dependencies: | IrfanView |
| cUrl |
|
| Paths to the executables of the aforementioned dependencies need to be set within GpsMkIni.bat. |
Changelog
Getpic stitcher lite v1.1 (15-03-2016)
- Added JSON support.
Getpic stitcher lite v1.0 (27-08-2013)
- Creation with XML support.
TilePic reader/stitcher v2.4 (21-06-2011)
- Restructured Stitcher program architecture (under the hood).
- Improved Stitcher GUI with tabs, for easier use.
- Added functionality to Stitcher to stitch both online and offline tiles, that are indexed either by tile number or by row/column number.
- Restructured the format for ini-files (not backwards compatible; batch file is still designed for v2.3).
- Added progress bars to the Stitcher (both GUI and CLI).
TilePic reader/stitcher v2.3 (25-05-2011)
- Added infrastructure to the Reader and Stitcher to cope with TJpegImage's problem in dealing with jpeg graphics with a height of 1 pixel.
- Small fix in Stitcher (CLI version) with regard to dealing with paths in the ini-file.
TilePic reader/stitcher v2.2 (19-05-2011)
- Restructured Delphi project: Reader and Stitcher in one project group.
- Inadvertently introduced bug in notation of boolean values in the ini-file (resolved in v2.3).
- Restructuring of Stitcher GUI, now with menu.
- Form colours in Reader and Stitcher hardcoded, to be independent of Windows' colour scheme.
- Added CLI version for Stitcher.
- Switched to CCR Exif for including exif-information in jpegs.
- Creation of batch file.
TilePic reader/stitcher v2.1 (07-06-2010)
- Undocumented
TilePic stitcher v2.0 (15-05-2009)
- Creation of Stitcher.
TilePic reader v1.0
- Creation of Reader.
What is TilePic anyway?
“TilePic is a file format developed by the Berkeley Digital Library Project that is designed to store tiled data of arbitrary type in a hierarchical, indexed format in order to provide fast retrieval. This format was influenced by the Kodak FlashPix format and is based in part on the GridPix format developed by the Tertiary Disk Project at UC Berkeley.”Taken from the TilePic homepage
See also:
- UC Berkeley CalPhotos and their collection of TilePics
- GISlite / TileZoom Viewer from UC Berkeley
- CollectiveAccess.org and their TilePic wiki page
TilePic file format header
Taken from the TilePic homepage./* * All of the numeric data, including the "magic number" are stored * in the file most-significant byte first. * * file size field description * byte in * offset bytes * * 0 4 magic magic number == "TPC\n" * 4 4 headerSize size of file header in bytes (40) * 8 4 imageWidth width (x) of largest image in base units * 12 4 imageHeight height (y) of largest image in base units * 16 4 tileWidth width of lowest tiles in base units * 20 4 tileHeight height of lowest tiles in base units * 24 4 nTiles number of tiles stored in the file * 28 2 nLayers number of layers of tiles * 30 2 scale scale factor between layers (typically 2) * 32 4 attribSize size of space used to store attributes * 36 4 nAttribs number of attributes stored in file * 40 (nTiles+1)*4 (tileIndex) offsets of the start of each tile in order * followed by offset of start of attributes * 44+nTiles*4 tileIndex[0]-(44+nTiles*4) [optional filler] * tileIndex[0] tileIndex[1]-tileIndex[0] data for tile "1" * tileIndex[1] tileIndex[2]-tileIndex[1] data for tile "2" * ... * tileIndex[tileNo-1] tileIndex[tileNo]-tileIndex[tileNo-1] * data for tile "tileNo" * tileIndex[tileNo] attribSize null separated attribute data * * Note: There may optionally be uninterpreted filler data between * the end of the header and the start of the first tile. Applications * are neither required to interpret nor pass on this information. This * space may exist to align the start of the tile data on a sector * boundary, but applications should not count on such alignment. * * The tile data is stored contiguously and in order from the first to last * tile. The tiles are numbered 1 to tileNo, starting with the upperleft * tile in the smallest layer and proceeding across, then down, then to the * next larger layer. So for example, if the image size is 1011x765 and * the tilesize is 256x256 and the scale is 2, and there are four layers, * the tile order would be: * * scaled * layer size scale * * layer 1: 1 127x96 8x * * layer 2: 2 253x192 4x * * layer 3: 3 4 506x383 2x * 5 6 * * layer 4: 7 8 9 10 1011x765 1x * 11 12 13 14 * 15 16 17 18 * * Note that the layer sizes are rounded up to the nearest integer. * * The data to be tiled may be raster or vector data. The tiling is done * in more or less the same way with slight differences. In each case, * there is a base unit of dimension whose type and scale is not important * to the tiling process (although that information can be stored as text * attributes for application processing). * * For raster data, the base unit corresponds to one cell of the lowest layer * (highest resolution) data. For image data this would be a single pixel. * Higher layers are assumed to represent aggregations or inteprolations of * the lower levels with each level aggregating cells in scale^2 chunks. * For example, if the lowest layer was a black and white scanned image, * the higher levels might be grayscale images of increasing depth. Or, if * the bottom layer was a color image, the upper layers could use color * averaging or median color to pick the colors for higher layers. The * exact aggregation function used is not constrained or specified by the * tilepic format except that rate of aggregation must match the specified * scale factor. It is even possible for the tile data format to change * from one level to another, for example with the bottom layer tiles * being GIFs, while higher layers are JPEGs. It is up to the application * to keep track of and deal with these issues * * For vector data, the tiling works in a similar fashion except that the * scale units do not change as you rise through the hierarchy. Instead, * the tile sizes change by the scale factor with each layer to cover * more "ground units" at each layer while the level of detail drops. * So, if the tiles were to hold vector data of rivers and coastlines, * the level of detail might decrease as you move towards higher layers. * Similarly if it held city data, the smaller cities might be omitted * as you zoom out. Or for stellar data, the dimmer stars and galaxies * might be omitted as you zoom out. * * The TilePics format neither specifies nor cares what format the tile * data is in. That is left up to the application to determine. * Similarly it does not specify whether partial tiles (on the right and * bottom edges) are padded to the full tile size or truncated to the * minimum number or rows and columns required. Thus either the * application must know these conventions, or (preferably) the tile data * should include sufficient header information to determine its storage * format and size. * * The last tile is immediately followed in the file by the attribute * data. The attributes are stored as contigous null-terminated ASCII-7 * or modified UTF-8 (UNICODE) strings of the form: * * name1=value1\0name2=value2\0...nameN=valueN\0 * * Each "name=value" substring including the last one is terminated by * a single null character. (There should be exactly nAttribs nulls in * the attribSize bytes used to store the attributes.) If UNICODE * strings are used, they should be encoded with the same modified UTF-8 * encoding used by Java such that embedded nulls in the value strings * are stored as 0xc0 0x80. Only 16-bit Unicode values are supported * as for Java. Attributes are for use by the applications and are * uninterpreted within the basic format. * * TilePic files cannot be larger than 4GB in size due to the use of * 32-bit unsigned integers as file offsets. However some systems cannot * handle files larger than 1GB or 2GB, so files larger than 1GB may * not be portable anyways. For datasets larger than 1GB or for data which * is extensively mosaiced, we recommend considering using the TileSource * data tiling approach instead. */