0001653: Crop settings ignored when re-encoding from existing DCP - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0001653	DCP-o-matic	Bugs	public	2019-11-03 23:20	2023-09-01 21:45

Reporter	overlookmotel	Assigned To	carl
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	fixed
Platform	Mac	OS	OS X	OS Version	10.14
Product Version	2.14.8

Summary	0001653: 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.
Tags	No tags attached.

Branch
Estimated weeks required
Estimated work required	Undecided

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 developer ~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? Bildschirmfoto 2019-11-04 um 01.59.57.png (223,049 bytes) Bildschirmfoto 2019-11-04 um 01.59.57.png (223,049 bytes) Bildschirmfoto 2019-11-04 um 01.59.38.png (227,878 bytes) Bildschirmfoto 2019-11-04 um 01.59.38.png (227,878 bytes) Bildschirmfoto 2019-11-04 um 01.59.12.png (209,278 bytes) Bildschirmfoto 2019-11-04 um 01.59.12.png (209,278 bytes)

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

overlookmotel 2019-12-20 10:05 developer ~0003667	Was this fixed in 2.14.14? Maybe "Fix incorrect images when cropping without stretch in some cases" in the changelog was referring to this?

carl 2019-12-23 23:00 administrator ~0003681	It's certainly plausible that it's the same bug; let's be optimistic, and see what happens!

overlookmotel 2020-01-05 13:01 developer ~0003699	I think this is fixed. I haven't tested on the original DCP that I had a problem with, but had to crop another DCP from 1.85 to 1.33 today and it worked fine.

carl 2020-01-05 23:17 administrator ~0003700	Good news... thanks for the note!

Date Modified	Username	Field	Change
2019-11-03 23:20	overlookmotel	New Bug
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
2019-12-20 10:05	overlookmotel	Note Added: 0003667
2019-12-23 23:00	carl	Assigned To	=> carl
2019-12-23 23:00	carl	Status	new => resolved
2019-12-23 23:00	carl	Resolution	open => fixed
2019-12-23 23:00	carl	Note Added: 0003681
2020-01-05 13:01	overlookmotel	Note Added: 0003699
2020-01-05 23:17	carl	Note Added: 0003700
2023-09-01 21:45	carl	Status	resolved => closed