Hi,

What is the current state with the Raspberry Pi 4 support for PGenerator?

Hi,

It requires a lot of development as the framework for Pi 3 was not compatible, so when the software will be ready first, then it will be tested to see if it can provide the same bit-perfect RGB output as Pi 3 etc.

Probably a stupid question but given that the Pi 4 supports HDMI 2.0 will this mean that we can manipulate the EDID and use it as a HDR pattern generator without requiring an HD Fury or similar?

Many thanks.

Hi, I don't think it's available any API to control the metadata with Pi4.

PGenerator does not even support it as a Pi4 device.

If it is available a way to control metadata infoframe, then the developer will take a lot.

I think that it is not possibile and the rpi p4 is not compatibile with PGenerator software: I have to rewrite the code to use new functions

Thanks for the responses.

So essentially there is nothing to gain from waiting as an HDFury will still be needed for HDR. Presumably all that is needed aside from the Pi is a Dr HDMI 4k?

Anthony.

The lowest cost HDFury is the Linker or the Integral 300 MHz: https://www.hdfury.com/product/integral-4k60-420-300mhz/

Dr. HDMI can't be used as it can't inject HDR10 metadata.

Thanks for the response. The Dr. HDMI specs were confusing as they seemed to imply that it could so thanks for stopping me from making a mistake. The Integral 300MHz seems to be discontinued and is at a nice price as a result so with a Pi should make a nice low cost HDR pattern generator.

Thanks all.

Anthony.

One caveat: it will be for RGB Full only. The Pi does not generate bit-accurate YCbCr for SDR, and neither it nor the HDFury boxes can produce the proper YCbCr for HDR - the mathematics involved are completely different. Generators that can produce the correct YCbCr output for HDR are still very scarce and very expensive.

Thanks for this. Now this is where my ignorance is probably going to get exposed.

I am looking at attempting the calibration of a few TVs, most of them Samsung. There will be no external hardware sources used and as such the only sources will be the internal steaming apps of the TVs. I am probably wrong but the output format of these apps will be RGB so assuming the HDMI port doesn't do anything funky all I need to do is have a bit perfect RGB pattern generator in order to be able to calibrate solely for these apps. I suspect I am probably incorrect about this in quite a few ways!

Anthony.

Samsung TVs maintain separate memories for HDMI inputs and USB/internal apps. So calibrating one HDMI input would only work for that input unless you choose "Apply to All Inputs" in Settings. This would copy the results to all HDMI inputs but not USB/Internal apps. However, you could copy the final settings and manually apply them while watching something via an internal app such as Netflix.

I had braced myself for such a step in my workflow. As long as the Pi is a suitable pattern generator for the internal apps then a little elbow grease to get things setup properly isn't going to hurt!

Thanks for the assistance.

Hi, I'm completely new here. 😇

I have extensive experience with the Quantum Data 780e HDMI/DisplayPort/HDBaseT generator, I also programmed its complete control via USB/UART and revealed a number of errors and shortcomings in it.
https://www.quantumdata.com/780e.html
I also have experience with the Omnitek Ultra 4K Tool Box, which was recently purchased by Intel and is almost no longer supported.
http://www.postium.co.kr/support/file/brochure/Omnitek_4K_toolbox.pdf
I also play with HDMI 2.0/SDI 12G video converters from BlackMagic and AJA and other video equipment from Gefen, Astro or Kramer.

I really want PGenerator to work on Raspberry Pi 4B so that I can generate HDMI 2.0 UHD and 4K signals with it, such as VIC 97 (3840x2160p60), because QD780E is really terribly slow and unreliable product.

I can capture video by "my own", more precisely from a friend, frame grabber (and generator), built on Intel Arria 10 FPGA (inputs/outputs HDMI 2.0 and 12G SDI) and I can confirm not only a bit of perfect data transfer, but also the validity of AVI infoframe, clock accuracy, compliance with CEA/CTA and VESA standards and so on.

Personally, I have generated dozens of 2D interesting bit of perfect test patterns and animations (for measuring input latency), as well as 3D patterns (eg from Big Bugs Bunny), and in my collection I also have nice shapes from Quantum Data, Omnitek, Murideo, Väinö Helminen, and also something for HDR and BT.2020.
I also know a lot about EDID, I have read the standard quite well and I can test the causes of special errors that a faulty EDID can cause, such as the missing bit that it is an HDMI interface without which Intel graphics do not work.
I also have a lot of experience in the past with calibrating LCD monitors with X-Rite i1Basic Pro 2 with Argyll + DisplayCal, and now I have a Minolta industrial probe available from a friend, but I haven't played with it at all yet. 😉

So what can I do to extend PGenerator support to RPi 4B and how can I help?

I read this whole thread and nowhere did I see the summarized reasons for not supporting RPi 4B. I'm sorry if I missed it somewhere.
Unfortunately, I'm not the owner of RPi 3B and I have no experience with it to be able to distinguish the differences in the video core of RPi 4B, but here I sense the problem that there is quite a different graphics core and architecture around.

I hope this post will help find a way for PGenerator to support RPi 4B soon. 🙂

Thanks for your attention!

hope for pi4

Forlorn hope...