Bitmap dimensions for RenderBitmap when saving a signature to file

If you want to output the signature image only (i.e. without the biometric data) then the bitmap dimensions can be as small or as large as is practical for your purposes.
If you make the image too small the signature will not be legible. If you make it too large the inking may look rough at the edges.

If you want to include the biometric information in the signature image file (using the RenderEncodeData flag of RenderBitmap) then you need to ensure that the dimensions are large enough.
Typically a bitmap size of 150 x 100 should give you plenty of space to encode the average signature and the size of the output file should be less than 3Kb.

The minimum number of pixels required to encode a signature is: 2 * (12 + number of bytes).

The number of bytes varies, depending on the device. Generally, there are 4 bytes each for each of:

• stroke Id
• x coordinate
• y coordinate
• up/down status

In addition:

• if the device provides timing information, there will be 4 bytes for time
• if the device provides pressure, there will be 4 bytes for pressure

Given a device with a constant reporting rate (the current STU pads all generate 200 pen points per second), and knowing the number of bytes of pen data per point,
it would be possible to make a rough estimate of the number of bytes of biometric data per second of signing. The pen data invariably makes up the bulk of the signature data
but there are other factors involved and there is a certain amount of compression within the stream store which will reduce the number of bytes to be encoded.

In the example below taken from our standard CaptureImage.js the bitmap is 300 x 150 = 45,000 pixels and this should be more than ample for encoding most signatures.
 

filename = "sig.png"; 
flags = 0x1000 | 0x80000 | 0x400000; //SigObj.outputFilename | SigObj.color32BPP | SigObj.encodeData 
rc = sigCtl.Signature.RenderBitmap(filename, 300, 150, "image/png", 0.5, 0xff0000, 0xffffff, 0.0, 0.0, flags );

 
The amount of biometric data within a signature can however vary substantially depending on the length of the signature (amount of inking) and its speed of execution.

If the same signature is written more slowly it will generate more data because the pen still outputs the same number of points per second (200 on an STU tablet), regardless of how fast the signature is written.

If you are using an eSeal then a much larger bitmap is required because the eSeal image is encoded along with the signature data.
The bitmap therefore needs to be big enough for the eSeal image and the signature data together.

Here is some guidance on calculating an adequate image size (pixel dimensions) when using an eSeal.

Assumptions made for these calculations are:

1. You want to render 32-bit pixel colour (using the RenderColor32BPP flag)
2. The signature data itself requires 15,000 pixels (this is a fairly high estimate)
3. Roughly 2 pixels are required to encode one byte of your eSeal image (this is an approximate guideline)  
    

Here are two examples:
 

 
Using a JPG or compressed PNG or a smaller bit depth should substantially help at reducing the size requirement for the output image.
Alternatively you can increase the size (number of pixels) of the requested bitmap to provide more space to encode within it.

Please note however that if you want to encode the biometric data within the signature image (using the RenderEncodeData flag) then you should not use a compressed image format (such as JPG or compressed PNG) because it will corrupt the biometric data.