How to check the transparency survived the download and not just the export
Ask Vizard Agent to download the delivered file back from its own link and check the alpha channel there, rather than checking the file it just rendered. Transparency can be lost at four separate points — the encoder, the container, the upload and the delivery link — and only the last of those is what the recipient actually opens.
What is the short version?
You render an overlay with transparency, it looks right, you send the link. The person at the other end opens it and the subject is sitting on a black rectangle, because something between your renderer and their download re-encoded it.
- Ask Vizard Agent for a format that genuinely carries alpha.
- Ask it to fetch the file back from the link and check it there.
- Ask for the master packaged so nothing re-encodes it.
What do you need before you start?
The overlay and a clear idea of where it is going. Vizard Agent chooses the export format from the destination, and an overlay for a web page, an editing timeline and a messaging app do not all survive the same container.
- The overlay. With its alpha, as rendered.
- Where it is going. Timeline, web page, another tool.
- Who opens it. Their software decides what works.
- Whether size matters. Lossless alpha files are large.
- A fallback need. A flat preview is often wanted too.
What do you type into Vizard Agent?
Ask Vizard Agent about the received file rather than the produced one. It is a small distinction in wording and it is the entire subject of the job: the render itself is almost never the place where transparency actually gets lost.
Prompt
Variants worth knowing:
- "When it arrives, not when it renders." The whole point.
- "Download it back from the link." The check that matters.
- "So nothing converts it." Packaging, not just format.
What does Vizard Agent actually do?
Here is the Vizard Agent sequence on a real transparent overlay that lost its alpha twice on the way to delivery. Each step narrows down which hop was responsible, because "the transparency is gone" is a single symptom with four quite different possible causes behind it.
- Exports the overlay in a format meant to carry transparency.
- Checks why that export did not keep the alpha channel.
- Confirms which transparent formats the encoder actually supports.
- Re-exports with the correct alpha flag set.
- Inspects the muxer's own output before the compression stage.
- Checks the codec's alpha options specifically.
- Tries a lossless mode to see whether compression is the culprit.
- Exports a master in a container that carries real transparency.
- Downloads the file back from the delivery link and checks it.
- Packages the master so the delivery path cannot transcode it.
Step nine is the check nobody runs. Every other test in the list examines a file you still have; this one examines the file the recipient gets, and those are different objects the moment anything in between decides to re-encode.
Step five is how you find the hop. If the muxer's output has alpha and the compressed file does not, the compression stage is responsible; if neither has it, the problem is upstream. Checking only the final file tells you it failed, not where.
Step ten is the difference between a fix and a recurrence. A correct file sent through a path that transcodes will be broken again next time, so the packaging has to prevent the conversion rather than survive it by luck.
What does the result look like?
A file that is still transparent when it is opened. Vizard Agent tells you which format it used, which hop had been stripping the alpha, and confirms the check was run on the downloaded copy rather than the local one.
When does this not work well?
Some destinations simply do not carry transparency at all. A platform that re-encodes everything on upload will flatten your overlay whatever Vizard Agent sends it, and the honest answer there is to composite the overlay before delivery rather than to keep fighting the format.
- Platforms that always re-encode. Composite first instead.
- Formats with no alpha at all. Common delivery defaults.
- Very large lossless masters. Size limits force compression.
- Chat and messaging apps. They flatten almost everything.
- Embedded players. They may ignore alpha even when it is present.
How do you fix a result that came back wrong?
Say where you opened it. The very same file can be transparent in one application and solid black in another, so the place you saw the failure happen is the single most useful fact you can hand Vizard Agent to work from.
- "It is black in my editor." The container is changed for that tool.
- "It is black from the link." The delivery path is transcoding it.
- "It works locally but not for them." The received copy is tested.
- "The file is too big." A compressed format that keeps alpha is tried.
How does Vizard Agent compare to doing it yourself?
By hand you check the render, see the transparency, and consider the job done. The failure is reported by somebody else, days later, and by then you have no way of knowing which of the four hops changed the file.
| By hand | Vizard Agent | |
|---|---|---|
| What gets checked | The file you rendered | The file that comes back |
| Locating the failure | Guesswork | Hop by hop, muxer then codec |
| The format | Whatever the tool offers | Chosen for the destination |
| Delivery | Upload and hope | Packaged against transcoding |
| Recurrence | Every time | The path is fixed, not the file |
Common questions
Where is alpha usually lost? Most often at upload or delivery. Vizard Agent checks each hop separately.
Why check the downloaded copy? Because that is the file your recipient opens. It may not be the one you made.
Which format should I use? It depends on the destination. Vizard Agent picks one that carries alpha there.
Is a lossless file necessary? Not usually. Vizard Agent tries compressed alpha formats first.
What if the platform re-encodes everything? Then composite before delivery. Vizard Agent will tell you when that is the case.
Can it test in my editor? It can produce the container your editor wants and confirm the alpha is present.
Why does it look fine in my player? Some players fake it. Vizard Agent checks the file, not the preview.
Can I have a flat version too? Yes, and it is worth having alongside the transparent master.
Does compression destroy alpha? Some modes do. Vizard Agent checks the codec's alpha options specifically.
What about file size? Transparent masters are large. Vizard Agent reports the size before you send it.
Can it check an existing file? Yes. Send it and Vizard Agent will say whether the alpha is there.
Will the colours change? They can, when alpha is mishandled. That is a related but separate check.
How do I stop this happening again? Fix the delivery path, not the file. Vizard Agent packages for that.
What if I only need it for the web? Then the format choice is narrower, and Vizard Agent picks accordingly.