Petition for Samsung NX1 hack

[Marco Tecno]

I still haven't tried the latest rev. Of the hack. Does it have problems with nx1, due to double ev press?

[SMGJohn]

4 minutes ago, Marco Tecno said:

I still haven't tried the latest rev. Of the hack. Does it have problems with nx1, due to double ev press?

Sort of, I do not like it causes issues with EV stays open and freezes everything and you gotta press two times to close the EV and the menu, it makes more sense to connect it to AEL which is never used by me and probably no one else or even the Fn, I am going to try remapping them when I get home.

[vasile]

http://***URL removed***/forums/post/57685081

[Geoff CB]

3 hours ago, sandro said:

How much is the focal length multiplier with DIS on?

I wish the higher bitrate would also allow a better low light performance. At least a ISO3200 without those horrible lines.

DIS only does ~1.25 additional crop. Not to heavy.

[shanebrutal]

8 hours ago, sandro said:

How much is the focal length multiplier with DIS on?

I wish the higher bitrate would also allow a better low light performance. At least a ISO3200 without those horrible lines.

 

5 hours ago, Geoff CB said:

DIS only does ~1.25 additional crop. Not to heavy.

In my testing I've found it to be around 1.15 additional crop. Maybe its adaptive to how much shake is going on? I did the test on a tripod and compared. 24mm with dis was equivalent to about 27.5 mm non dis. My test is not 100% accurate or scientific either.

When it comes to hacking maybe there is something in the code that defines the crop amount of DIS? I wonder if its just a digital crop or it its actually cropping in on the sensor. If it's sensor crop then maybe we can modify this to get a pseudo crop for extra telephoto and less rolling shutter  

[Marco Tecno]

6 hours ago, SMGJohn said:

Sort of, I do not like it causes issues with EV stays open and freezes everything and you gotta press two times to close the EV and the menu, it makes more sense to connect it to AEL which is never used by me and probably no one else or even the Fn, I am going to try remapping them when I get home.

the latest vs by kinoseed solves everything!

[kidzrevil]

@Marco Tecno whats the difference ?? is it more stable ? I'm currently using the bitrate v3 hack. The one without the gui cause the loss of use over the exposure button is not worth it to me. But 200 mbps is sure nice

[Marco Tecno]

kidz, the latest vs uses ev+ok to summon menu. and has no bugs,as far as I can say!

[kidzrevil]

@Marco Tecno you got the link ? I wanna try it out now !

[Pavel D Prichystal]

Ok, here are my findings from dodays shoot.

It slows down the camera. A lot. Like a lot lot! But most of us already know that right?
a) When the SD is clean + you have a lot of light + temperature is ok (around 22 degrees *C on the sun), it works beautifully for me at 190mbps with pretty budget card.
b) When the SD is filling up (30% and more filled up) + you are loosing good light (golden hour is dimminishing and you are pushing Iso from 100 to 200, 400,800,1250,2000..) + temperature drops (7-8 *C), it stops frequently. What worked with conditions a) is not working with b) anymore. The camera is getting slower (my opinion, nothing scientific), the card is stopping- this one is for sure and I had to drop it down from 190 to 165.. I wonder what is causing it?

Also:
Loading of script is slow. Really slow. When you run and gun, everything needs to be smooth, fast. And its not. There was a moment when the camera frozed, so I took out the battery, placed it in and got like purple error screen (Looked like when you drop your phone on the ground and the screen breaks, looked really bad). So I rebooted again and the script. Just takes a long time and when you are shooting in high cadency motion situations, those moments to load the script just feels like forever. And you are loosing a lot of time. Didnt had the time to check the files, not sure if recording before the script is loaded causes to record with previously modified bitrate or just standard Pro 80mbps.

Other then that: cadency is fixed,CTUs are better, more einformation is there.
The question is
- what caused the card to be so unstable in my todays recordings?
- Is there a way to make the script not slow down the camera so much?

[Marco Tecno]

9 minutes ago, kidzrevil said:

@Marco Tecno you got the link ? I wanna try it out now !

 

sure!

http://***URL removed***/forums/post/57686226

[Parker]

29 minutes ago, Pavel D Prichystal said:

Ok, here are my findings from dodays shoot.

It slows down the camera. A lot. Like a lot lot! But most of us already know that right?
a) When the SD is clean + you have a lot of light + temperature is ok (around 22 degrees *C on the sun), it works beautifully for me at 190mbps with pretty budget card.
b) When the SD is filling up (30% and more filled up) + you are loosing good light (golden hour is dimminishing and you are pushing Iso from 100 to 200, 400,800,1250,2000..) + temperature drops (7-8 *C), it stops frequently. What worked with conditions a) is not working with b) anymore. The camera is getting slower (my opinion, nothing scientific), the card is stopping- this one is for sure and I had to drop it down from 190 to 165.. I wonder what is causing it?

Also:
Loading of script is slow. Really slow. When you run and gun, everything needs to be smooth, fast. And its not. There was a moment when the camera frozed, so I took out the battery, placed it in and got like purple error screen (Looked like when you drop your phone on the ground and the screen breaks, looked really bad). So I rebooted again and the script. Just takes a long time and when you are shooting in high cadency motion situations, those moments to load the script just feels like forever. And you are loosing a lot of time. Didnt had the time to check the files, not sure if recording before the script is loaded causes to record with previously modified bitrate or just standard Pro 80mbps.

Other then that: cadency is fixed,CTUs are better, more einformation is there.
The question is
- what caused the card to be so unstable in my todays recordings?
- Is there a way to make the script not slow down the camera so much?

Yeah I also had a lot of issues with the latest mod today, messed around with it at my house and it worked great, but later this afternoon out shooting portraits for a client it was freezing like crazy while taking stills, the autofocus points would stay on the screen but the shutter wouldn't fire, I had to pull out the battery like 3 times before finally just uninstalling the hack.

[kidzrevil]

32 minutes ago, Pavel D Prichystal said:

Ok, here are my findings from dodays shoot.

It slows down the camera. A lot. Like a lot lot! But most of us already know that right?
a) When the SD is clean + you have a lot of light + temperature is ok (around 22 degrees *C on the sun), it works beautifully for me at 190mbps with pretty budget card.
b) When the SD is filling up (30% and more filled up) + you are loosing good light (golden hour is dimminishing and you are pushing Iso from 100 to 200, 400,800,1250,2000..) + temperature drops (7-8 *C), it stops frequently. What worked with conditions a) is not working with b) anymore. The camera is getting slower (my opinion, nothing scientific), the card is stopping- this one is for sure and I had to drop it down from 190 to 165.. I wonder what is causing it?

Also:
Loading of script is slow. Really slow. When you run and gun, everything needs to be smooth, fast. And its not. There was a moment when the camera frozed, so I took out the battery, placed it in and got like purple error screen (Looked like when you drop your phone on the ground and the screen breaks, looked really bad). So I rebooted again and the script. Just takes a long time and when you are shooting in high cadency motion situations, those moments to load the script just feels like forever. And you are loosing a lot of time. Didnt had the time to check the files, not sure if recording before the script is loaded causes to record with previously modified bitrate or just standard Pro 80mbps.

Other then that: cadency is fixed,CTUs are better, more einformation is there.
The question is
- what caused the card to be so unstable in my todays recordings?
- Is there a way to make the script not slow down the camera so much?

damn dude ! I just use the nx-bitrate-v3 one with double the bitrates. 160mbps with my sandisk extreme 64gb card works fine. 190-200 mbps is cool but by the time you hit 140-160 that's more than reasonable imo. I do a lot of run and gun as well and I noticed the freezing. I can't afford that on a paid gig. The client will certainly have my head on their wall if I missed valuable footage cause my cam kept locking up

[MountneerMan]

1 hour ago, shanebrutal said:

When it comes to hacking maybe there is something in the code that defines the crop amount of DIS? I wonder if its just a digital crop or it its actually cropping in on the sensor. If it's sensor crop then maybe we can modify this to get a pseudo crop for extra telephoto and less rolling shutter  

Yes please! This would be huge for me and my uses. a sort of loss less digital zoom/crop.   Range from 1.5x(std APS-C) to  about 2.4x.

 

I think we are just dreaming though.

[Marco Tecno]

Mountneer, it would be enough to enable on nx1 (AS AN OPTION) what on nx500 is the default cropped UHD.

[kidzrevil]

I like all these ideas being shared here. You never know maybe it will inspire an NX2 hahahah

[BopBill]

8 hours ago, Pavel D Prichystal said:

Ok, here are my findings from dodays shoot.

It slows down the camera. A lot. Like a lot lot! But most of us already know that right?
a) When the SD is clean + you have a lot of light + temperature is ok (around 22 degrees *C on the sun), it works beautifully for me at 190mbps with pretty budget card.
b) When the SD is filling up (30% and more filled up) + you are loosing good light (golden hour is dimminishing and you are pushing Iso from 100 to 200, 400,800,1250,2000..) + temperature drops (7-8 *C), it stops frequently. What worked with conditions a) is not working with b) anymore. The camera is getting slower (my opinion, nothing scientific), the card is stopping- this one is for sure and I had to drop it down from 190 to 165.. I wonder what is causing it?

Also:
Loading of script is slow. Really slow. When you run and gun, everything needs to be smooth, fast. And its not. There was a moment when the camera frozed, so I took out the battery, placed it in and got like purple error screen (Looked like when you drop your phone on the ground and the screen breaks, looked really bad). So I rebooted again and the script. Just takes a long time and when you are shooting in high cadency motion situations, those moments to load the script just feels like forever. And you are loosing a lot of time. Didnt had the time to check the files, not sure if recording before the script is loaded causes to record with previously modified bitrate or just standard Pro 80mbps.

Other then that: cadency is fixed,CTUs are better, more einformation is there.
The question is
- what caused the card to be so unstable in my todays recordings?
- Is there a way to make the script not slow down the camera so much?

This is the first version. It is faster than BT versions http://***URL removed***/forums/post/57559389

Currently I am testing Kino Seeds mod, but I don't know yet if it is faster than Vasile's  first version (just the bitrate hack)

Here Kino Seed explains little about the card speed and setting the bitrate http://***URL removed***/forums/post/57688493

 

[vasile]

12 hours ago, Pavel D Prichystal said:

(1) It slows down the camera. A lot. Like a lot lot! But most of us already know that right?

(2) Loading of script is slow. Really slow.

Other then that: cadency is fixed,CTUs are better, more einformation is there.
The question is
- what caused the card to be so unstable in my todays recordings?
- Is there a way to make the script not slow down the camera so much?

(1) and (2): Some explanations.

1. Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes.
2. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing.
3. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts).

Bottom line, there are several things someone will need to do before you will get better performance:

1. RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor.
2. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary.
3. Ideally, a mod should go through multiple stages:
   1. SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera
   2. internal when determined as safe for camera and changes are not so frequent
   3. once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed.

There you go.

Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).

This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).

Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.

It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.

Regards

Vasile

[sandro]

@kidzrevil I'm confused, if I stay at 150-160Mbit do these problem occur also? I mean freezes and stuff.

[kidzrevil]

@sandro not for me but you never know until you test it out. Im not talking about the hack with the gui btw