View Bug Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001947 | DCP-o-matic | Bugs | public | 2021-04-02 15:19 | 2023-05-30 00:04 |
| Reporter | overlookmotel | Assigned To | carl | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Mac | OS | OS X | OS Version | 10.14 |
| Summary | 0001947: 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:
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. | ||||
| Tags | No tags attached. | ||||
| Branch | |||||
| Estimated weeks required | |||||
| Estimated work required | |||||
|
|
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? |
|
|
If you're not sure I can check! Just let me know... |
|
|
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... |
|
|
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. |
|
|
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. |
|
|
Sorry for belated response. It appears this is fixed in 2.16.56 (and no doubt many versions before). This issue can be closed. |
|
|
Thanks for getting back! |
| 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 |
