NAV
shell

Watermarking with Payload

When to use payload

Payload is generally not the default IMATAG approach but it can be useful in certain circumstances.

The default IMATAG approach

For most use-cases, IMATAG doesn't use a payload, each watermarked media is assigned a unique watermarking key that needs to be transmitted to IMATAG for detection.

This has the advantage of being simple to manage (1 watermark = 1 registration) and therefore reducing the risk for errors. It is also very secure, like a one-time pad in cryptography. Unfortunately, it is only suitable if the number of watermarks per original file is reasonably low (less than ~100). As the number of watermarks goes up, managing/storing/transmitting the image registrations files can become an issue and the detection times would start to go up significantly.

The Payload approach

For this purpose IMATAG also offers a "payload" approach that reuses the same watermarking key for multiple watermarked versions of the same original media but adds an integer payload that can go as high as 65535 (16 bits). When using this approach you will typically only have to transmit one registration file or secret per original and detection will return the value of this payload if (and only if) a watermark is found. On the other hand, this approach requires you to manage payloads manually and to know ahead of time the approximate number of watermarks you expect for a given original file.

When using the "payload" approach you have to provide three pieces of information:

More information on how to choose these settings is provided below.

Payload in the context of blind watermarking

If you use video blind watermarking you might want to use the same watermarking key/secret for different original videos and only change the payload. This allows you to simplify the detection further by sending only one secret for multiple original videos. The wording in recommendations below focus on the use case where the watermarking key/secret changes for each original but they are still valid if you use the same secret for multiple videos.

How to assign payloads

We recommend reserving payload #0 for your own use, especially for media types that use registration files (Images, PDFs...). You can use it to do an initial watermark and generate the registration file you are going to send to the IMATAG API. This allows you to discard all other registration files, which might be particularly convenient if you distribute the processing.

For the watermarks that you are going to send out, you only need to make sure that the payloads are unique for a given secret. If you already have IDs that would be unique to each watermark and are small enough, you can use those, otherwise you can simply assign them sequentially.

Unlike many payload-based watermarking techniques, you don't need to add error-correcting codes or generally space payloads out in the hamming space. If a watermark is "found", it means the p-value is lower than 1e-12 for this specific secret and payload. There is no higher risk of making a 1 bit error or generally detecting a payload that is "close" in terms of hamming-distance.

How to choose the secret

The secret is a string of alphanumeric characters plus "_", "-" and ".". It must be less than 256 character in length. You need to make sure you remember it in order to keep it fixed while the payload changes. As the name implies, it should be kept secret and shouldn't be easy to guess, as this could potentially allow for targeted attacks on this specific watermark if an attacker were also able to gain access to the software.

How to choose the maximum payload

This is quite easy if you know exactly how many watermarks you will produce for a given secret, but if you don't, you might be tempted to just set it to the maximum allowed, but we recommend against it as this will negatively impact robustness. This is because we have to compensate the increased risk of false positive that come with more detections and making more detections than necessary (say 65535 instead of 127) means that we might miss detections that are just on the edge. We recommend making your best guess at the number of watermarks and adding a margin for error based on your uncertainty. If you end-up underestimating the maximum payload, please see the next section.

The maximum payload cannot exceed 65535 (16 bits). If this is not sufficient for your use-case, please see the next section.

What to do if you have reached the maximum payload

If you have reached the maximum payload, either because you underestimated how many you would need or because you need more than 65535 watermarks per original, all is not lost! You just need to change the secret and you can start again from payload 0. Feel free to take this opportunity to re-estimate the maxpayload and use a different one for this new secret.
Never change the maxpayload without changing the secret, you would run the risk of decoding the wrong payload!

Please note that there is a higher risk of confusion as you will be reusing the same payload multiple times with different secrets. You may also have different maxpayload for different secrets. For this reason, you must take extra care to associate all three parameters (payload, secret, maxpayload) to each watermark.

This means that you will need to register / detect each secret-maxpayload pair independently, even if the original image is the same.

shell