[IMPOSSIBLE] Output recording HDMI

[rav]

Hi everybody!

I saw the last "nightly build" update and btw i'm so impressed by the RAW DNG render, like many people.
My request is certainly a dream but I'd like to know if the recording via HDMI on a 14bits RAW recorder and SSD could be possible one day?

The BIG advantage would be the bitrate (up to 6gb/s) and of course the budget : a 250GB SSD coast approx the same than a 32GB 1000X CF.

I've also see somewhere on the web that a 3.5K RAW video have been shot on a 5DIII, is the 4K @ 24fps function will be able one day?

Thanks a lot and sorry for my english. 

[vroem]

Although this request is tagged as [IMPOSSIBLE], I find this a very interesting idea to explore. I'm not a developer, just a guy who's dreaming.

Of course HDMI has no support for bayered raw. In fact the format used by canon is 8-bit Y'UV 422, this means the hdmi signal has at least 16bit/px compared to the 14bit RAW. So HDMI's bandwidth would be sufficient to get a Full HD raw signal out. Again, I'm not a developer, but just for fun, let's explore the (long!) road it would take to achieve raw over HDMI:

- The first problem I think is that we didn't figure out yet how to feed raw bits into the HDMI buffer. It also needs to be seen if it would accept a bitstream with progressive frames.

- Currently, the camera's builtin display turns off when connecting the HDMI, so you would need to use an HDMI monitor. This means that the signal should be interpretable as YUV422. For that I came up with this raw to yuv conversion. An HDMI monitor interpreting this raw signal as yuv would show a monochrome bayered image with a slight color noise:

Code Select Expand


                    px1            px2           
14bit raw:          rrrrrrrrrrrrrr gggggggggggggg

                    px1      px1+2    px2      px1+2   
8bit Y'UV422:       yyyyyyyy uuuuuuuu yyyyyyyy vvvvvvvv
                   
16bit yuv-like raw: rrrrrrrr 00rrrrrr gggggggg 00gggggg


Short explanation: every 14bit raw pixel value gets split: the 8 most significant bits become the luminance (y) value of the yuv pixel, the other 6 bits 'leak' into the chroma (u or v) value that follows it. We prefix the chroma value with two zero bits to fill up the byte and also to reduce the color noise resulting from the random value of the 6 last bits.

- Bitrate downconversion (to 12 or 10bit) is in the works, so maybe this kind of upconvertion could be doable by the ARM processor, maybe not.

- Of course this HDMI signal should be recorded uncompressed, as compression would interpret the raw signal as yuv which would destroy it.

- The resulting uncompressed file can than be reconverted to a standard raw file without any loss.

And voilà! A man can dream sometimes, can't he?

[nanomad]

- We can feed whatever we want to the HDMI buffer, that's actually quite easy
- The HDMI chip will apply some non linear image effects that screw up everything. So, unless someone comes up with an inverse "effect function" we can't do much with it

[vroem]

Heh, that clarifies the [impossible]  Do you know anything more on these linear image effects? Thanks to chipworks, we now know the hdmi chip for the t4i (650D): it's the ADV7523A.

[a1ex]

Sharpening, 16-235 scaling, and I think luma averaging too. For example, you fill the screen with 0x12345678 and you get 0x302F6B2F. The 2F is luma. Both look kinda bluish, but we need to recover the exact value.

[nanomad]

Heh, that clarifies the [impossible]  Do you know anything more on these linear image effects? Thanks to chipworks, we now know the hdmi chip for the t4i (650D): it's the ADV7523A.

Dig inside the data sheet and figure out how we can reconfigure it. :-

[Grey_Sally]

Hi, first post, so go easy with the replies 

Far as I can see, it's any sharpening applied by the HDMI controller that's the main obstacle to this working... That said, the latest 5D3 firmware enables clean HDMI out (with LV still on the screen), which as far as I understand, should at the very least be unsharpened (maybe unscaled?). I know ML can't run over this latest Canon firmware, but if there is a way of telling the chip to not modify the image, maybe that can be exploited?

Also, if "we can feed whatever we want to the HDMI buffer", then there's a way to feed it various known pixel arrays/images/colour blocks to see what processing does occur. Obviously, could be useful for creating a function map for pixel-level processing, maybe not so much for image level, but I can't help feeling that, since we only really need to send out a greyscale image, and HDMI spec requires 3 channels, that maybe there's a way of decomposing whichever image into three parts so that processing on each part is minimal... Who knows. The last suggestion sounds like CPU intensive task, but I've gotten to the point where I'm just thinking out loud.

Thoughts?

[1%]

very least be unsharpened (maybe unscaled?

I doubt it. I bet they just turned off overlays and made it 24P...its still YUV.

After feeding raw data to the HDMI there has to be something that records it untouched too. Its not going to be image data.

[papkee]

Sorry to bump an old post, but was this ever explored further? Something like this could be a lifesaver for cameras with a capped card reader (like my T4i) to allow higher resolution continuous recording. Would it be possible then to get the max resolution (1792x972) fed through the HDMI feed to an external recorder?

If this is possible, even in theory, then this could be a major break for people who are limited by their card reader.