Difference: GhostProof (1 vs. 14)

Revision 142017-04-03 - TravisMoore

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Changed:
<
<
The GhostProof project involves using Ghostscript and MuPDF together to provide an interactive color correct proofing tool. Ghostscript will process the input PDF so we get color correct output, and MuPDF will handle the interactive display of that output.
>
>
The GhostProof project involves using Ghostscript and MuPDF together to provide an interactive color correct proofing tool. Ghostscript will process the input PDF so we get color correct output, and MuPDF will handle the interactive display of that output.
  The workflow (for the android app at least) is as follows:

Revision 132016-09-08 - RobinWatts

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 35 to 35
  Edit the paths in Makefile as appropriate for your ndk installation.
Changed:
<
<
And then: make so= (or =make sodebug)
>
>
And then: make so (or make sodebug)
  This should produce a sobin/libgs.so (or sodebugbin/libgs.so).
Added:
>
>
Then run 'arm-linux-androideabi-strip sobin/libgs.so'. If we don't strip the lib fails to start up with a -100 error. No idea why. In any event stripping is probably a good idea.
 

Building MuPDF

Checkout MuPDF from robin's repo (master branch).

Revision 122016-03-03 - FredRossPerry

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 29 to 29
  Check out: android_mupdf_gs_so branch on robin's ghostscript repo
Changed:
<
<
Change directory into gs.
>
>
Change directory into gs.
 
Changed:
<
<
Copy Makefile.android as Makefile (important, as the so targets recursively invoke Makefile).
>
>
Copy Makefile.android as Makefile (important, as the so targets recursively invoke Makefile).
 
Changed:
<
<
Edit the paths in Makefile as appropriate for your ndk installation.
>
>
Edit the paths in Makefile as appropriate for your ndk installation.
 
Changed:
<
<
And then: make so (or make sodebug)
>
>
And then: make so= (or =make sodebug)
 
Changed:
<
<
This should produce a sobin/libgs.so (or sodebugbin/libgs.so).
>
>
This should produce a sobin/libgs.so (or sodebugbin/libgs.so).
 

Building MuPDF

Checkout MuPDF from robin's repo (master branch).

Changed:
<
<
Copy libgs.so from the previous stage to platform/android/jni/libgs.so
>
>
Copy libgs.so from the previous stage to platform/android/jni/libgs.so
 
Changed:
<
<
Do the usual android build, but add SUPPORT_GPROOF=1 to the end of the ndk-build line.
>
>
Do the usual android build, but add SUPPORT_GPROOF=1

to the end of the ndk-build line.

  That's it!
Added:
>
>

Using Android Studio

The Android project contains a Gradle build file that can be used with Android Studio. Note that this is simply a wrapper around the existing NDK makefiles, and they are still required.

First, get the source code and update the subprojects as you normally would.

Then, build the muPDF library with gproof support, like this:
make HAVE_X11=no XCFLAGS="-DSUPPORT_GPROOF"

The first time, launch Android Studio and import the platform/android folder. You'll be asked if you want to set up the gradle wrappers, choose OK to do this. Once this is done, Android Studio will remember this and all you need to do is open it next time.

You may see an error saying that your gradle version is too old. There is a link in the error window you can click to fix this automatically. It's just editing gradle-wrapper.properties with a link to the correct version.

Now, get or build a version of libgs.so that also has gproof support. See http://twiki.ghostscript.com/do/view/MuPDF/GhostProof for details. Copy this file into the JNI folder.

Edit local.properties and specify which version of the NDK to use. Newer versions will work, but version r8e will result in an app that works with our minimum platform.

Now build and run using Android Studio. You should be able to debug the Java code.

You can also do command-line builds using the gradle wrappers (gradlew and gradlew.bat), which are simply scripts that are used by Android Studio when it builds.

 

Using the App

Line: 181 to 203
 

Comments

Deleted:
<
<
<--/commentPlugin-->
 \ No newline at end of file
Added:
>
>

<--/commentPlugin-->

Revision 112015-07-20 - RobinWatts

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 29 to 29
  Check out: android_mupdf_gs_so branch on robin's ghostscript repo
Added:
>
>
Change directory into gs.
 Copy Makefile.android as Makefile (important, as the so targets recursively invoke Makefile).

Edit the paths in Makefile as appropriate for your ndk installation.

Revision 102015-07-20 - RobinWatts

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 15 to 15
  The viewer UI displays a list of separations for each page, and enables them to be turned on and off. If all separations are turned on, then MuPDF will use the color correct rgb representation from the .gprf file. If not, it will form its own (non-color correct) composite from the separations and equivalent cmyk colors given in the .gprf file.
Added:
>
>

Building a GhostProof viewer

For Android

First, you need to a libgs.so. Either you can use a prebuilt one or you can build your own:

Prebuilt libgs.so

http://ghostscript.com/~robin/libgs.so

Building yourself.

Check out: android_mupdf_gs_so branch on robin's ghostscript repo

Copy Makefile.android as Makefile (important, as the so targets recursively invoke Makefile).

Edit the paths in Makefile as appropriate for your ndk installation.

And then: make so (or make sodebug)

This should produce a sobin/libgs.so (or sodebugbin/libgs.so).

Building MuPDF

Checkout MuPDF from robin's repo (master branch).

Copy libgs.so from the previous stage to platform/android/jni/libgs.so

Do the usual android build, but add SUPPORT_GPROOF=1 to the end of the ndk-build line.

That's it!

Using the App

Install MuPDF as built above. Run the app. This will give you the normal file picker. Pick a PDF file. This will give you the standard MuPDF view on the file.

On the top bar, click (+) to go to the 'more' menu. There should be a 'P' icon to the left of the print icon. 'P' is intended to mean 'Proof' - any suggestions for better icons gratefully received. Click 'P' and the app goes into proofing mode.

Actually what happens is that the app writes out a '.gproof' file based upon the current PDF file, and then invokes itself to view that gproof file. When the proofing viewer shuts down, the original viewer deletes the gproof file and continues.

Things to do with the viewer

The viewer is just at proof of concept stage. Lots of work to do on it.

  • The 'P' icon could be replaced by something better.

  • The UI should change when in 'proofing' mode; annotation/searching options etc should be hidden, probably printing too. The 'P' icon should be hidden in proofind mode.

  • The UI should offer a separations view; something like a list of 'swatches' across the top bar that can be enabled/disabled. Too many separations to fit on the screen means the bar should scroll left/right. Somehow we should show separation names; maybe show the names running downwards at 45 degrees from each swatch? Fade the names out as the top bar disappears off the screen. Potentially Different separations on each page.

  • Need to expose a JNI interface to read number of separations, separation names and enable/disable separations etc.

  • Probably need a way to set icc profile options within the MuPDF API?

  • Probably need a way to specify the proofing resolution - when we invoke the proofing mode, we should prompt for the desired resolution. Currently it's hardwired to 300 dpi. If we change the dpi in the .gproof generation, it should follow through all the rest of the stages nicely.

  • The GS device needs work. Performance improvements would be good - potentially we could improve a lot - do some profiles. Equivalent colors don't appear to being produced (for CMYK at least). RGB is generated dumbly, so spots aren't showing up at all at present. ICC profile needs to be output.
 

File formats

There are therefore 2 file formats:

Revision 92015-07-10 - RobinWatts

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 31 to 31
 
2 Version Currently 1
4 Desired resolution for proofing  
4 n = Number of pages Minimum 1
Changed:
<
<
8*n (Width, Height) pairs for each page 4 bytes each
>
>
8*n (Width, Height) pairs for each page (pixels at target resolution) 4 bytes each
 
variable utf-8 encoded filename of PDF file zero terminated

Page data files - .gprf

Revision 82015-06-19 - RobinWatts

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 32 to 32
 
4 Desired resolution for proofing  
4 n = Number of pages Minimum 1
8*n (Width, Height) pairs for each page 4 bytes each
Changed:
<
<
variable utf-8 encoded filename of PDF file
>
>
variable utf-8 encoded filename of PDF file zero terminated
 

Page data files - .gprf

Line: 60 to 60
 
20-27 ICC offset Zero if ICC not present
28-35 Table offset  
36-63 Reserved for future Fill with 0s
Deleted:
<
<
Following the header, we will have the separation mapping information as well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the number of separations specified in the header. Note that some spot colorants may have opacity properties (e.g. clear varnish). This opacity will be described by the alpha term provided with the RGB values. The separation color names are null terminated. An example is shown below where we have S separations including the standard separations.
 
Changed:
<
<
Equivalent RGB value (3 bytes) Equivalent CMYK value (4 bytes) UTF-8 Name (at least 1 byte)
RR GG BB FF 00 00 00 "Cyan"
RR GG BB 00 FF 00 00 "Magenta"
RR GG BB 00 00 FF 00 "Yellow"
RR GG BB 00 00 00 FF "Black"
RR GG BB CC MM YY KK Name of Spot 0
RR GG BB CC MM YY KK Name of Spot 1
>
>
Following the header, we will have the separation mapping information as well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the number of separations specified in the header. Note that some spot colorants may have opacity properties (e.g. clear varnish). This opacity will be described by the alpha term provided with the RGB values. The RGB values are not pre-multipled by the alpha value. The separation color names are null terminated.

An example is shown below where we have S separations including the standard separations.

Equivalent RGB value (4 bytes) Equivalent CMYK value (4 bytes) UTF-8 Name (at least 1 byte)
RR GG BB AA FF 00 00 00 "Cyan"
RR GG BB AA 00 FF 00 00 "Magenta"
RR GG BB AA 00 00 FF 00 "Yellow"
RR GG BB AA 00 00 00 FF "Black"
RR GG BB AA CC MM YY KK Name of Separation 4
RR GG BB AA CC MM YY KK Name of Separation 5
 
... ... ...
Changed:
<
<
RR GG BB CC MM YY KK Name of Spot S-4
>
>
RR GG BB AA CC MM YY KK Name of Separation S-1
 If the ICC offset entry in the header is non-zero, the next part of the file is the ICC profile associated with the RGB data included in the file.

Following the ICC profile data is the tile table. This table contains the index locations of the image tiles. The tiling of the image starts in the lower left indexing to the right (+x) and then up (+y) in chunks of 256x256 with appropriately sized remainders at the image edges. To provide improved compression, each red green and blue channel as well as separation color is individually compressed to provide S+3 separate planes of compressed data for each image tile. In the tile table, the offset locations for each compressed tile location are provided (8 bytes). In the tile table, the individual red, green and blue channel tile locations followed by the separations are provided for the tiles at index [x,y] = [0,0]. The order the separations appear in the table is in the same order as given in the separation color mapping tables. Each table entry is eight bytes. An example table is shown below, where the image has been tiled into W sections along the x direction and H sections along the y direction with S separations:

Revision 72015-06-19 - MichaelVrhel

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 60 to 60
 
20-27 ICC offset Zero if ICC not present
28-35 Table offset  
36-63 Reserved for future Fill with 0s
Changed:
<
<
Following the header, we will have the separation mapping information well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the number of separations specified in the header. Note that some spot colorants may have opacity properties (e.g. clear varnish). This opacity will be described by the alpha term provided with the RGB values. The separation color names are null terminated. An example is shown below where we have S separations including the standard separations.
>
>
Following the header, we will have the separation mapping information as well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the number of separations specified in the header. Note that some spot colorants may have opacity properties (e.g. clear varnish). This opacity will be described by the alpha term provided with the RGB values. The separation color names are null terminated. An example is shown below where we have S separations including the standard separations.
 
Equivalent RGB value (3 bytes) Equivalent CMYK value (4 bytes) UTF-8 Name (at least 1 byte)
RR GG BB FF 00 00 00 "Cyan"

Revision 62015-06-19 - RobinWatts

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Changed:
<
<
This Twiki provides detailed information on the file format that will provide proofing output for overprint, individual separations and color managed viewing as created by Ghostscript for consumption by MuPDF. The format is structured with tiles to enable relatively fast zooming performance in MuPDF and includes an RGB color managed preview, ink levels for individual separations, simple linear mappings from spot levels to RGB and CMYK values as well as an optional ICC profile for the RGB image. The image data is divided into 256x256 tiles, which are compressed. The compression method is defined in the header.
>
>
The GhostProof project involves using Ghostscript and MuPDF together to provide an interactive color correct proofing tool. Ghostscript will process the input PDF so we get color correct output, and MuPDF will handle the interactive display of that output.
 
Changed:
<
<
All multi-byte data is encode as little-endian.
>
>
The workflow (for the android app at least) is as follows:

  • The viewer app is invoked on the input file (postscript, PDF, XPS etc).
  • This file is converted to PDF if it is not already (using Ghostscript and pdfwrite).
  • The converted file is then loaded into the viewer as normal.
  • When the viewer enters 'proofing' mode, it creates a .gproof file from the input pdf file. The viewer then invokes itself again on this .gproof file.
  • The gproof file contains enough information for the viewer to display the correct number of correctly sized pages.
  • As the viewer requests a page to be rendered, MuPDF invokes gs in the background to produce the appropriate .gprf file. This is then read and the page returned.

The viewer UI displays a list of separations for each page, and enables them to be turned on and off. If all separations are turned on, then MuPDF will use the color correct rgb representation from the .gprf file. If not, it will form its own (non-color correct) composite from the separations and equivalent cmyk colors given in the .gprf file.

File formats

There are therefore 2 file formats:

  • .gproof
  • .gprf

Document skeleton files - .gproof

The gproof files are designed to have just enough information in to allow mupdf to mock up pages matching the original PDF file.

Byte Size Content Comments
4 ‘GPRO’ (0x4F525047) File signature
2 Version Currently 1
4 Desired resolution for proofing  
4 n = Number of pages Minimum 1
8*n (Width, Height) pairs for each page 4 bytes each
variable utf-8 encoded filename of PDF file

Page data files - .gprf

This section provides detailed information on the file format that will provide proofing output for overprint, individual separations and color managed viewing as created by Ghostscript for consumption by MuPDF. The format is structured with tiles to enable relatively fast zooming performance in MuPDF and includes an RGB color managed preview, ink levels for individual separations, simple linear mappings from spot levels to RGB and CMYK values as well as an optional ICC profile for the RGB image. The image data is divided into 256x256 tiles, which are compressed. The compression method is defined in the header.

All multi-byte data is encoded as little-endian. All offsets given in the file are offsets from the 0th byte of the File Signature (so if there are multiple pages encoded in a single file, the offsets for the second page start from the second pages header).

  The format consists of five primary parts and they occur in the format in the following order:
  • Header (64 bytes)
Line: 12 to 46
 
  • ICC Profile (Variable # bytes and Optional)
  • Tile Table (Variable # bytes)
  • Tiles (Variable # bytes)
Added:
>
>
 The header details are as follows:
Changed:
<
<
Byte Offset Content Comments
0-3 ‘GSPF’ (0x46505347) File signature
4-5 Version Currently 1
6-7 Compression method of tiles 0x0000
8-11 Width
12-15 Height
16-17 Bits/Channel Currently only 8 supported
18-19 Number of separations Minimum 1
20-27 ICC offset Zero if ICC not present
28-35 Table offset
36-63 Reserved for future Fill with 0s
>
>
Byte Offset Content Comments
0-3 ‘GSPF’ (0x46505347) File signature
4-5 Version Currently 1
6-7 Compression method of tiles 0x0000 (deflated deltas)
8-11 Width  
12-15 Height  
16-17 Bits/Channel Currently only 8 supported
18-19 Number of separations Minimum 1
20-27 ICC offset Zero if ICC not present
28-35 Table offset  
36-63 Reserved for future Fill with 0s
  Following the header, we will have the separation mapping information well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the number of separations specified in the header. Note that some spot colorants may have opacity properties (e.g. clear varnish). This opacity will be described by the alpha term provided with the RGB values. The separation color names are null terminated. An example is shown below where we have S separations including the standard separations.
Changed:
<
<
>
>
Equivalent RGB value (3 bytes) Equivalent CMYK value (4 bytes) UTF-8 Name (at least 1 byte)
RR GG BB FF 00 00 00 "Cyan"
RR GG BB 00 FF 00 00 "Magenta"
RR GG BB 00 00 FF 00 "Yellow"
RR GG BB 00 00 00 FF "Black"
RR GG BB CC MM YY KK Name of Spot 0
RR GG BB CC MM YY KK Name of Spot 1
... ... ...
RR GG BB CC MM YY KK Name of Spot S-4
 
Changed:
<
<
Equivalent RGB value + Alpha (8 Bytes)

*Equivalent CMYK value (8 bytes)*

>
>
If the ICC offset entry in the header is non-zero, the next part of the file is the ICC profile associated with the RGB data included in the file.
 
Changed:
<
<
*UTF-8 Name*
RR GG BB FF FF 00 00 00 Cyan
RR GG BB FF 00 FF 00 00 Magenta
RR GG BB FF 00 00 FF 00 Yellow
RR GG BB FF 00 00 00 FF Black
RR GG BB FF CC MM YY KK Name of spot 1
RR GG BB FF CC MM YY KK Name of spot 2
..... ..... ....
RR GG BB FF CC MM YY KK Name of spot S-4
>
>
Following the ICC profile data is the tile table. This table contains the index locations of the image tiles. The tiling of the image starts in the lower left indexing to the right (+x) and then up (+y) in chunks of 256x256 with appropriately sized remainders at the image edges. To provide improved compression, each red green and blue channel as well as separation color is individually compressed to provide S+3 separate planes of compressed data for each image tile. In the tile table, the offset locations for each compressed tile location are provided (8 bytes). In the tile table, the individual red, green and blue channel tile locations followed by the separations are provided for the tiles at index [x,y] = [0,0]. The order the separations appear in the table is in the same order as given in the separation color mapping tables. Each table entry is eight bytes. An example table is shown below, where the image has been tiled into W sections along the x direction and H sections along the y direction with S separations:
 
Changed:
<
<
If the ICC offset entry in the header is non-zero, the next part of the file is the ICC profile associated with the RGB data included in the file.
>
>
  Tile Offset
Tile[0,0] Offset Red channel
  Offset Green channel
  Offset Blue channel
  Offset Separation 0
  ...
  Offset Separation S-1
Tile[1,0] Offset Red channel
  Offset Green channel
  Offset Blue channel
  Offset Separation 0
  ...
  Offset Separation S-1
... ...
Tile[W-1,0] Offset Red channel
  Offset Green channel
  Offset Blue channel
  Offset Separation 0
  ...
  Offset Separation S-1
Tile[0,1] Offset Red channel
  Offset Green channel
  Offset Blue channel
  Offset Separation 0
  ...
  Offset Separation S-1
... ...
Tile[W-1,H-1] Offset Red channel
  Offset Green channel
  Offset Blue channel
  Offset Separation 0
  ...
  Offset Separation S-1
End Offset end of data
 
Changed:
<
<
Following the ICC profile data is the tile table. This table contains the index locations of the image tiles. The tiling of the image starts in the lower left indexing to the right (+x) and then up (+y) in chunks of 256x256 with appropriately sized remainders at the image edges. To provide improved compression, each red green and blue channel as well as separation color is individually compressed to provide S+3 separate planes of compressed data for each image tile. In the tile table, the offset locations for each compressed tile location are provided (8 bytes). In the tile table, the individual red, green and blue channel tile locations followed by the separations are provided for the tiles at index [x,y] = [0,0]. The order the separations appear in the table is in the same order as given in the separation color mapping tables. Each table entry is eight bytes. An example table is shown below, where the image has been tiled into M sections along the x direction and N sections along the y direction with S separations:
>
>
The only currently defined compression method for the channel data is defined in the header by the value 0x0000. This indicates that the deflate compression method is used on delta encoded image data. The data is compressed on a stream that consists of concatenated rows running from the top left to the bottom right of the image tile.
 
Changed:
<
<
Tile Offset
Offset Red channel [x,y] = [0,0]
Offset Green channel [x,y] = [0,0]
Offset Blue channel [x,y] = [0,0]
Offset Separation 0 [x,y] = [0,0]
...
Offset Separation S-1 [x,y] = [0,0]
Offset Red channel [x,y] = [1,0]
Offset Green channel [x,y] = [1,0]
Offset Blue channel [x,y] = [1,0]
Offset Separation 0 [x,y] = [1,0]
....
Offset Separation S-1 [x,y] = [1,0]
....
Offset Red channel [x,y] = [M-1,N-1]
Offset Green channel [x,y] = [M-1,N-1]
Offset Blue channel [x,y] = [M-1,N-1]
Offset Separation 0 [x,y] = [M-1,N-1]
....
Offset Separation S-1 [x,y] = [M-1,N-1]
>
>
For the i'th entry in the offset table, the data is assumed to run to the (i+1)th entry in the table (hence the need for the final end of data offset).
 
Changed:
<
<
The only currently defined compression method for the tiles is defined in the header by the value 0x0000. This indicates that the deflate compression method is used on delta encoded image data. The data is compressed on a stream that consists of concatenated rows running from the top left to the bottom right of the image tile.
>
>
If the length of the channels data thus computed is 0, the data is assumed to be all zeros.
  -- Michael Vrhel - 2015-06-16

Revision 52015-06-19 - MichaelVrhel

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Changed:
<
<
This Twiki provides detailed information on the file format that will provide proofing output for overprint, individual separations and color managed viewing as created by Ghostscript for consumption by MuPDF. The format is structured with tiles to enable relatively fast zooming performance in MuPDF and includes an RGB color managed preview, ink levels for individual separations, simple linear mappings from spot levels to RGB and CMYK values as well as an optional ICC profile for the RGB image. The image data is divided into 256x256 chunks, which are each compressed. The compression method is defined in the header.
>
>
This Twiki provides detailed information on the file format that will provide proofing output for overprint, individual separations and color managed viewing as created by Ghostscript for consumption by MuPDF. The format is structured with tiles to enable relatively fast zooming performance in MuPDF and includes an RGB color managed preview, ink levels for individual separations, simple linear mappings from spot levels to RGB and CMYK values as well as an optional ICC profile for the RGB image. The image data is divided into 256x256 tiles, which are compressed. The compression method is defined in the header.
  All multi-byte data is encode as little-endian.
Line: 14 to 14
 
  • Tiles (Variable # bytes)
The header details are as follows:
Changed:
<
<
Byte Offset Content Comments
0-3 ‘GSPF’ (0x46505347) file signature
4-5 Version Currently 1
6-7 Compression method of blocks 0x0000
8-11 Height
12-15 Width
16-17 Bits/Channel Currently only 8 supported
18-19 Number of separations Minimum 1
20-27 ICC offset Zero if ICC not present
28-35 Table offset
36-63 Reserved for future Fill with 0s
Following the header, we will have the separation mapping information well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the Number of separations specified in the header. The separation color names are null terminated. An example is shown below where we have S separations including the standard separations.
>
>
Byte Offset Content Comments
0-3 ‘GSPF’ (0x46505347) File signature
4-5 Version Currently 1
6-7 Compression method of tiles 0x0000
8-11 Width
12-15 Height
16-17 Bits/Channel Currently only 8 supported
18-19 Number of separations Minimum 1
20-27 ICC offset Zero if ICC not present
28-35 Table offset
36-63 Reserved for future Fill with 0s
 
Changed:
<
<
Equivalent RGB value Equivalent CMYK value UTF8 Name
RR GG BB FF 00 00 00 Cyan
RR GG BB 00 FF 00 00 Magenta
RR GG BB 00 00 FF 00 Yellow
RR GG BB 00 00 00 FF Black
RR GG BB CC MM YY KK Name of spot 1
RR GG BB CC MM YY KK Name of spot 2
..... ..... ....
RR GG BB CC MM YY KK Name of spot S-4
>
>
Following the header, we will have the separation mapping information well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the number of separations specified in the header. Note that some spot colorants may have opacity properties (e.g. clear varnish). This opacity will be described by the alpha term provided with the RGB values. The separation color names are null terminated. An example is shown below where we have S separations including the standard separations.

Equivalent RGB value + Alpha (8 Bytes)

*Equivalent CMYK value (8 bytes)*

*UTF-8 Name*

RR GG BB FF FF 00 00 00 Cyan
RR GG BB FF 00 FF 00 00 Magenta
RR GG BB FF 00 00 FF 00 Yellow
RR GG BB FF 00 00 00 FF Black
RR GG BB FF CC MM YY KK Name of spot 1
RR GG BB FF CC MM YY KK Name of spot 2
..... ..... ....
RR GG BB FF CC MM YY KK Name of spot S-4
  If the ICC offset entry in the header is non-zero, the next part of the file is the ICC profile associated with the RGB data included in the file.
Changed:
<
<
Following the ICC profile data, is the tile table. This table contains the index locations of the image tiles. The tiling of the image starts in the lower left indexing to the right (+x) and then up (+y) in chunks of 256x256 with appropriately sized remainders at the image edges. The individual red, green and blue channel tile locations are provided first for each x, y index. The separation colors are then provided, with a separation given for all the x, y tile indices prior to the next separation. The order the separations appear in the table is in the same order as given in the separation color names and separation color mapping tables. Each table entry is eight bytes, providing an offset and a size for the compressed tile. An example table is shown below, where the image has been tiled into M sections along the x direction and N sections along the y direction with K separations:
>
>
Following the ICC profile data is the tile table. This table contains the index locations of the image tiles. The tiling of the image starts in the lower left indexing to the right (+x) and then up (+y) in chunks of 256x256 with appropriately sized remainders at the image edges. To provide improved compression, each red green and blue channel as well as separation color is individually compressed to provide S+3 separate planes of compressed data for each image tile. In the tile table, the offset locations for each compressed tile location are provided (8 bytes). In the tile table, the individual red, green and blue channel tile locations followed by the separations are provided for the tiles at index [x,y] = [0,0]. The order the separations appear in the table is in the same order as given in the separation color mapping tables. Each table entry is eight bytes. An example table is shown below, where the image has been tiled into M sections along the x direction and N sections along the y direction with S separations:

Tile Offset
Offset Red channel [x,y] = [0,0]
Offset Green channel [x,y] = [0,0]
Offset Blue channel [x,y] = [0,0]
Offset Separation 0 [x,y] = [0,0]
...
Offset Separation S-1 [x,y] = [0,0]
Offset Red channel [x,y] = [1,0]
Offset Green channel [x,y] = [1,0]
Offset Blue channel [x,y] = [1,0]
Offset Separation 0 [x,y] = [1,0]
....
Offset Separation S-1 [x,y] = [1,0]
....
Offset Red channel [x,y] = [M-1,N-1]
Offset Green channel [x,y] = [M-1,N-1]
Offset Blue channel [x,y] = [M-1,N-1]
Offset Separation 0 [x,y] = [M-1,N-1]
....
Offset Separation S-1 [x,y] = [M-1,N-1]

The only currently defined compression method for the tiles is defined in the header by the value 0x0000. This indicates that the deflate compression method is used on delta encoded image data. The data is compressed on a stream that consists of concatenated rows running from the top left to the bottom right of the image tile.

 
Deleted:
<
<
Offset Size
Offset Red channel [x,y] = [0,0] Size Red channel [x,y] = [0,0]
Offset Green channel [x,y] = [0,0] Size Green channel [x,y] = [0,0]
Offset Blue channel [x,y] = [0,0] Size Blue channel [x,y] = [0,0]
Offset Red channel [x,y] = [1,0] Size Red channel [x,y] = [1,0]
... ...
Offset Blue channel [x,y] = [M-2,N-1] Size Blue channel [x,y] = [M-2,N-1]
Offset Red channel [x,y] = [M-1,N-1] Size Red channel [x,y] = [M-1,N-1]
Offset Green channel [x,y] = [M-1,N-1] Size Green channel [x,y] = [M-1,N-1]
Offset Blue channel [x,y] = [M-1,N-1] Size Blue channel [x,y] = [M-1,N-1]
Offset Separation 0 [x,y] = [0,0] Size Separation 0 [x,y] = [0,0]
.... ....
Offset Separation 0 [x,y] = [M-1,N-1] Size Separation 0 [x,y] = [M-1,N-1]
Offset Separation 1 [x,y] = [0,0] Size Separation 1 [x,y] = [0,0]
.... ....
Offset Separation 1 [x,y] = [M-1,N-1] Size Separation 1 [x,y] = [M-1,N-1]
.... ....
Offset Separation K-1 [x,y] = [0,0] Size Separation K-1 [x,y] = [0,0]
.... ....
Offset Separation K-1 [x,y] = [M-1,N-1] Size Separation K-1 [x,y] = [M-1,N-1]
  -- Michael Vrhel - 2015-06-16

Comments

Revision 42015-06-18 - MichaelVrhel

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 6 to 6
  All multi-byte data is encode as little-endian.
Changed:
<
<
The format consists of six primary parts and they occur in the format in the following order:
>
>
The format consists of five primary parts and they occur in the format in the following order:
 
  • Header (64 bytes)
Changed:
<
<
  • Spot Mappings (Variable [Number of separations*8 bytes])
  • Spot Names (Variable # bytes)
>
>
  • Spot Mappings and Names (Variable # bytes)
 
  • ICC Profile (Variable # bytes and Optional)
  • Tile Table (Variable # bytes)
Changed:
<
<
  • Tiles (Variable size # bytes)
>
>
  • Tiles (Variable # bytes)
 The header details are as follows:
Changed:
<
<
Byte Offset Content Comments
0-3 ‘GSPF’ (47535046h) file signature
4-5 Version Currently 1
6-7 Compression method of blocks 0x0000
8-11 Height
12-15 Width
16-17 Bits/Channel Currently only 8 supported
18-19 Number of separations Minimum 1
20-23 ICC offset Zero if ICC not present
24-27 Table offset
28-63 Reserved for future Fill with 0s
Following the header we will have the separation mapping information. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The size of the separation mapping information is [Number of separations*8 bytes] where Number of separations is defined in the header. An example is shown below where we have K separations including the standard separations.
>
>
Byte Offset Content Comments
0-3 ‘GSPF’ (0x46505347) file signature
4-5 Version Currently 1
6-7 Compression method of blocks 0x0000
8-11 Height
12-15 Width
16-17 Bits/Channel Currently only 8 supported
18-19 Number of separations Minimum 1
20-27 ICC offset Zero if ICC not present
28-35 Table offset
36-63 Reserved for future Fill with 0s
Following the header, we will have the separation mapping information well as the separation names. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The number of table entries is defined by the Number of separations specified in the header. The separation color names are null terminated. An example is shown below where we have S separations including the standard separations.
 
Changed:
<
<
Equivalent RGB value padded to 4 bytes Equivalent CMYK value Comments
00 RR GG BB FF 00 00 00 Equivalent colors for Cyan
00 RR GG BB 00 FF 00 00 Equivalent colors for Magenta
00 RR GG BB 00 00 FF 00 Equivalent colors for Yellow
00 RR GG BB 00 00 00 FF Equivalent colors for Black
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 1
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 2
..... ..... .....
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color K-4
Following the color mappings, we have the separation color names null terminated. The names are encoded in UTF-8.
>
>
Equivalent RGB value Equivalent CMYK value UTF8 Name
RR GG BB FF 00 00 00 Cyan
RR GG BB 00 FF 00 00 Magenta
RR GG BB 00 00 FF 00 Yellow
RR GG BB 00 00 00 FF Black
RR GG BB CC MM YY KK Name of spot 1
RR GG BB CC MM YY KK Name of spot 2
..... ..... ....
RR GG BB CC MM YY KK Name of spot S-4
 
Deleted:
<
<
UTF8 Name
Cyan
Magenta
Yellow
Black
Name of spot 1
Name of spot 2
.....
Name of spot K-4
 If the ICC offset entry in the header is non-zero, the next part of the file is the ICC profile associated with the RGB data included in the file.

Following the ICC profile data, is the tile table. This table contains the index locations of the image tiles. The tiling of the image starts in the lower left indexing to the right (+x) and then up (+y) in chunks of 256x256 with appropriately sized remainders at the image edges. The individual red, green and blue channel tile locations are provided first for each x, y index. The separation colors are then provided, with a separation given for all the x, y tile indices prior to the next separation. The order the separations appear in the table is in the same order as given in the separation color names and separation color mapping tables. Each table entry is eight bytes, providing an offset and a size for the compressed tile. An example table is shown below, where the image has been tiled into M sections along the x direction and N sections along the y direction with K separations:

Revision 32015-06-17 - MichaelVrhel

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Changed:
<
<
This Twiki provides detailed information on the file format that will provide proofing output for overprint, individual separations and color managed viewing as created by Ghostscript for consumption by MuPDF. The format is structured with tiles to enable relatively fast zooming performance in MuPDF and includes an RGB color managed preview, ink levels for individual separations, simple linear mappings from spot levels to RGB and CMYK values as well as an optional ICC profile for the RGB image. The image data is divided into 256x256 chunks, which are each gzipped.
>
>
This Twiki provides detailed information on the file format that will provide proofing output for overprint, individual separations and color managed viewing as created by Ghostscript for consumption by MuPDF. The format is structured with tiles to enable relatively fast zooming performance in MuPDF and includes an RGB color managed preview, ink levels for individual separations, simple linear mappings from spot levels to RGB and CMYK values as well as an optional ICC profile for the RGB image. The image data is divided into 256x256 chunks, which are each compressed. The compression method is defined in the header.
  All multi-byte data is encode as little-endian.
Line: 15 to 15
 
  • Tiles (Variable size # bytes)
The header details are as follows:
Changed:
<
<
Byte Offset Content Comments
0-3 ‘GSPF’ (47535046h) file signature
4-5 Version Currently 1
6-11 Reserved Fill with 0s
12-15 Height
16-19 Width
20-21 Bits/Channel Currently only 8 supported
22-23 Number of separations Four or more
24-27 ICC offset Zero if ICC not present
28-31 Table offset
32-64 Reserved for future Fill with 0s
Following the header we will have the spot mapping information. At minimum, we should have mappings for Cyan, Magenta, Yellow and Black. The size of the spot mapping information is [Number of separations*8 bytes] where Number of separations is defined in the header. An example is show below:
>
>
Byte Offset Content Comments
0-3 ‘GSPF’ (47535046h) file signature
4-5 Version Currently 1
6-7 Compression method of blocks 0x0000
8-11 Height
12-15 Width
16-17 Bits/Channel Currently only 8 supported
18-19 Number of separations Minimum 1
20-23 ICC offset Zero if ICC not present
24-27 Table offset
28-63 Reserved for future Fill with 0s
Following the header we will have the separation mapping information. Most commonly, we would have mappings for Cyan, Magenta, Yellow and Black. However, it is possible that there may only be one or two separations. This can occur in mono-tone or duo-tone cases for example. The size of the separation mapping information is [Number of separations*8 bytes] where Number of separations is defined in the header. An example is shown below where we have K separations including the standard separations.
 
Changed:
<
<

Equivalent RGB value

front padded to 4 bytes

Equivalent CMYK value Comments
00 RR GG BB FF 00 00 00 Equivalent colors for Cyan
00 RR GG BB 00 FF 00 00 Equivalent colors for Magenta
00 RR GG BB 00 00 FF 00 Equivalent colors for Yellow
00 RR GG BB 00 00 00 FF Equivalent colors for Black
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 1
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 2
..... ..... .....
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color N
Following the spot color mappings, we have the spot color names. The names are encoded in UTF-8. An example is given below:
>
>
Equivalent RGB value padded to 4 bytes Equivalent CMYK value Comments
00 RR GG BB FF 00 00 00 Equivalent colors for Cyan
00 RR GG BB 00 FF 00 00 Equivalent colors for Magenta
00 RR GG BB 00 00 FF 00 Equivalent colors for Yellow
00 RR GG BB 00 00 00 FF Equivalent colors for Black
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 1
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 2
..... ..... .....
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color K-4
Following the color mappings, we have the separation color names null terminated. The names are encoded in UTF-8.
 
Added:
>
>
UTF8 Name
Cyan
Magenta
Yellow
Black
Name of spot 1
Name of spot 2
.....
Name of spot K-4
If the ICC offset entry in the header is non-zero, the next part of the file is the ICC profile associated with the RGB data included in the file.

Following the ICC profile data, is the tile table. This table contains the index locations of the image tiles. The tiling of the image starts in the lower left indexing to the right (+x) and then up (+y) in chunks of 256x256 with appropriately sized remainders at the image edges. The individual red, green and blue channel tile locations are provided first for each x, y index. The separation colors are then provided, with a separation given for all the x, y tile indices prior to the next separation. The order the separations appear in the table is in the same order as given in the separation color names and separation color mapping tables. Each table entry is eight bytes, providing an offset and a size for the compressed tile. An example table is shown below, where the image has been tiled into M sections along the x direction and N sections along the y direction with K separations:

Offset Size
Offset Red channel [x,y] = [0,0] Size Red channel [x,y] = [0,0]
Offset Green channel [x,y] = [0,0] Size Green channel [x,y] = [0,0]
Offset Blue channel [x,y] = [0,0] Size Blue channel [x,y] = [0,0]
Offset Red channel [x,y] = [1,0] Size Red channel [x,y] = [1,0]
... ...
Offset Blue channel [x,y] = [M-2,N-1] Size Blue channel [x,y] = [M-2,N-1]
Offset Red channel [x,y] = [M-1,N-1] Size Red channel [x,y] = [M-1,N-1]
Offset Green channel [x,y] = [M-1,N-1] Size Green channel [x,y] = [M-1,N-1]
Offset Blue channel [x,y] = [M-1,N-1] Size Blue channel [x,y] = [M-1,N-1]
Offset Separation 0 [x,y] = [0,0] Size Separation 0 [x,y] = [0,0]
.... ....
Offset Separation 0 [x,y] = [M-1,N-1] Size Separation 0 [x,y] = [M-1,N-1]
Offset Separation 1 [x,y] = [0,0] Size Separation 1 [x,y] = [0,0]
.... ....
Offset Separation 1 [x,y] = [M-1,N-1] Size Separation 1 [x,y] = [M-1,N-1]
.... ....
Offset Separation K-1 [x,y] = [0,0] Size Separation K-1 [x,y] = [0,0]
.... ....
Offset Separation K-1 [x,y] = [M-1,N-1] Size Separation K-1 [x,y] = [M-1,N-1]
 -- Michael Vrhel - 2015-06-16

Comments

Revision 22015-06-17 - MichaelVrhel

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

GhostProof

Line: 14 to 14
 
  • Tile Table (Variable # bytes)
  • Tiles (Variable size # bytes)
The header details are as follows:
Deleted:
<
<
 
Changed:
<
<
Byte Offset
Content Comments
0-3 ‘GSPF’ (47535046h) file signature
4-5 Version Currently 1
6-11 Reserved Fill with 0s
12-15 Height
16-19 Width
20-21 Bits/Channel Currently only 8 supported
22-23 Number of separations Four or more
24-27 ICC offset Zero if ICC not present
28-31 Table offset
32-64 Reserved for future Fill with 0s
>
>
Byte Offset Content Comments
0-3 ‘GSPF’ (47535046h) file signature
4-5 Version Currently 1
6-11 Reserved Fill with 0s
12-15 Height
16-19 Width
20-21 Bits/Channel Currently only 8 supported
22-23 Number of separations Four or more
24-27 ICC offset Zero if ICC not present
28-31 Table offset
32-64 Reserved for future Fill with 0s
Following the header we will have the spot mapping information. At minimum, we should have mappings for Cyan, Magenta, Yellow and Black. The size of the spot mapping information is [Number of separations*8 bytes] where Number of separations is defined in the header. An example is show below:
 
Deleted:
<
<
Following the header we will have the spot mapping information. At minimum, we should have mappings for Cyan, Magenta, Yellow and Black. The size of the spot mapping information is [Number of separations*8 bytes] where Number of separations is defined in the header. An example is show below:
 

Equivalent RGB value

front padded to 4 bytes

Changed:
<
<
Equivalent CMYK value Comments
0 RGB FF 00 00 00 Equivalent colors for Cyan
0 RGB 00 FF 00 00 Equivalent colors for Magenta
0 RGB 00 00 FF 00 Equivalent colors for Yellow
0 RGB 00 00 00 FF Equivalent colors for Black
0 RGB CMYK Equivalent colors for Spot Color 1
0 RGB CMYK Equivalent colors for Spot Color 2
..... ..... .....
0 RGB CMYK Equivalent colors for Spot Color N

Following the spot color mappings, we have the spot color names. The names are encoded in UTF-8. An example is given below:

>
>
Equivalent CMYK value Comments
00 RR GG BB FF 00 00 00 Equivalent colors for Cyan
00 RR GG BB 00 FF 00 00 Equivalent colors for Magenta
00 RR GG BB 00 00 FF 00 Equivalent colors for Yellow
00 RR GG BB 00 00 00 FF Equivalent colors for Black
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 1
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color 2
..... ..... .....
00 RR GG BB CC MM YY KK Equivalent colors for Spot Color N
Following the spot color mappings, we have the spot color names. The names are encoded in UTF-8. An example is given below:
  -- Michael Vrhel - 2015-06-16

Revision 12015-06-16 - MichaelVrhel

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="WebHome"

GhostProof

This Twiki provides detailed information on the file format that will provide proofing output for overprint, individual separations and color managed viewing as created by Ghostscript for consumption by MuPDF. The format is structured with tiles to enable relatively fast zooming performance in MuPDF and includes an RGB color managed preview, ink levels for individual separations, simple linear mappings from spot levels to RGB and CMYK values as well as an optional ICC profile for the RGB image. The image data is divided into 256x256 chunks, which are each gzipped.

All multi-byte data is encode as little-endian.

The format consists of six primary parts and they occur in the format in the following order:

  • Header (64 bytes)
  • Spot Mappings (Variable [Number of separations*8 bytes])
  • Spot Names (Variable # bytes)
  • ICC Profile (Variable # bytes and Optional)
  • Tile Table (Variable # bytes)
  • Tiles (Variable size # bytes)
The header details are as follows:

Byte Offset

Content Comments
0-3 ‘GSPF’ (47535046h) file signature
4-5 Version Currently 1
6-11 Reserved Fill with 0s
12-15 Height
16-19 Width
20-21 Bits/Channel Currently only 8 supported
22-23 Number of separations Four or more
24-27 ICC offset Zero if ICC not present
28-31 Table offset
32-64 Reserved for future Fill with 0s

Following the header we will have the spot mapping information. At minimum, we should have mappings for Cyan, Magenta, Yellow and Black. The size of the spot mapping information is [Number of separations*8 bytes] where Number of separations is defined in the header. An example is show below:

Equivalent RGB value

front padded to 4 bytes

Equivalent CMYK value Comments
0 RGB FF 00 00 00 Equivalent colors for Cyan
0 RGB 00 FF 00 00 Equivalent colors for Magenta
0 RGB 00 00 FF 00 Equivalent colors for Yellow
0 RGB 00 00 00 FF Equivalent colors for Black
0 RGB CMYK Equivalent colors for Spot Color 1
0 RGB CMYK Equivalent colors for Spot Color 2
..... ..... .....
0 RGB CMYK Equivalent colors for Spot Color N

Following the spot color mappings, we have the spot color names. The names are encoded in UTF-8. An example is given below:

-- Michael Vrhel - 2015-06-16

Comments

<--/commentPlugin-->
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2014 Artifex Software Inc