Pavel Mašek

Has anyone actually found where and how the SRP is used in the NX1 firmware? It would be a shame to spend a bunch of time learning how it is programmed only to find out that it's just something like an audio processor as in the Exynos SoCs the DRIMe-5 is based on. Seems to me like there's a pretty good chance Samsung just used the fast dedicated 4k HEVC encoder they were already developing for their cell phones. Their video encoders are famous for their efficiency, so if they were done with the design of their HEVC codec in time the smart choice would be to use less flexible hardware for the sake of battery life and heat.
I really hope it is being used for video encoding, since that would open the door to much more significant modifications (with a massive reverse-engineering and digital design effort). However I think the prudent first step is to figure out exactly what all it is doing in the camera. That's what I will be attempting to do once I have some time.

Could you please share this SDK with others? Maybe someone else would like to help with it.

There has been a few stating that they would like to tip/donate, which would of course be muchhelp,, as I seem to be doing this more than my 9-5 haha! But it is not at a quantifiable stage at the moment, What I have found out is pretty much just a key, and if the key can open the lock is not yet determined. Even with the sdk things of this nature are not 100% 
At any step of the way if they did something undocumented it can halt progress to a point the modification cant be done. Ive been lucky so far with things is all!

But if knowing that what Im doing may not bring a firmware mod to light people still wish to donate then I can put something together. But I started this not knowing there was anyone wanting this camera modded, and I would still do this if no one wanted to tip/donate.

That being said the next stages of what I am doing are copious research. There are white paper behind paywalls but my local university seems to have most of the books on file so I will be acquiring those to get a better idea of the way samsung chose to code.

Personally I am also interested in the lens mount for a working adapter to other lens systems. So the control files are something I am also looking into. As well as if hevc is the best choice for encoding or if something like the redcoderaw would be more suitable which is just their modded version of mjpeg2000. dct vs wavelet is something interesting to read about. 

I agree, if you are putting in a lot of work you deserve some form of compensation as everybody here will benefit should we get a breakthrough.
I would love to help, unfortunately the only thing i know about programming languages is 'how are you doing, world?"
 

I believe I have found the sdk for the srp. And quite a few examples of the c scripting style used before it is parsed into the machine state and binary. Working backwards it should be possible to figure out how it is compiled and explore what lies inside the system. It seems similar to an fpga so it shouldnt be very hard to dissect. Things that can be added over just changing the config files. Will update as I go. Keeping these updates short as I have a lot to do with making sure I fully understand the inner workings of this system.

guys im in a place call it cgpersia where there are a lot of people crack program like premiere element 3d etc etc..i can open 3d and ask to this people if can help us to do somethink to this camera....

Wow, nx1 Italian community! I feel less lonely now :-P 

Done as well! That's for getting this together 

If I may chime in here. The ideal interface for me would be to drop some files in the sd with names like 4KMax.config, 1080pMax.config for example. The GUI should just get all the file names that end in .config and show them as options. I pick one and the settings from within that .config file are applied. This way, the system could be made very flexible and extensible and people can share settings. The file should probably be in a human-readable format like json.
I am very interested in bumping up the HEVC bitrate to whatever maximum is allowed. I think that will improve the image quality a lot. My PCs have high end GPUs so I am not worried about decoding. I am prepared to contribute $$$ to the effort as well.
 
 

Ok, few short notes. 
First of all, there are two operating systems running, tizen and t-kernel based real time OS. What we see and can access is just a nice front end that issues messages to RTOS that actually does all the hard work. If some function is not implemented in it it's unfeasible for us. 
Regarding GUI - I'm working on it now and it's the most hostile toolkit I have ever worked with - EFL. Android is walk in the park compared to this hell.
As you can explicitly set readout to 120fps it either works slower (why?) or faster (240fps declared in the same NX1 launch event that also declared CGRA). 
Cpu cores are most likely based on 1600MHz A9. 

If i see it right (in the Chart) then the maximum Bitrate for the H.265 HEVC is at Level 5.1 (found this Level in the File-Infos of my NX1-Videos) 160.000 kbit/s, approximately 156 Mbit/s.
And interessting too, the maximum Frame rates:
c4k @ 60p
UHD @ 64p
an FHD @ 256p

The list of additions are interesting, I have to admit the focus will be on video and all other aspects will be secondary.
Found a few things. DRIMe-V clock rate seems to be 200mhz. And that seems.. low. Im expecting an NX1 in the next few weeks, so that is one thing I will test. May have to do some heat dissipation help, but from other things I have found in the fw that should be able to be pushed. If things are on the level of the sony a7(s) line up with their over heating issues I think a tad below that will suffice. The upper limit should be 700mhz+ But erring on the safe side will always be more logical.

**Edit** In additon to that finding, I will have to track the changes to see if they upped the clock rate in the later fw. I am working in the first revision as that has the largest file size, so I assumed it would have the most debug changes from the 1.0 layout, with the other firmwares focusing more on updates and camera usability changes.**
I wasnt intending to work on this tonight as I have some graphic design work I need to do, but the more I look, the juicer things get!

Absolutely agree with this one,
1. Most important - Higher bit rates is the thing we all need the most. Lets get rid of macroblocking and all sorts of problem.
2. Turn off the NoiseReduction - in my mind, the NR must slow eat a big chunk of processing power. If turned off, this power can be used elswhere.
3. 10 bit or 12RAW - I mean, honestly. You cant argue with this one.. 
4. Higher frame rates - is what makes the camera more appealing to us, but honestly, not more usable. Just makes it a better deal
5. Trying to disable crop 4K on NX500 and applieing 1 to 4 to NX500. That could make the camera more appealing to everybody. (not sure if we established already this is not possible?)

PS: Chant, as other stated, if you are dedicated to this task.. As other stated, dont be shy to ask for compensation or think of crowdfunding from us, if you plan to break in the camera and make it whole new better piece of tech.
 

Higher bit rate recording for 4K and 1080p (160 Mbps+) Higher frame rates (4K/60 fps, 1080p/240 fps) 2K recording mode and/or 4K crop mode similar to NX500 Ability to turn off noise reduction completely

When you produce results do not be shy to ask for donations, I think a lot of people are willing to support you financial including myself. 

Chant, great! Think that I've been asking for a NX1 hack since february 2015  Perhaps, in few weeks/months, you'll get there!!! I'm excited!

Depending on what I find there could be an option for a 1:1.29 lossless or a higher compression visually lossless hevc. Creating a custom lut for a more red like log seems possible also.
 The firmware seems more of a proof of concept that they left it open to change so many things. And more so to show they can go head to head with the established makers and make something better. Since this thread has garnered more interest I have shifted to put more hours into this dive I am doing.

When people talk about raw video I don't think they imply it at full native resolution of 28Mp, this would be insane. Look at 5Dm3 raw video for example, each frame is at HD resolution with 14bit of color information. So it's not true raw per say, but a downscaled raw instead. If we had video files with 14bit that would be perfect. No need for any kind of s-log tricks, which improve dynamic range but introduces banding and other issues after grading.

Ha, yes, we had some good interaction in that thread. And yes, for h265 you are probably correct. Prores on the shogun seems to care little between 0-255 and 16-235 once you actually grade the files. Sorry for this digression in this thread!
My main point earlier that I may or may not have made, is that increased bitrate will help us, particularly in h265 with things like macroblocking, unfortunately I doubt it will help us with banding (as 220mpbs+ already doesn't seem to get rid of it ala the shogun). while h265 is a very impressive codec, I'd really like to see something come along in the hack that will give us 422 (i really dont think hdmi out is 422 on this camera, but i have no evidence other than the terrible banding that still occurs). with gammadr and -10 contrast the camera is capable of a ton of latitude, it just can't be pieced back together in color without significant banding.

That test is totally outdated. With fw 1.4, NX1 improved SD writing times by a big margin. With a Lexar 2000x UHS-II card, I have a buffer for 35 frames at 15fps, after which it goes up to 5-6fps "forever". Meaning that it writes at about 200-250MB/sec (notice the capital B).
 
This is still too little for 25fps raw of course; but...NX500 implemented raw compression on the fly. I don't know how much this could save, but it's something already. Perhaps we could reach 8-10fps written directly to SD card.
 
NX1 also has USB3 connection. I really don't know if this can be used to connect an external unit, but if so, it could reach 600+ MB/sec, meaning about 20-24fps.
 
But the most likely scenario for raw video is the following: UHD crop (ala NX500). This would greatly reduce each picture size (less than 10MB each) and hence the lexar 2000x could already handle 20-25fps.

I think "just" 160/200 Mbits H265 would improve image a lot. But question now is not "how much" but "how"...:-)
 

I think it depends on everyone's taste - someone prefers dynamic range (and more filmic?), someone likes richer and more accurate colours. I have almost same settings as Casey... I did not make any scientific tests but my opinion is that (with this limited bitrate and 8bit codec) it is best solution to get best picture straight out of camera. But please - let's focus on hacking of NX1 in this thread... :-)

Answer on my email:
 
The NX1 is certainly under consideration.
We almost did it last year, and then Samsung started pulling that camera from the shelves. 
It isn't sold in these parts anymore.
 
This is in discussion, but I can't promise anything at this stage.
We've had quite a few requests for this camera in the last week so hopefully we can push that through.

But RAW image has to be scale down because bitrate would be insane in this case (24x around 30MB = 720MB/s). Maximum write speed of NX1 is 60MB/s (see http://www.cameramemoryspeed.com/samsung-nx1/sd-card-comparison/ )

But RAW image has to be scale down because bitrate would be insane in this case (24x around 30MB = 720MB/s). Maximum write speed of NX1 is 60MB/s (see http://www.cameramemoryspeed.com/samsung-nx1/sd-card-comparison/ )