The grid is too noticeable

[CareBearsAEQM1]

Hello, I would like to know how to solve that the grid is marked too much. In version 1.8 or less, you don't notice the grid but you do notice squares that look deformed. and in version 1.9 to 2.1.3, that error is corrected, but now the image looks more yellowish and saturated, the grid is very noticeable, I don't know if there will be a solution. I have tried many combinations, changing the grid size and jpg quality. Is there any way to keep the grid from being noticed?

1.8: [vulkan][s2][n2][b20][q95]

1.9 [vulkan][s2][n2][b15][q95] 1.9 [vulkan][s2][n2][b20][q95]

2.1.3 [vulkan][s2][n2][b20][q95]

[akai-katto]

In 1.9, I changed the default ffmpeg filters used, which may account for the change in edges. Try going back

https://www.reddit.com/r/Dandere2x/comments/gs0qi0/19_release_ssim_bug_fixes_new_default_ffmpeg/

I would recommend reading this post to try and change the settings to your liking

https://www.reddit.com/r/Dandere2x/comments/gqhhgj/i_posted_an_ai_upscaled_liveaction_video_with/

Let me know the results, im curious

[CareBearsAEQM1]

Hi, I tried to change several ffmpeg settings. I tried to use the code:

• ' pp=hb/vb/dr/fq|32, deband=range=22:blur=false'. in version 1.9 and 2.1.3, I tried to copy all the ffmpeg code from version 1.8 to 2.1.3, but it always looks the same, as if I had not touched the code. I also tried the opposite, to put the ffmpeg code from 1.9 to 1.8, but I get the same results. 1.9 is still seen with a grid and 1.8 is still missing some blocks

I don't know much about this type of code, plus the code changes a lot from the yaml of 1.8 to 2.1.3

I would like it to look like 1.8 but without those blocks that fail, everything is fine, except those blocks that fail.

I have already tried 40 different combinations, different versions and configurations and I keep getting the same results.

I have noticed that the problem happens when the video moves a bit diagonally

Is there any way to make it look like 1.8 without those annoying errors? (Translated with DeepL, I don't know much English)

1.8: (block size 20) 1.3: (Block size 20) Block Size 60: Block Size 10 Block Size 30

1.7.1

Grid: 1.8: (Block Size 20) 2.1.3:(Block Size 20)

the differences can be noticed much more with a screen (I don't remember the name), those that look different depending on the angle, those that are not IPS. When looking from the bottom up you can easily notice it.

If it could look like 2.1.3 without that grid, it would be great. Or it would also look like 1.8 without those missing blocks.

[akai-katto]

I'm going to look into this this weekend. Would you mind submitting the original video + timestamp of this bug for me to investigate?

[CareBearsAEQM1]

Here is the link to several tests I have done. https://drive.google.com/file/d/1cIHiofy-IgVlI1OEMcyngATkDOZXTPNW/view?usp=sharing The tests last 11 and 22 seconds.

[CareBearsAICAL]

@aka-katto I don't understand much about how the program works, but, there will be some way that in the 1.8- increase the sensitivity by keeping a block from a previous frame, example: that it needs to be more similar the blocks to keep them and by being different that the difference doesn't have to be so much, so as not to repeat a previous frame that doesn't match as it is what happens in the tests. Or to configure somehow the 1.9+ so that the grid is not too noticeable, which does not happen in previous versions, because the edges are too noticeable. And also something that calls my attention is the saturation, it changes too much in the 1.9+, leaving blue and yellow tones. All this can be noticed too much on a regular notebook screen, which are not IPS. (I want to use the word "bug", but the translator won't let me translate from Spanish "bug" to English)

Original video (In 1.3.1 it was cut) / Dandere2x 1.9: The colors change a lot, the color of the upper right corner, in the original looks darker and the other lighter, and the color purple, in the original looks smooth and the other shows blue spots. (You can see it on those screens that reflect, looking at it from the bottom up)

Normal color / 1.9

Grid 1.8 / 1.9

[CareBearsAICAL]

@aka-katto I'm stuck with my project to remaster a series, I can't choose between worse color or failing blocks, it would help me a lot to know how to configure the sensitivity with which the program detects that a block should be replaced or not. Is there an adjustment for that? This way you could repair the 1.8 fault and it would look great.

I tried to remaster a chapter with 1.8, but it was a bad idea. And the color of 2.1.3 does not convince me, it looks very blue and yellowish. https://drive.google.com/file/d/1_wgpyDjP3uq5Co9ARp8tkXs_BL7TNn2m/view https://youtu.be/Ao_flURDavQ Where it is most noticeable: 0:37, 1:36, 10:17

[akai-katto]

Here's some of the major changes that happened between 1.8 -> 19

1.8

Frames from a video were extracted using ffmpeg

1.9

Frames from a video are extracted from CV2, prior to being re-encoded using ffmpeg.

How does this affect you?

I conjecture that the major difference in color that is causing you issues stems from the way CV2 decodes the file format. Im the yaml file, look here:

re_encode_video:
    output_options:
      -pix_fmt: null
      -vsync: "cfr"
      -crf : 17
      -vf:
        - noise=c1s=8:c0f=u

You probably want to set the pixel format (https://video.stackexchange.com/questions/16374/ffmpeg-pixel-format-definitions) in -pix_fmt for your videos, as that's the main reason I believe the colors would be different. I would recommend starting with AV_PIX_FMT_YUV420P.

Sorry for the slow responses though - life is moving fast but I'm still trying to find time to work on dandere2x. Let me know if I missed anything / didn't address your questions correctly.

[CareBearsAICAL]

@aka-katto I don't understand much how ffmpeg works, which line should I modify and what should I try with. My doubt was if it is possible to modify 1.3.1 or 1.8 so that those blocks don't appear failing. I find that 1.3.1 looks better than 1.8. replace the "null" with the other truth?. I will try to do it In 2.1.3 I got an error that something was missing when modifying the pix_fmt, and it didn't do anything

[akai-katto]

@aka-katto I don't understand much how ffmpeg works, which line should I modify and what should I try with. My doubt was if it is possible to modify 1.3.1 or 1.8 so that those blocks don't appear failing. I find that 1.3.1 looks better than 1.8. replace the "null" with the other truth?. I will try to do it

I would recommend trying some variations of these

re_encode_video:
    output_options:
      -pix_fmt: "yuv420p"
      -vsync: "cfr"
      -crf : 17
      -vf:
        - noise=c1s=8:c0f=u

  pipe_video:
    -y: true
    output_options:
      -loglevel: panic
      -pix_fmt: "yuv420p"
      -y: -f
      image2pipe: True
      -i: '-'
      -vcodec: libx264
      -preset: medium
      -qscale: 5
      -crf: 17
      -vf:
        - ' deband=range=8:blur=false, pp7=qp=2:mode=medium'

Until you find a pixformat that gets the colors you want. You can find pix_fmt here

https://trac.ffmpeg.org/wiki/Chroma%20Subsampling

[CareBearsAICAL]

@aka-katto I don't know what I'm doing wrong, but when I change the code to 1.9 and 2.1.3, the program crashes now i just changed the "yuv420p", and it didn't crash anymore

[CareBearsAICAL]

@aka-katto looks almost identical, I would say that the grid is more noticeable, Still no solution :c i tried the "yuv420p" and the "yuv444p10le" no change is noted

[akai-katto]

You can try copy and pasting dandere2x_cpp.exe from 2.1.3 into 1.8 and seeing if that fixes the issue for the quality - what this is doing is getting the program that is responsible for calculating which blocks to recycle, and then using them in 1.8. I'm fairly certain they're backwards compatible.

Will test right now

Edit: dragging dandere2x_cpp.exe from 2.1.3 into 1.8 externals seems to be working fine.

Edit 2: In 1.8, set

  developer_settings:

    debug: false
    workspace: ..\workspace\default\ # path to the workspace folder (lots of files will be written here)
    dandere2x_cpp_dir: ..\externals\dandere2x_cpp.exe # path to dandere2x_cpp binary file
    workspace_use_temp: false
    gui_delete_workspace_after: true
    extension_type: .jpg
    bleed: 1
    quality_moving_ratio: 0.55
    step_size: 8

->

  developer_settings:

    debug: false
    workspace: ..\workspace\default\ # path to the workspace folder (lots of files will be written here)
    dandere2x_cpp_dir: ..\externals\dandere2x_cpp.exe # path to dandere2x_cpp binary file
    workspace_use_temp: false
    gui_delete_workspace_after: true
    extension_type: .jpg
    bleed: 1
    quality_moving_ratio: 1.0
    step_size: 8

I forgot that I've deprecated quality_moving_ratio as it made the quality fairly poor

[CareBearsAICAL]

@aka-katto Thank you very much, finally it looks like it wanted, it looks like 1.3.1, it loses a little bit of quality, but it doesn't have any kind of failure, thank you very much. The solution you said served me too much: Copy the folder "External" from 2.1.3 to 1.8 and give it to replace. And set the quality:moving ratio to 1.0

[CareBearsAICAL]

The solution had nothing to do with "externals", you just had to change the "quality_moving_ratio" from 0.55 to 1.0 Personally, I choose 1.3.1 and modify the color in DaVinci Resolve (vulkan, denoise 0, scale 2x, image quality 95, block size 10, quality_moving_ratio: 1.0)

2.1.3 1.3.1 1.8

[akai-katto]

@aka-katto Thank you very much, finally it looks like it wanted, it looks like 1.3.1, it loses a little bit of quality, but it doesn't have any kind of failure, thank you very much. The solution you said served me too much: Copy the folder "External" from 2.1.3 to 1.8 and give it to replace. And set the quality:moving ratio to 1.0

:]

I'm happy to resolve this - 'moving_quality_ratio' is something I added last minute (was moving out to college) and didn't think too deeply on. Thanks for reminding me to remove it - I'll close this ticket once I do. Happy to see you achieved your results

[CareBearsAICAL]

@aka-katto After many tests, the best option is 1.3.1, since the color is better preserved and does not lose detail, what happened was that a block failed to appear again, with a block size 30 or less appeared, with 40 and 60 not. So I decided to change the quality_moving_ratio from 1.0 to 2.0 and to my surprise, when I tried with the size 30 block, the block didn't fail anymore, so that left me thinking. What is the limit number of the quality_moving_ratio? 1.3.1 b30, quality_moving_ratio 1.0 | b40, quality_moving_ratio 1.0 | b30, quality_moving_ratio 2.0

Edit: I just tried a block 10 and there is no block failing I still have a half-bug block, it has a pixel left from the previous frame that should not be left

[petvas]

Dain app has a solution to get rid of Grid effect:

Maybe something like this can be implemented in this program?