Surviving Earth chromatic aberration?

[Jonathan Greer]

It seems the film Surviving Earth may have a similar chromatic aberration problem on certain server / projectors as the Brutalist:
Brutalist Chromatic Aberration - Film-Tech Forums

(we also had a similar issue with Babylon, and other cinemas with Mission Impossible 7)
I didn't test the film myself, but the projectionist who did reported:
"When checking Surviving Earth in Cinema 2 today, there was a green hue that was most noticeable on the characters' faces when they moved. I tested another DCP and re-loaded the film a couple of times, but couldn't seem to recreate the issue.
It looked very similar to the issue we had with the Brutalist a while back"

So, I'm wondering if anyone else has seen this?
-and flagging that there may be this issue with this film on certain setups - we have a doremi showvault & Christie CP2220 in the cinema the film was tested.
The distributor says the film has screened elsewhere without issue, but this could happen if it only affects some servers / projectors (intermittently) and not others.
As I understand it, if it is the same issue it will only affect the 4K version of the film, not a 2K version, so I'll see if we can receive the film in 2K if possible.
I'm not working the next two days, but I'll direct the other projectionists to this thread in case anyone has any updates.

[Jonathan Greer]

The distributor has responded to say a 2K version of the film would require a full remaster of the Feature DCP, so this may not be an option.
If we encounter the problem, does anyone know if ejecting the film then restarting from the same point would clear it?

[Marco Giustini]

From the document Carsten linked:

https://www.isdcf.com/wp-content/uploads/2024/01/MeetingNotes20231108vPOSTED.pdf

What’s the “fix”? • The content will need to validated and/or re-encoded to constrain the J2C bitstream

It looks like you don't need a 2K DCP, you need a properly encoded 4K DCP

SCR-20260423-bdgn.jpg

[Ryan Gallagher]

From the document Carsten linked:

https://www.isdcf.com/wp-content/uploads/2024/01/MeetingNotes20231108vPOSTED.pdf

It looks like you don't need a 2K DCP, you need a properly encoded 4K DCP

Yikes, that is far worse than I was imagining it looking like.

[Marcel Birgelen]

Well, that's the problem with those complex compression algorithms like JPEG2000... For years, studios and labs have used libraries that never had any big issues and suddenly someone upgrades their pipeline to a new version and those issues start to pop up, since content with those issues did not exist until then, nobody was able to test it.

Still, those studios validate their JPEG2000 stream and come to the conclusion: Everything conforms to the JPEG 2K standards... Unfortunately, those ASIC-optimized early decoding solutions don't and since much of the decompression is done in ASICs, it's increasingly hard to solve the issues in software. Also, most affected servers have been abandoned by those same manufacturers years ago... Unfortunately, DCI has painted itself into a corner. Would this be open source, then your problem would probably be solved via a simple software patch... Welcome to DCI-hell.

Meanwhile, I'll buy a bunch of strong sunglasses, in order to survive Earth's Chromatic Aberration...

[Harold Hallikainen]

I think the issue is in ASIC JPEG 2K decoders. More recent servers have moved the decoding to an FPGA which can be updated in the field. I also understand this occurs more on 4k content than 2k content.

[Ioannis Syrogiannis]

[...]a green hue that was most noticeable on the characters' faces when they moved.[...]

What I can't wrap my head around is the "when they moved" part. JPEG2000 uses intra-frame compression, there is no direct connection between one frame and the other, where movement manifests, on encoding nor decoding. So, how comes movement has an effect on that artefact?

The 2023 problem mentioned on the ISDCF document is describing DSP100 and DSS200 (the Cat.862 media block). While in this case, we have a Showvault (IMB).

If I haven't read what you all write about ASIC decoders, I would imagine that the problem has its root in formatting, more than decoding. So, does anyone have any pointers, any insight to share on what is the problem here and why it manifests in the way it does?

[Marcel Birgelen]

There is no inter-frame compression in JPEG2000. Yet, as soon as a JPEG2000 decompression state machine goes into "unexplored territory" it's very hard to predict what the visual result is. If, for example, it suddenly forgets to flush every image after the other and starts to "bitblt" information over existing data, the results might be "interesting" and look like there is an interframe-issue while there cannot be one.

As for the ASIC decoders: Those where the first one out there and what's inside the ASICs cannot be software updated, contrary to FPGA-based designs, where the FPGA can be reprogrammed with new software. It's just a hunch that it primarily affects the ASIC decoders, but it seems to affect mostly the older media blocks out there.

I guess the solution lies with the studios/labs producing those DCPs, as Dolby, who seem to own most if not all the affected servers is not likely to come up with a solution for hardware that has been EOS for a while. The labs should work closely with their integrator partners that set-up the compression pipeline.

At least one issue has been clearly defined, analysed and workaround exists, it's described here. It doesn't seem to be clear if there are "more legacy issues", but at least this one should be fixable at the lab's end.

[Jim Cassedy]

I've had a report, from someone who knows what they're looking at, that this is occurring
in several scenes of the HDR version of THE DEVIL WEARS PRADA II in the auditorium
here. I haven't had time to sit for any extended length of time to check this out myself,
but I trust the person who mentioned it to me.
> HAS ANYONE ELSE HAD REPORTS OF THIS ? (I'm guessing not, since I'm sure
somebody here would have mentioned it by now) I suppose I could try to re-boot the
HDR, but that's a major task between shows because the Barcoguys suggest I run the
HDR calibration routine after a re-boot, and that takes some time.

UPDATE/EDIT: I went and watched about 10min of the movie, and what I saw was not
exactly like, or as pronounced as, the picture Marco originally posted. What I'm seeing
is not a 'fringing', but a slightly bluish/greenish shift that is mostly visible in the skin-tones.
I was told that this was mostly happening in interior scenes, and the scenes I personally
saw it in were several scenes where all the actors are sitting around a big 'boardroom'
style table having a meeting. ( I'm not really familiar with the movie, so I can't tell
you exactly where in the movie this was. I know where it was in our PLAYLIST, but
not where it was in the D-W-P-2 CPL. I've got to do some work early Thurs morning
before the theater opens, and I may try to pin down exact scenes, time-wise, if I can
work it into my busy morning. The effect is not as pronounced as in Marco's picture,
and it was more of a facial color shifting, than a fringe- - and, quite honestly, if I wasn't
actually paying extra attention looking for it, I might not have noticed it. But, it's one
of those things where once you do notice it, you can't un-see it.

[Marco Giustini]

Unlikely but wondering if it could have been a bad case of blue screen! (random pic from the ethernet)

Maybe the HDR process is enhancing that? My understanding on HDR workflow is that there is a baseline generated by a software and then a colourist sits down in front of an HDR screen and tweaks it to their taste. Giving the limited amount of Barco HDR right now I wonder whether maybe this version didn't receive enough attention?

maxresdefault.jpg