Frame dump at raw internal resolution

[Filoppi]

Allows the frame dumper to use the raw emulation output (XFB) resolution, avoiding any scaling if possible. This should make comparisons much more reliable as pixels wouldn't be smushed together or stretched.

Currently even if bInternalResolutionFrameDumps is enabled, dumps are done after scaling to the target aspect ratio (which is almost always different from the raw emulation render), so they aren't really raw, they are scaled, but they scaling isn't done with gamma correction as the post process effects pipeline doesn't run on them.

This PR adds an enum with 3 dumping resolution choices:

Some possible future improvements related to this:

• Save the target aspect ratio number in the output file name, so it could be stretched in post.
• Remove the VIDEO_ENCODER_LCM (4) limit, or move it to the frame dumper and just make it add black pixel lines of padding on the edges instead of forcing images to stretch.

The FifoCI differences are expected.

The 2nd commit moves the adjustments to the dumping resolution into the actual dumping function, so the window output resolution isn't affected by recording anymore (previously it would snap to the closest multiple of 4 when recording, which was unnecessary). The 4th commit allows screenshots to be taken at any resolution, without the unnecessary VIDEO_ENCODER_LCM (4) limit.

[JosJuice]

This is okay for FifoCI, but for regular users I think this is unacceptable unless it's put behind a toggle. You say that "it's very easy to size the window to match the target aspect ratio and then set bInternalResolutionFrameDumps to false", but:

1. Finding out the size the image is supposed to be after scaling is non-trivial
2. Resizing the window to the right size is non-trivial (either you have to carefully drag the window edges to match exact pixel sizes, or you have to know how to navigate Qt.ini)
3. If the game you're dumping changes the resolution/aspect ratio, each time there's a change you have to do a frame-perfect pause (without Dolphin even telling you when to pause) and do all the steps above over again (with editing Qt.ini now being impossible due to Dolphin only reloading it on restart)

This would completely break TAS dumping workflows.

[Filoppi]

@JosJuice I was indeed wondering what happens if the game changes resolution while recording. Theoretically this was already an issue before, as if bInternalResolutionFrameDumps was true (or false actually), the video/output size could be changed between frames.

Regarding the rest, we could simply make an enum with 3 choices (window resolution, XFB raw resolution, XFB aspect ratio corrected resolution).

[JosJuice]

I was indeed wondering what happens if the game changes resolution while recording. Theoretically this was already an issue before, as if bInternalResolutionFrameDumps was false, the video/output size could be changed between frames.

We split the video on resolution changes.

Regarding the rest, we could simply make an enum with 3 choices (window resolution, XFB raw resolution, XFB aspect ratio corrected resolution).

Yes, that sounds fine.

[Filoppi]

uploaded a new version with 3 settings Edit: screenshot outdated

[Filoppi]

@mbc07 it was an oversight, fixed

[Filoppi]

The fifoci differences are due to the following reasons:

• frame dumping now follows the VIDEO_ENCODER_LCM (4) size in a more streamlined way, without ever influencing the window size
• frame dumping screenshots now ignore VIDEO_ENCODER_LCM (4), as it's only needed when dumping videos.
• frame dumping now ignores cropping
• frame dumping better converts from a float to int resolution, and finds the one with the closest target aspect ratio

[impiaaa]

Might I also make the suggestion to tag frame dump output with the intended aspect ratio? It looks like it can be set in FFmpeg with sample_aspect_ratio in the AVCodecContext, and in PNG with the pHYs chunk. That way the actual video data can be raw XFB, but the video player or editor should still display it at the correct ratio.

[Filoppi]

@impiaaa good point. I won't do anything more surrounding these features, given I don't use them, but anybody else could do in a separate PR.

[MayImilae]

That's better. But I have some more notes.

Having Dolphin do aspect ratio correction doesn't prevent scaling or post processing in external editing software, as is implied by this description. Raw doesn't "allow" it. Also, grammatically, it should be "at higher quality" not "with a higher quality".

I still take issue with quality being mentioned here. This option basically has Dolphin go hands off so video editors have completely control over the pixels of the footage. This could allow them to optimize the pixel clarity of their video, or they just won't apply pixel aspect ratio correction at all and get a worse result than if they had used one of our correction options (which IMO is pretty likely). The whole point of this is that we're giving the user a clean slate for them to manipulate however they so please, which can mean basically anything. So I'm not super happy with saying that this option will improve quality. Cause it may very well not.

Furthermore, I don't like the uneven presentation of these options. Window Resolution and Aspect Ratio Corrected Internal Resolution do not describe how to use them or their advantages or anything, they simply state what they are and move on. But for Raw, you continue to talk about its advantages and what users can gain from using it. That, plus positive language, are what gives is the impression that Dolphin wants you to use this and not the others. IMO, you should treat all three options the same way. If you want to matter of fact say what they are, do it for all of them. If you want to describe use cases, do it for all of them.

[Filoppi]

@MayImilae please directly write the tooltip exactly as you want :), I already gave my version and proposed some alternatives. I don't think it matters at all, but if you are looking for something very specific, please directly suggest the full edit. Thanks.

[MayImilae]

Ok, I'll give it a shot!

Window Resolution: Uses the output window resolution (without black bars or cropping). This is a simple dumping option that will capture the image more or less as you see it.

Aspect Ratio Corrected Internal Resolution: Uses the Internal Resolution (XFB size), and corrects it by the target aspect ratio. This option will consistently dump at the specified Internal Resolution regardless of how the image is displayed during recording.

Raw Internal Resolution: Uses the Internal Resolution (XFB size) without correcting it with the target aspect ratio. This will provide a clean dump without any aspect ratio correction so users have as raw as possible input for external editing software.

How's this? I added to the other options to even it out, and went with the one I showed earlier for Raw Internal Resolution but with some modifications. It's still not completely even between the options but by adding some details to the other ones, the details for Raw Internal Resolution now fit in better, imo.

[Filoppi]

@MayImilae re-uploaded with your text.

[Filoppi]

@JosJuice https://github.com/dolphin-emu/dolphin/pull/12436#issuecomment-1971068359

[AdmiralCurtiss]

This has been sitting here for ages, works fine, and is a useful improvement to the options.