25p will be sent as PsF over HDMI in PAL – clean cadence, other than 24p.

@Ralph_B

Yes, I know. But his question concerned the in-camera recording when an HDMI monitor was plugged in.

Yes, I'm talking about in-camera recording while HDMI is being used also.

Yes, I think so, it's only Y'Cb'Cr'. Many devices don't cover the "standard" to full extent.

@DirkVoorhoeve . Sorry, I was traveling and I couldn't post you. You are very right on your considerations about color spaces and the chroma components values for Magenta and Green too. Also on how the RGB and YCbCr are patched (Y/G, Cb/B, Cr/R).

I reached the conclusion that the GH2's HDMI was RGB for the fact that when I feed my PANASONIC Plasma TV with any HDMI/YCbCr signal out of the AJA ioHD (HDMI out RGB/YCbCr selectable) everything goes wrong. That makes me think that the PANA TV doesn't accepts HDMI/YCbCr but only HDMI/RGB. If this is true, the GH2 HDMI out should be RGB, because looks great in the PANA TV.

My Dell US24 screen also display the GH2 HDMI without any problem. I doubt very much that is fitted to take HDMI/YCbCr (as you mentioned that's is optional and very little likely in a 4 years old computer monitor). Anyway, I will test feeding it with a HDMI/YCbCr from the AJA and I will post.

Yeap. I've just found a pict of a test I did. In the left is the TV screen when the AJAs HDMI is putting out RGB. In the right when putting out YUV:

@kicap In mi test (PAL), the HDMI is putting out a clean signal (full range, which is great), but interlaced (1080i25). For those who want interlaced, perfect. For my self who want Progressive, no.

That's nothing related with the camera being hacked or not.

@kicap I understand you. When the GH2 is recording is sending a signal already processed (Video range/color matrix) and also interlaced. I think, being high quality patches, thats no worth to try to record it on an external device. The weird thing for me is the Interlacing issue. Its seems that even when set in p25 or p30, the camera always scan interlaced. I don't know who get the recorded signal progressive, but in many cases (even with the best patches) it fails and can not hide the original Interlacing (see some posts about banding).

@DirkVoorhoeve It's been done a long time ago. You're a little late to the party.

@DirkVoorhoeve Mine are speculations based in what I see on my TV (haven't checked yet on the Dell). If my TV breaks the HDMI/YUV from the AJA (see the picture in my post of the 12th) but plays well his HDMI/RGB and the GH2 HDMI, I have to deduce that the GH2 HDMI is RGB. That, or the AJA is lying me.

This for me makes sense as well because when not recording (the AVCHD processor is not working, so no need of YUV nowhere), is easier to pull an RGB signal than an YUV signal from the system. RGB out simplify the things.

About Interlacing/progressive, what I've found is that is plain interlaced: Two fields. I tried that with recording on the NANO-Flash. After deinterlacing the picture plays great on any progressive monitor.

I've made my tests with the camera NOT recording because that gives a full 0-255 range. That's great, but the need to deinterlace isn't at all. When recording, the camera goes 16/239 clipping the highlights and apply the color matrix set in camera.

@Amadeus5D2 are talking about 25p (HBR mode)? You say it has strange interlaced effects, do you mean that it is 'sort of' PsF? How did you watch it?

I'm am not sure, but I recall that Vitaliy has already pointed out somewhere that in PsF mode the Luma (Y') is sampled progressively (PsF), but the chroma subsampling is done interlaced. If I understand right, that's also the FixBrokenChromaUpsampling() part of the AviSynth script. Could that CUE-like effect be what you are seeing? In other words: do you still have those strange interlaced effects if you look at the Y' channel only (black&white)?

@Brian202020 I fully agree with you, and I am sorry that I have not been clear in the original post. What I meant is that the HDMI stream for sure will be 4:2:2 Y'CbCr or better, but that it took me some time to find out that the real question is not about the stream itself, but to what is fed to the HDMI converter inside of the GH2? In case of playback it will for sure be the AVCHD video: but the output of the HDMI converter will not be a compressed stream, it will be decompressed before leaving the GH2. I'll change my post to be more specific.

@Rafa I've been trying to get the same colors as your picture by using RGB->Y'CbCr or the Y'CbCr -> RGB conversion, but I could not recreate the colors in your picture. All I would get is a green/magenta haze like this, not all these strange colors you got, that looks more like a hue shift. And about the PsF v.s. interlaced discussion: Yes: the PsF stream will be two fields, as it is segmented frame. Try not deinterlace it, but instead set the field order to progressive. If it is real PsF, it should not look like this. Just make sure you have the cam in PAL -> HBR 25p mode. I'm interested to see your findings.

@DirkVoorhoeve You say that the picture you are getting has all the colors in the Green/Magenta axe. So the colors go from (R128,G16,B128) to (R128,G16,B128), but the only variations are in "G" that goes from all 16 to 235. R and B always keep at 128 what means there is "0". For me that means that your monitor is getting a monochromatic (B&W) YUV signal. You know that in a B&W signal Y' will goes 16/235 but Cb = Cr = 128. So the R and B channels of your screen will always be getting 128, while the G channel (the one that get the Y' channel) can go all the way from 16 to 235. When the picture will be black (Y=16) you will get R128-G16-B128 (so Magenta) and when the picture will be white (Y=235) R128-G235-B128 (so green), when the picture will have a 50% luma (Y=128), you will get a grey: R128-G128-B128.

The picture on the link you've posted is VERY BAD to judge this issue. That picture is not B&W but is very much desaturated. In the picture there are almost no reds, neither blues and even the green on the bushes is very weak. Chroma is low so Cb and Cr values won't go much faraway from "128". This makes that all the colors are very much close to the Green/magenta axe with little variations unperceptible to the eye, but I'm testing this with a Color Picker which is giving me the real RGB values on both images. The GREY makes sense because in the original picture is also gray.

The picture I've posted have nothing of a color shift, but is a perfect example of what happens when you patch an YUV signal to an RGB system. If was a chroma shift, the low lights would change the tone, but would keep low lights because the luma wouldn't change. The same would happens with the high lights: would change the tones but would keep high lights. About pure Grays, they wouldn't change when shifting colors because they have no Chroma to shift. They would always remain the same. I have tried with Color Bars and the Black and the White bars change completely: A simple chroma shift wouldn't do so (I'll post later a test).

If you see the picture of the car, there is not anymore low lights neither highlights. There you don't get the Greens or Magentas of your picture (neither a Grey) because there are not real blacks, whites or grey. There is color everywhere so you can't get Cb = Cr = 128 to produce these colors.

@Rafa I am with you on the part about the B&W signal, with all variations having Cb and Cr values of 128 and only Y' changing.

But I must say I find it difficult to understand what is happening with your picture though. FYI I attached two pictures of my display. It is an image your picture, displayed on my BenQ and then photographed. Colors will not be exactly spot-on, but it will give you an idea of what I am seeing.