name: Bug report
about: Report an issue of the mod crashing or behaving in an unexpected way
title: ''
labels: bug
assignees: ''
Describe the bug
The monitor and projector compress the image, which in this case involves converting to YUV420 and back. The 420 part of YUV420 means a specific type of chroma subsampling, where the hue for most of the pixels is discarded and they have the same hue as surrounding pixels but with different brightness. Thatʼs fine with higher-resolution displays and natural images like photographs, but looks terrible at 640x480 with lots of sharp lines, like with text. See attached screenshot of the monitor GUI; most of the text looks fine but the prompt on the last line does not, because the sharp color change is lost; compare with what the guest VM thinks it should look like when I grab /dev/fb0 without first converting to YUV420 and back.
See also the result of view /mnt/builtin/lib/micropython/devices.py; the normal text is perfectly normal (gray and black are the same chroma so subsampling doesnʼt matter), the purple keywords look bad but are understandable, and the blue string literals are almost completely unreadable.
To Reproduce
Steps to reproduce the behavior:
- Open a new world, singleplayer or multiplayer doesnʼt matter.
- Place a preconfigured computer and a monitor, with enough power.
- Turn on monitor, then computer
- Log in as root and look at the output
Log files
Not relevant
Expected behavior
All 640×480 pixels have independent color, or at least the compression algorithm works better with the current primary use case of text or simple graphics written to /dev/fb0.
Screenshots
The screen right after logging in, as seen on the monitor:
Similar screen, what Linux is actually sending to the FB:
A Python file with syntax highlighting, on the monitor:
Versions (please complete the following information):
- Minecraft: 1.20.1
- Forge: 47.4.0
- oc2r: [Custom branch 4 commits ahead of 1.20.1 master, but none of those commits touch this code]
Additional context
I think h264 is simply the wrong codec for the job here. The simplest solution compression might be to use jCodec for PNG because jCodec is already being used, but thereʼs probably an easy option that still has interframe compression if PNG isnʼt good enough for that. Maybe something with JPEG XL, based on my very limited research?
name: Bug report
about: Report an issue of the mod crashing or behaving in an unexpected way
title: ''
labels: bug
assignees: ''
Describe the bug
The monitor and projector compress the image, which in this case involves converting to YUV420 and back. The 420 part of YUV420 means a specific type of chroma subsampling, where the hue for most of the pixels is discarded and they have the same hue as surrounding pixels but with different brightness. Thatʼs fine with higher-resolution displays and natural images like photographs, but looks terrible at 640x480 with lots of sharp lines, like with text. See attached screenshot of the monitor GUI; most of the text looks fine but the prompt on the last line does not, because the sharp color change is lost; compare with what the guest VM thinks it should look like when I grab
/dev/fb0without first converting to YUV420 and back.See also the result of
view /mnt/builtin/lib/micropython/devices.py; the normal text is perfectly normal (gray and black are the same chroma so subsampling doesnʼt matter), the purple keywords look bad but are understandable, and the blue string literals are almost completely unreadable.To Reproduce
Steps to reproduce the behavior:
Log files
Not relevant
Expected behavior
All 640×480 pixels have independent color, or at least the compression algorithm works better with the current primary use case of text or simple graphics written to
/dev/fb0.Screenshots
The screen right after logging in, as seen on the monitor:
Similar screen, what Linux is actually sending to the FB:
A Python file with syntax highlighting, on the monitor:
Versions (please complete the following information):
Additional context
I think h264 is simply the wrong codec for the job here. The simplest solution compression might be to use jCodec for PNG because jCodec is already being used, but thereʼs probably an easy option that still has interframe compression if PNG isnʼt good enough for that. Maybe something with JPEG XL, based on my very limited research?