View Bug Details

IDProjectCategoryView StatusLast Update
0002681DCP-o-maticBugspublic2024-01-09 20:30
Reporteroverlookmotel Assigned Tocarl  
Status resolvedResolutionfixed 
PlatformMac OSOS XOS Version10.13
Product Version2.16.70 
Target Version2.16.71 
Summary0002681: Alpha channel not rendered correctly in ProRes4444 files

I've noticed this for a long time, but only just getting around to making a repro case.

When DOM is given a ProRes4444 file with alpha channel, DOM appears to ignore the alpha channel. This results in blocky graphics and text where smoothing of the edges relies on the alpha channel.

Probably it's bad practice to deliver a master without alpha channel flattened, but nonetheless it's not uncommon to find on end credits and other graphics (e.g. white text on a transparent background).

I guess it's arguable that DOM shouldn't pay attention to the alpha channel, because that raises the question of what colour DOM should render transparent as. However, the standard in most editing software is to render transparent as black, so I don't think it'd be surprising to users if DOM did the same.

Steps To Reproduce

Open a ProRes4444 file with alpha channel in DCP-o-matic. The result is immediately visible in the preview. The output in DCP is identical to the preview.

I'll post a repro case shortly.

TagsNo tags attached.
Estimated weeks required
Estimated work requiredSmall


related to 0002564 resolvedcarl Strange white line down right hand side of PNG 



2023-12-08 19:48

developer   ~0006129

Repro case:

This contains:

  • Source: Short ProRes4444 file
  • DOM project: DCP-o-matic project creating DCP from the ProRes4444
  • DCP (inside DOM project): Resulting DCP

When viewing the source ProRes in e.g. VLC or Quicktime, it appears as a white circle with soft blurry edges. The DCP renders it as a larger circle with hard, blocky edges. My assumption is that this is the image contained in the video's YUV channels, without taking into account the alpha channel.


2023-12-08 19:52

developer   ~0006130

PS: Same effect occurs with other image formats which support alpha channels e.g. TIFFs. However, it's far less of a problem with stills, as you'll spot it immediately. A graphic buried somewhere in a feature-length video is much easier to miss.


2023-12-08 19:54

developer   ~0006131

Here's a TIFF with transparency, if it's useful for testing: (112,245 bytes)


2023-12-10 22:52

administrator   ~0006133

Done, needs tests to be run.


2023-12-12 14:05

administrator   ~0006143

Thanks for another great bug report!

@carl fixed in b4a306418f70cd0f43f1b91a9bb96b1714c0fa25 and fbaade900b1479fafe54bbbe904cf8483a577e94


2023-12-12 18:24

developer   ~0006144

Thank you Carl!


2023-12-29 18:41

developer   ~0006170

Has this made it into a release yet? We have a couple of films with this problem that we need to make DCPs from, so would be a good opportunity to check the fix.

If you're on holiday Carl, don't tear yourself away from the turkey! We can work around it other ways for now, and there'll be other opportunities to test the fix no doubt.


2023-12-31 19:36

administrator   ~0006173

@overlookmotel I just uploaded 2.16.71 with this fix in, thanks for testing!


2024-01-03 20:27

developer   ~0006189

Confirmed it works on one the ProRes4444 HQ files we have received recently with an alpha channel.

There is one small oddity: If you create a project in DOM 2.14.x using a source with an alpha channel, when you open that project in 2.16.71, the alpha channel does not get recognised, and "premultiply" does not happen. i.e. result is same as before this fix. I guess something in metadata.xml indicates the presence of an alpha channel, but that key isn't present in a DOM 2.14.x project file.

I don't think that really matters much! Not many people will be switching between 2.14.x and 2.16.x willy nilly. Just mentioning it as I happened to notice it.


2024-01-03 21:24

administrator   ~0006190

Right, when the content is examined a suitable video filter is inserted into chain if the source has an alpha channel. We could force re-examination of 2.14.x projects in 2.16.x but that feels a little like a sledgehammer to crack a nut (and might cause other problems I guess).


2024-01-04 16:28

developer   ~0006194

Yes, I don't think the sledgehammer is necessary!

Bug History

Date Modified Username Field Change
2023-12-08 19:42 overlookmotel New Bug
2023-12-08 19:48 overlookmotel Note Added: 0006129
2023-12-08 19:52 overlookmotel Note Added: 0006130
2023-12-08 19:54 overlookmotel Note Added: 0006131
2023-12-08 19:54 overlookmotel File Added:
2023-12-08 21:36 carl Status new => acknowledged
2023-12-08 21:36 carl Target Version => 2.16.71
2023-12-08 21:36 carl Estimated work required => Undecided
2023-12-09 19:32 carl Branch => 2681-alpha
2023-12-09 19:32 carl Estimated work required Undecided => Small
2023-12-09 19:32 carl Assigned To => carl
2023-12-09 19:32 carl Status acknowledged => in progress
2023-12-10 22:52 carl Note Added: 0006133
2023-12-11 13:07 carl Status in progress => tests running
2023-12-12 14:05 carl Status tests running => resolved
2023-12-12 14:05 carl Resolution open => fixed
2023-12-12 14:05 carl Note Added: 0006143
2023-12-12 18:24 overlookmotel Note Added: 0006144
2023-12-29 18:41 overlookmotel Note Added: 0006170
2023-12-31 19:36 carl Note Added: 0006173
2024-01-03 20:27 overlookmotel Note Added: 0006189
2024-01-03 21:24 carl Note Added: 0006190
2024-01-04 16:28 overlookmotel Note Added: 0006194
2024-01-09 20:30 carl Relationship added related to 0002564