Will not Auto Crop or manually crop / will not crop using Crop menu item about staxrip HOT 10 CLOSED

@THGhost
Correct, in case you have run into it, I have already published a hotfix on Discord and here: #1249 (comment)

Dolby Vision only (Purple/Green Tint - Profile 5) Videos also play perfectly after crop re-encode with proper colors adjusted by Dolby Vision - Only DV metadata.

Depending on the source and metadata: yes or no.

Also my TVs specifically indicate when Dolby Vision is active playing back the videos - so HDR fallback is not active.

The TV just tells you, that it recognized and uses Dolby Vision metadata, nothing about its conditions. You could apply the metadata of a completely different video and it would show you, that Dolby Vision metadata was found and use it.

Also, I further compared the original videos to the re-encoded cropped videos and other than a minor reduction in detail (due to generational and size - bitrate - reduction) - no difference - excellent colors, bright highlights and very good contrast - the cropped re-encode is virtually identical to the original.

Again it depends on the source and metadata as many videos would work, even not all parts of it.
But I also doubt you have checked if the smallest details like stars were correct. I would also consider a misalignment of 1px being broken. In your case the most obvious differences would be IMAX videos with different letter boxes.

The examples seem to indicate that cropping Dolby Vision/HDR does not "break" the Dolby Vision metadata. What are the external reference sources that support the contention that cropping yields "metadata won't fit the video anymore."

Nobody says that cropping itself breaks the metadata!! 🤨
But as soon as you crop the video different than the metadata, you break the result. And that is what StaxRip prohibits to do and you want me to ignore. Maybe a misunderstanding of how the metadata works or is applied?

🤔 Just to make sure the sample does not contain wrong metadata:
Can you share/post the HDRDVmetadata_L5.json file or its content of the whole and uncut video, that StaxRip lets write to the _temp folder after opening the source file?

What? NOT A SINGLE ONE OF MY REQUESTS WOULD LIMIT WHAT THE USER CAN DO!
Give specific examples and indicate how my request would limit the user!

The MOD 2 topic was indeed the one that came into my mind first, but nothing we need to discuss here, I just noticed, especially we also disagree in what it is. 😁

from staxrip.

I have checked your sample and StaxRip does, what it is supposed to do. Cropping this video would lead to a broken result, meaning the metadata would not fit anymore. So in case you really want to crop the video, you should remove the Dolby Vision metadata as that would not break the outcome.

from staxrip.

What broken result? What issue occurs?

I have always cropped these video before and had no issue with re-encoding or Dolby Vision playback.

Edit: To test this I reverted back to 2.35 and re-encoded the same video (CROPPED) I encoded in 2.36 and no there is no visual Dolby Vision difference between the two. There is a finished video size difference - 2.36 = 678 MB versus 2.35 = 881 MB. 2.36 version seems to be slightly lower quality consistent with the smaller file size.

This restriction of using cropping needs to be USER selectable. The USER should be allowed to crop videos at their discretion. If there is an issue the user can deal with it.

Occasionally, there was an issue with aberrant Dolby Vision playback cropping, The RPU created by StaxRip was the problem. HDR Multi Tool created RPU (picture/settings below) fixed the issue. I believe you have already corrected this problem.

from staxrip.

What broken result? What issue occurs?

The metadata won't fit the video anymore. The enhancement would affect the wrong parts of the image.

I have always cropped these video before and had no issue with re-encoding or Dolby Vision playback.
To test this I reverted back to 2.35 and re-encoded the same video (CROPPED) I encoded in 2.36 and no there is no visual Dolby Vision difference between the two

So either you had always luck with the sources and your cropping, or you proved, that there is not a big difference between Dolby Vision and HDR10(+) - or at least you can't see it. 😅

This restriction of using cropping needs to be USER selectable.

Interestingly there are some feature requests left from you, that want exactly the opposite, meaning giving the user less choices. 😅 👍
To be honest: When it comes to settings, that might deform a video, create horrible quality and so on, I'm completely with you. But destroying the end result on purpose? Once again: I don't get it.

The USER should be allowed to crop videos at their discretion.

Same as above...
You can crop what you want, but with metadata, you are restricted - not by StaxRip, by the metadata!

If there is an issue the user can deal with it.

Obviously not? 🥴

Occasionally, there was an issue with aberrant Dolby Vision playback cropping, The RPU created by StaxRip was the problem.

v2.35 handled it like most guides on various forums, guides, meaning incorrectly. Took me many hours to understand, that almost everybody was wrong and implement a proper way.

HDR Multi Tool created RPU (picture/settings below) fixed the issue. I believe you have already corrected this problem.

Both tools use dovi_tool, so I'm not sure where the difference should come from. But when you are talking about v2.34, then I would agree, because the --crop parameter was always applied, which was completely wrong.

from staxrip.

So either you had always luck with the sources and your cropping, or you proved, that there is not a big difference between Dolby Vision and HDR10(+) - or at least you can't see it. 😅

Dolby Vision only (Purple/Green Tint - Profile 5) Videos also play perfectly after crop re-encode with proper colors adjusted by Dolby Vision - Only DV metadata. Also my TVs specifically indicate when Dolby Vision is active playing back the videos - so HDR fallback is not active. Also, I further compared the original videos to the re-encoded cropped videos and other than a minor reduction in detail (due to generational and size - bitrate - reduction) - no difference - excellent colors, bright highlights and very good contrast - the cropped re-encode is virtually identical to the original.

The examples seem to indicate that cropping Dolby Vision/HDR does not "break" the Dolby Vision metadata. What are the external reference sources that support the contention that cropping yields "metadata won't fit the video anymore."

Interestingly there are some feature requests left from you, that want exactly the opposite, meaning giving the user less choices.

What? NOT A SINGLE ONE OF MY REQUESTS WOULD LIMIT WHAT THE USER CAN DO!
Give specific examples and indicate how my request would limit the user!

FYI I have reviewed all of my requests/questions and bug reports and none request something that would give the user less choices.

Even my enquiry about crop not being restricted to MOD2 numbers was because StaxRip reports an error if crop values are not Mod2 - Reference my original questions: "Are there circumstances where non-Mod 2 numbers can be used in cropping?" and "If a MOD 2 number is always REQUIRED..."

NOT MY "less choice": StaxRip error message - Crop: YUV image can only be cropped by Mod 2 (top).

from staxrip.

Just FYI, the whole "Does not retain manually entered crop values" problem occurs with all video files, not just Dolby Vision. Enter a value, click OK, the crop doesn't happen, check the values again, it's forgotten the values. So that definitely needs fixing.

from staxrip.

I just noteiced that message and came here to find a solution.
How about displaying the warning message (1st screenshot) and let the user continue anyway at his own risk?
Now that I know the reason for the warning I'll let StarxRip do its job of course 😁

from staxrip.

@Dendraspis
Does DV metadata have some coordinate information like what part of image need to be brighter or darker?
I tried to use dovi_tools info and don't see such information. It just contains information about offsets(L5) where to apply.
I often see that DV metadata contains offsets that 1 or 2 pixels bigger or smaller of my desired cropping(especially if I use some border filters to make frame even bigger by copying pixels above and below)
For instance, right now, I'm going to do original Jumanji encode and L5 metadata looks following

{
  "crop": true,
  "presets": [
    {
      "id": 0,
      "left": 0,
      "right": 0,
      "top": 40,
      "bottom": 40
    }
  ],
  "edits": {
    "0-149758": 0
  }
}

But actual crop should be 42 from both top and bottom because those pixels are completely black and would create unneeded 2px black lane at the top and the bottom.
Encoding should be done in a way to avoid these situations(top/bottom black bars)

from staxrip.

@cartman0208
Technically possible, but breaking the visual experience when it's not necessary? If you you want to crop more than possible, remove the metadata file and crop the shit out of it, the result should be better than with metadata. 😕

@IevgenSobko
I recommend to vidit the dovi_tool repository to get more information about its handling. I just use the commands I need for the handling. Nevertheless you might wanna have a look at dovi_tool export.

But actual crop should be 42 from both top and bottom because those pixels are completely black and would create unneeded 2px black lane at the top and the bottom.

Yeah, but sadly that's the way to go if you want to have a proper Dolby Vision encode as it's not possible to alter the metadata.

Encoding should be done in a way to avoid these situations(top/bottom black bars)

That's impossible as the metadata dictates the max cropping.

from staxrip.

The the Auto Crop feature seems to work as intended and the manual crop issue is already fixed for the next release as mentioned in its related issue.

So I close this one...

from staxrip.