View Issue Details

IDProjectCategoryView StatusLast Update
0001653DCP-o-matic[All Projects] Bugspublic2019-11-04 01:09
Reporteroverlookmotel Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
PlatformMacOSOS XOS Version10.14
Product Version2.14.8 
Target VersionFixed in Version 
Summary0001653: Crop settings ignored when re-encoding from existing DCP
Description

I have an existing DCP which is Flat ratio. I am trying to create a new DCP from it, but cropping the image to 1.33:1 ratio.

DCP-o-matic seems to ignore the crop settings - the resulting DCP has exactly the same image as the original.

This is using DCP-o-matic 2.14.8. I've not tested more recent versions, so I don't know if this may have been fixed already.

Carl, I'll email you the content I'm using and DOM project file, in case it's something specific to the content.

Steps To Reproduce
  • Create new DCP-o-matic project
  • Click Add DCP and import an existing 2K Flat DCP
  • Set Left crop to 279.
  • Set Right crop to 279.
  • Set Scale to to "No Stretch"
  • In viewer, picture is cropped to 1.33 ratio (1440x1080)
  • Make DCP
  • Look at resulting DCP - it's not been cropped, picture still fills 1.85:1 ratio frame

I am not clear on whether the frames are being re-encoded, but just not cropped, or whether the frames are copied rather than re-encoded.

I have additionally tried a few other things to force re-encoding:

  • Changing DCP type - Interop to SMTPE
  • Ticking "Re-encode JPEG2000 data from input"
  • Setting Scale to to 1.33

None of the above have any effect.

What does work is to introduce vertical cropping too. e.g. Left crop = 280, Right crop = 279, Bottom crop = 1. This isn't ideal as it introduces unnecessary scaling, but it's a workaround.

TagsNo tags attached.
Estimated work requiredUndecided

Activities

Carsten

2019-11-03 23:29

manager   ~0003532

Maybe since it's introduction only the re-concode checkbox actually triggers a re-encode?

  • Carsten

overlookmotel

2019-11-03 23:45

reporter   ~0003534

Hi Carsten. I tried ticking that, but it made no difference. Weirdly, just adding 1 line of bottom crop did trigger re-encode and the left and right crop got applied too.

My understanding was that "Re-encode JPEG 2000 data" checkbox was to force re-encode where otherwise it wouldn't happen, but not having it ticked wouldn't disable re-encoding where it has to occur to honour other options e.g. crop, 4K -> 2K, Flat -> Scope. Certainly I know that subtitles do get burned in even without "Re-encode JPEG 2000 data" checked.

Carsten

2019-11-04 01:01

manager   ~0003536

Yes, I know there's a set of parameters that, when changed, trigger recompression. I meant that this may have been messed up with the introduction of the re-encode checkbox.

BTW - at what speed is the conversion happening? If no recompression is taking place, than it should go very quickly.
If it takes long, it may actually be recompressing, but not applying the cropping/scaling parameters.
Doesn't help YOU much with your project to know that, but, it's a different problem.

Currently converting a scope trailer with only left/right cropping applied in 2.14.11 (OSX). It is definitely taking the time to recompress. Let's look at the result...

All correct. At least L/R cropping alone will trigger recompression with cropping in 2.14.11. Can you try a later version?



Carsten

2019-11-04 01:09

manager   ~0003537

Hmm, looks as if the issue is the 'no stretch' being chosen - if I crop AND choose no-stretch, DCP-o-matic IS recompressing, but neither crop nor no stretch is applied.

Or is it possible that 'no-stretch' is 'overriding' crop?

  • Carsten

Issue History

Date Modified Username Field Change
2019-11-03 23:20 overlookmotel New Issue
2019-11-03 23:29 Carsten Note Added: 0003532
2019-11-03 23:45 overlookmotel Note Added: 0003534
2019-11-04 00:25 carl Severity minor => major
2019-11-04 00:25 carl Estimated work required => Undecided
2019-11-04 01:01 Carsten File Added: Bildschirmfoto 2019-11-04 um 01.59.57.png
2019-11-04 01:01 Carsten File Added: Bildschirmfoto 2019-11-04 um 01.59.38.png
2019-11-04 01:01 Carsten File Added: Bildschirmfoto 2019-11-04 um 01.59.12.png
2019-11-04 01:01 Carsten Note Added: 0003536
2019-11-04 01:09 Carsten Note Added: 0003537