Hacked Sony A7S?!

Samuel H said:
I ran some tests to check that Sony claim. It's not true. It has a lot more DR than the slog2 video mode allows.
http://www.dvxuser.com/V6/showthrea...my-procrastination-towards-interesting-stuff)

Even so, this is most likely just a hoax. The 10-bit thing is highly unlikely. If he had said internal 8-bit 420 4K on the a7S, it would be actually believable. Internal 422 would already be a stretch in my mind. Those things are usually hard-coded in the processor.
Click to expand...

HD 10-bit 422 is more plausible.
 
https://vimeo.com/140160082

Another video with a stack of comments.

I still don't see anything in there that says this is hackable. That github project allows you to load up android apps (hence the cpu stuff). He's trying to say the root explorer shows access to HDMI and all that but i just see a bunch of directories.

I don't see anything i'd consider hacked firmware.

I'm not saying this isn't possible but this is such a basic step. The applications on the sonys have a very limited API and anything beyond that won't be published and most likely secured against access.

Any thoughts?

cheers
Paul
 
Now he says, he can even add slog3, this just isnt possible unless he is working for Sony and has access to the sony log profiles..
He just got an app so he can browse the contents of the camera. Great, but does not mean anything if he can not update the files. And it does not seem he knows anything about what he is doing. There has not been any evidence of any kind that this hack is possible.
I won't be holding my breath.
 
Honestly once someone can figure out how the file system works and how some of the api calls get used, I don't see why we wouldnt be able to get slog3 or faster frame rates or even internal 4k. external 10 bit 422 will potentially be hardware limited, but i have no idea if it is or not.
I don't doubt whether the a7s is hackable, i just have doubts that someone is willing to spend enough time figuring it out.
 
These processors usually have two sides: one that is a standard ARM processor that runs a version of Linux, and one that does the specific programming (debayering, applying gamma curve and color transformations, encoding). Magic Lantern can do a lot of stuff with the first part, and just play with the available registers for the second part. Playing with registers, you can turn on options that are there but have been cut out by the manufacturer, but you can't create anything that is not already hard-coded in that part of the ASIC. If the processor is not designed for internal 4K, 10-bit, or 422, playing with the registers is not going to allow for those. And the ARM part is barely powerful enough to export RAW data, without any transformations.
 
caseywilsondp said:
Honestly once someone can figure out how the file system works and how some of the api calls get used, I don't see why we wouldnt be able to get slog3 or faster frame rates or even internal 4k. external 10 bit 422 will potentially be hardware limited, but i have no idea if it is or not.
I don't doubt whether the a7s is hackable, i just have doubts that someone is willing to spend enough time figuring it out.
Click to expand...
I don't see how anybody can get slog3 on the a7s, it didn't even exist when the A7S was announced, so it is not baked in. And it is not like there is a download link on the sony website, here is the log pp that we worked a year on, here you can download it for free.
 
Polaroid22 said:
I don't see how anybody can get slog3 on the a7s, it didn't even exist when the A7S was announced, so it is not baked in. And it is not like there is a download link on the sony website, here is the log pp that we worked a year on, here you can download it for free.
Click to expand...

Ironically i don't that that would be too hard, it's just a lookup - very simple math. But Samuel is right, these aren't generic programmable computers, a lot of the functionality is in hardware. So whilst you could potentially hack an android app on there and possible access undocumented api calls i think that would be super slow and limited (just judging by the way the apps function now, they're so slow).

To do a magic lantern would mean uploading a new piece of firmware, everything. And what the camera might be capable of is unknown. Doesn't magic lantern work by intercepting the RAW data and bypassing the debayering etc,. That would be interesting, because we know the camera can get the data off the sensor fast enough, so can this data be written to something or compressed and written so we could get RAW from the camera. That's where things get interesting, making the camera do less but optimise the pipeline for sucking just the data off. Do all your colour work in post. This isn't a market for Sony, they'd never do that as it takes someone with technical knowledge just to work with the images.

Now if *that* was possible it would be a game changer...

But i'm not sure anyone has decrypted the firmware, made a change, and installed it - that's the basis of a hack.

cheers
Paul
 
Magic lantern does a lot of things, and you need different milestones for each of them.

* In order to turn off options that are in the hardware-specific part of the processor but have been turned off (like: shooting slog2 at ISO 800 for cleaner shadows, maybe recording 4K 420 internal or applying slog3 if those options are implemented but disabled), it should be enough to get an APP in the camera (easy) that plays with the registers (getting access to them: not easy at all; finding what each register does: trial and error process, slow and dangerous because you can brick your camera when investigating what each one does).

* In order to record RAW: get an APP in the camera (easy) that gets the RAW buffer (getting access to that part of the memory: not easy at all; finding the buffer and making sense of it: not easy at all) and sends it out somehow (the SD slot may not be fast enough for 1080p24; it can also be sent through HDMI to an external recorder doing uncompressed, then process that stream in the PC to turn it into DNGs or something like that; this didn't work on Canon because they transform the images when they are sent through the HDMI, with sharpness and things like that, which destroys this just-a-long-string-of-ones-and-zeros RAW stream).

* UI improvements: do we need any? :)
 
Samuel H said:
Magic lantern does a lot of things, and you need different milestones for each of them.

* In order to turn off options that are in the hardware-specific part of the processor but have been turned off (like: shooting slog2 at ISO 800 for cleaner shadows, maybe recording 4K 420 internal or applying slog3 if those options are implemented but disabled), it should be enough to get an APP in the camera (easy) that plays with the registers (getting access to them: not easy at all; finding what each register does: trial and error process, slow and dangerous because you can brick your camera when investigating what each one does).

* In order to record RAW: get an APP in the camera (easy) that gets the RAW buffer (getting access to that part of the memory: not easy at all; finding the buffer and making sense of it: not easy at all) and sends it out somehow (the SD slot may not be fast enough for 1080p24; it can also be sent through HDMI to an external recorder doing uncompressed, then process that stream in the PC to turn it into DNGs or something like that; this didn't work on Canon because they transform the images when they are sent through the HDMI, with sharpness and things like that, which destroys this just-a-long-string-of-ones-and-zeros RAW stream).

* UI improvements: do we need any? :)
Click to expand...

The SD card might be fast enough, after all SDXC is a requirement already.

Apertus does the raw encoding over HDMI, it's a really neat idea. I wonder whether 4K RAW could be compressed down to the bandwidth of 1080 uncompressed. The O7Q can record 1080 uncompressed dpx frames so you can capture the data intact.

When i see someone showing a 3rd party accessing data from the camera, then i'll sit up a bit.

But to dump the contents of that sensor to storage ought not to be that hard (i really wish Sony would consider it)

cheers
Paul
 
Polaroid22 said:
I don't see how anybody can get slog3 on the a7s, it didn't even exist when the A7S was announced, so it is not baked in. And it is not like there is a download link on the sony website, here is the log pp that we worked a year on, here you can download it for free.
Click to expand...
What? Slog 3 has been around at least since the beginning of 2014, when did the a7s ship?
I doubt it's baked in anywhere, but if the a7s2 is as similar hardware wise to the 2 as it currently appears, it is feasible that it could be hacked and feasible that whatever is needed to figure out how slog3 works on the 2, could be made to work on the 1. Again that's all if anyone even wants to take the time to figure it out, which I doubt.
 
paulcurtis said:
I wonder whether 4K RAW could be compressed down to the bandwidth of 1080 uncompressed.
Click to expand...


1920x1080 422 8-bit uncompressed has 1920x1080 for luminosity, plus twice 1920x540 for color information, for a total of 31.65 Mb per frame, 760 Mbps at 24p (95 MB/s)

1920x1080 14-bit RAW is a total of 27.7 Mb per frame, 664 Mbps at 24p (83 MB/s)

3840x2160 14-bit RAW is four times as much: 111 Mb per frame, 2658 Mbps at 24p (332 MB/s)

And the ARM side of the processor would need to have a lot of power to do lossless compression on this.
 
if this hack is real i think the only way to progress in a significant way is open the hack for collaboration, magic lantern style.
 
arturochu said:
if this hack is real i think the only way to progress in a significant way is open the hack for collaboration, magic lantern style.
Click to expand...
True, maybe post it on the magic lantern forums, maybe they can be of some assistance or see if it is possible.
 
Samuel H said:
1920x1080 422 8-bit uncompressed has 1920x1080 for luminosity, plus twice 1920x540 for color information, for a total of 31.65 Mb per frame, 760 Mbps at 24p (95 MB/s)

1920x1080 14-bit RAW is a total of 27.7 Mb per frame, 664 Mbps at 24p (83 MB/s)

3840x2160 14-bit RAW is four times as much: 111 Mb per frame, 2658 Mbps at 24p (332 MB/s)

And the ARM side of the processor would need to have a lot of power to do lossless compression on this.
Click to expand...

3840x2160 grey scale (it's not been debayered) at 10 bit log? That would be 9.8Mb/frame though (i think!!). Wouldn't need to do anything but 14 bit linear to 10 bit log, pack those bits into the data stream. IMHO a lot less work than the camera does now. You push all the processing to the end of the pipeline is software.

Of course difficulty is that data stream would look like recording white noise on a recorder, so how do you preview what you're looking at!

Even if you didn't encode the signal and just record a grey scale bayered image, perhaps you could preview in B&W very simply. A small firmware change in a record could probably do that.

cheers
Paul
 
That's 9.8 MB, but 79 Mb.
In any case, I ran all my numbers with the same conventions, the bottom line is that 4K RAW needs much more bandwidth than 1080p 422 8-bit video. Even with 10-bit log (which is a transformation that may be too taxing for the ARM side of the processor), you are at 237 MB/s vs 95MB/s for the usual HDMI stream.
And yes, it would look like gibberish to the recorder, unless a firmware update allows it to preview it somehow (no need for BW, it can be a simple 3-for-1-and-discard-the-extra-green debayer to 1920x1080).
 
Samuel H said:
That's 9.8 MB, but 79 Mb.
In any case, I ran all my numbers with the same conventions, the bottom line is that 4K RAW needs much more bandwidth than 1080p 422 8-bit video. Even with 10-bit log (which is a transformation that may be too taxing for the ARM side of the processor), you are at 237 MB/s vs 95MB/s for the usual HDMI stream.
And yes, it would look like gibberish to the recorder, unless a firmware update allows it to preview it somehow (no need for BW, it can be a simple 3-for-1-and-discard-the-extra-green debayer to 1920x1080).
Click to expand...

Continuing the thought (dream?) experiment

HDMI 1.4 bandwidth is 10Gbs (checking the lowercase b now), this is what the A7s is.
HDMI 2 is 18Gbs (next generation)

But unless my math is wrong (possibly) i think that (rounded up) 10MB per frame of RAW sensor data, would easily get pushed down the existing HDMI system (1.2GB/sec)

Looking the other way the A7s is already throwing 8 bit YUV UHD up to 30fps, according to the AJA data rate calculator on my phone that's 0.5GB/second, that's twice what is needed.

So i don't think there's any issue with data rate limitations over HDMI, sending or receiving, am i wrong?

I don't think there's any big overhead in encoding log from a linear source, it's just a pre-calculated 1D LUT lookup, very very simple. The camera will be doing this already and more, right now it's debayering and doing colour transforms, we don't need any of that. IMHO it would run cooler as i believe it would be doing less.

Of course ideally you want it to be dumping this stuff to SDXC cards, but those data rates aren't enough are they? I think you get 90MB/s these days, which is not enough without some form of compression in the camera. So that would be the most challenging part of this.

Assuming any kind of access to sensor data is possible....

cheers
Paul
 
Of course, I forgot that! It's sending out UHD 422 8-bit, which is 126.6 Mb per frame, 3Gbps at 24p (380 MB/s) --> yes, current HDMI can handle the bitrate of 4K RAW 14-bit
One less problem to worry about. Now, how to find that buffer? XD
 
I dunno if this is true

https://twitter.com/nabfathi15

I'll see if i can contact him. But he might just be collecting followers. In his biog he says he's 3rd AD on Iron Man 2 but he's on imdb as an uncredited extra... Hmmm.

He's obviously go something working though, but it might just be access to headers in the firmware. I'm surprised at the amount of english language in that code though, it ought to be obfuscated and have that kind of data stripped out.

I suppose there's a glimmer of light...

cheers
Paul
 
You must log in or register to reply here.
Back
Top