View Bug Details

IDProjectCategoryView StatusLast Update
0001947DCP-o-maticBugspublic2023-05-30 00:04
Reporteroverlookmotel Assigned Tocarl  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformMacOSOS XOS Version10.14
Summary0001947: Incorrect cropping in preview with subsampled sources
Description

I have noticed a difference in behavior between 2.14.38 and 2.14.47, which I believe to be a regression.

With subsampled sources, the display of picture in preview pane is slightly inaccurate when cropping and scaling.

Steps to reproduce:

  1. Add a source which is subsampled (I've been using ProResHQ 4:2:2).
  2. Set DCP container to Flat.
  3. Set "Scale" to 1.85.
  4. Set "Crop Right" to a large number which should make the crop line through middle of the picture (e.g. 400).

What you'd expect (and what you get with 2.14.38) is that the active picture fills the whole preview area. But in 2.14.47, there's a thin black line down the right-hand side. No matter what value you set "Crop Right" to, the black line remains there.

Additionally, "Crop Left" and "Crop Right" are only responsive in increments of 2 pixels. i.e. There's no change between Crop left 400 and 401, or 402 and 403.

None of this applies to "Crop Top" and "Crop Bottom", only horizontal crop. And none applies with a 4:4:4 source e.g. ProRes4444 or DCP.

The crop does appear to be performed correctly in the created DCP - there is no black line on the right in the output - it's just the preview in the GUI that's incorrect.

I've tried a few different 4:2:2 files and this behavior appears to be consistent.

I've re-run the same set of steps with the same source file in 2.14.38, and confirmed this behavior is new in 2.14.47. Therefore, I am guessing this regression is somehow related to recent changes to fix a bug in cropping of sub-sampled sources.

Additional Information

Just FYI, the reason I noticed this is that my standard procedure for cropping off letterboxing/pillarboxing is to set "Scale" to 1.85, crop until the picture is filling the whole preview window exactly (i.e. all black is gone) and then reverting "Scale" to "No stretch".

This method is useful because: (1) The black bars will be pure black rather than possibly containing some small noise present in the original source due to imperfect compression and (2) DCP-o-matic then displays the exact active aspect ratio e.g. "Cropped to 1440x1080 (1.33:1)" and I can put that in the DCP name "F-133".

The presence of the black line makes this difficult to do. But I don't know if anyone else would be using this slightly convoluted method, so maybe no-one else is really affected.

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work required

Relationships

related to 0002331 closedcarl Black border around image 

Activities

overlookmotel

2021-10-04 14:21

developer   ~0004572

I noticed that 0001872 has been resolved. Will that have resolved this one too?

If so, is that fix in stable branch, or only 2.15.x?

overlookmotel

2021-10-04 14:22

developer   ~0004573

If you're not sure I can check! Just let me know...

carl

2021-10-04 23:28

administrator   ~0004574

The behaviour of crop only working in 2-pixel increments with (e.g.) YUV420 is intentional, and should be in both 2.14.x and 2.15.x. The things we would need to do to crop in 1-pixel increments in those cases are complicated, and don't seem worth the effort. The thin black line in the view does need fixing, though. I need to check whether it is visible in 2.15.x...

overlookmotel

2021-10-05 14:37

developer   ~0004575

Ah, I didn't realise crop was only possible in 2-pixel increments now.

So I can check the DCPs we've made with odd-numbered crop have come out correct, can you advise: is crop rounded up or down? i.e. if set crop to 5 left, 5 right, does it actually crop 4 left, 4 right, or 6 left, 6 right? (or maybe 4 left, 6 right?)

I've opened a separate issue 0002093 with a related suggestion.

I don't know if that'd also make the black line bug easier to solve.

FYI, accurate crop is quite important in some cases. We regularly receive files which have some encoding artefacts on the edges (e.g. a bright green line 1 pixel wide all the way down right edge of frame). One would set crop right to "1" in such a case to get rid of it. But if DCP-o-matic quietly rounds it down to 0, it won't be cropped off and will be retained in the DCP. I've seen this happen once recently, and couldn't figure out why it wasn't getting cropped off.

carl

2021-10-08 20:30

administrator   ~0004578

It rounds down ... I improved things a bit in 2.15.x so that it tells you what it's going to do (rather than pretending it's going to crop in single pixel increments) but I agree it would be better if the controls only allowed multiples of 2 in these cases.

overlookmotel

2023-05-29 11:33

developer   ~0005701

Sorry for belated response. It appears this is fixed in 2.16.56 (and no doubt many versions before).

This issue can be closed.

carl

2023-05-30 00:04

administrator   ~0005706

Thanks for getting back!

Bug History

Date Modified Username Field Change
2021-04-02 15:19 overlookmotel New Bug
2021-10-04 14:21 overlookmotel Note Added: 0004572
2021-10-04 14:22 overlookmotel Note Added: 0004573
2021-10-04 23:28 carl Note Added: 0004574
2021-10-05 14:37 overlookmotel Note Added: 0004575
2021-10-08 20:30 carl Note Added: 0004578
2022-10-03 23:03 carl Relationship added related to 0002331
2023-05-29 11:33 overlookmotel Note Added: 0005701
2023-05-30 00:04 carl Assigned To => carl
2023-05-30 00:04 carl Status new => resolved
2023-05-30 00:04 carl Resolution open => fixed
2023-05-30 00:04 carl Note Added: 0005706