Hi all,
While I was verifying a DCP made with Clipster, I had the following errors for all the frames in the DCP.
Frame (number) has an invalid JPEG2000 codestream (invalid number of transform levels 5).
Could you please tell if this error is neglectable and I can succesfully ingest and play this DCP.
P.S. It is a 4K DCP which is restored from an old film shot by 35mm.
Thanks.
DCP-o-matic Verification Error
-
IoannisSyrogiannis
- Posts: 349
- Joined: Mon Nov 13, 2017 8:40 pm
- Location: Iceland
Re: DCP-o-matic Verification Error
From first read, what springs to mind is that 2K cinema JPEG2000 files have five transform levels, while 4K have six.
So, if the resolution is 4K, the frame was encoded in a non-DCP-compatible way that would (probably) match a 2K DCI encoding. I would expect that the same would go for the entirety of the stream and not only a frame.
I understand that Clipster has a lot non-automated parameters to be configured. So, I imagine that the person that made the DCP could have inadvertently mixed the 2K/4K encoding format. Meaning, creating JPEG2000 images of 4K resolution, compressing in a "2K" fashion. That might have also resulted in larger files or a higher degree of quantization.
(Personal note: I always envied people that could get to "play" with expensive Clipster systems (but the company was since acquired), so I was having contempt for Clipster DCPs that were badly made.
)
So, if the resolution is 4K, the frame was encoded in a non-DCP-compatible way that would (probably) match a 2K DCI encoding. I would expect that the same would go for the entirety of the stream and not only a frame.
I understand that Clipster has a lot non-automated parameters to be configured. So, I imagine that the person that made the DCP could have inadvertently mixed the 2K/4K encoding format. Meaning, creating JPEG2000 images of 4K resolution, compressing in a "2K" fashion. That might have also resulted in larger files or a higher degree of quantization.
(Personal note: I always envied people that could get to "play" with expensive Clipster systems (but the company was since acquired), so I was having contempt for Clipster DCPs that were badly made.
)-
ulastheplatypus
- Posts: 3
- Joined: Sat Jan 24, 2026 1:45 pm
Re: DCP-o-matic Verification Error
Thanks a lot! It is first time I've seen such an error and still not sure if it is okay to ingest and play or not. I think it will be best to try ingesting this DCP to a server to see the result.
-
IoannisSyrogiannis
- Posts: 349
- Joined: Mon Nov 13, 2017 8:40 pm
- Location: Iceland
Re: DCP-o-matic Verification Error
Just out of curiosity. If the DCP is 4K, what is its total size and duration? (Flat or Scope could make a difference as well, if you don't mind disclosing.)
-
Carsten
- Posts: 3056
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: DCP-o-matic Verification Error
The #transform levels usually causes no issues with servers to my knowledge. It was a common issue between 2k and 4k DCPs for a while.
-
ulastheplatypus
- Posts: 3
- Joined: Sat Jan 24, 2026 1:45 pm
Re: DCP-o-matic Verification Error
It is 176 mins, Flat and 298 GB in size.
-
IoannisSyrogiannis
- Posts: 349
- Joined: Mon Nov 13, 2017 8:40 pm
- Location: Iceland
Re: DCP-o-matic Verification Error
That's 226 Mbps, which is 1,09 bits/pixel for 24fps. Which is not unusual and probably a setting that takes into account the limit for many of the media blocks and ICPs out there.
I wonder how that specific DCP would compare with an extra resolution layer, if the bandwidth was to be kept.
There is no easy answer to that, but guessing would say "with an extra resolution layer, the same bandwidth/frame size would have hold more detail".
Would that be distinguishable? Would that have created artifacts that would have had made a difference on a big screen? Most probably not to the cinema-goer. Maybe to some off-screen analysis, comparing the two distinct cases.
It would be nice to let us know how it went with the server ingesting/validating!
I wonder how that specific DCP would compare with an extra resolution layer, if the bandwidth was to be kept.
There is no easy answer to that, but guessing would say "with an extra resolution layer, the same bandwidth/frame size would have hold more detail".
Would that be distinguishable? Would that have created artifacts that would have had made a difference on a big screen? Most probably not to the cinema-goer. Maybe to some off-screen analysis, comparing the two distinct cases.
It would be nice to let us know how it went with the server ingesting/validating!