Otto K

People asked about possibility to switch between EVF and LCD during video (apparently not working on NX1). Since I have NX500 I cannot really switch anything but what is described here works as described
st app bb [lcd|evf|tv][on|off|osd|video]
For example, to show only clean video on back LCD: st app bb lcd video
To show only OSD (without video): st app bb lcd osd
To turn it off completely: st app bb lcd off
To show everything as normal: st app bb lcd on
Now, someone with NX1 could try and report back if these things work and if this can solve the problem of switching the LCD/EVF during video.
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Control_LCD_EVF.md

People asked about possibility to switch between EVF and LCD during video (apparently not working on NX1). Since I have NX500 I cannot really switch anything but what is described here works as described
st app bb [lcd|evf|tv][on|off|osd|video]
For example, to show only clean video on back LCD: st app bb lcd video
To show only OSD (without video): st app bb lcd osd
To turn it off completely: st app bb lcd off
To show everything as normal: st app bb lcd on
Now, someone with NX1 could try and report back if these things work and if this can solve the problem of switching the LCD/EVF during video.
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Control_LCD_EVF.md

Improved version now using BT to trigger running scripts from SD card (still modifies your rootfs):
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode_BT.md
Apparently this works on NX1 as well, Wifi does not.

Improved version now using BT to trigger running scripts from SD card (still modifies your rootfs):
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode_BT.md
Apparently this works on NX1 as well, Wifi does not.

Cross post from dpreview:
As promised I was working on alternative way to run scripts off the SD card without entering the factory mode (as it limits several functions important to me).
Full text here
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode.md
What it does: it modifies your root filesystem in camera so it starts a shell script from SD card (if present) every time you start WiFi.
Yes, it's rough. This is a first release just to enable everybody else to test and play around.
Touchscreen works.
Bluetooth works.
Camera works faster than in factory mode.
This might help with increased bitrate as well (don't know, can't test).
Have fun

@Pavel Mašek Yes, but this "hack" is not meant for general end users just yet (wifi was just the simplest test case I could find). It's more for people willing to experiment and confirm that it even works on NX1. I think this will work fine in future update when tied to bluetooth (as it can be set to be automatically started) plus it would give us an easy "Hack ON/OFF" switch.
Plus - this thing modifies your "read-only" root filesystem on camera - it's more invasive than SD card based mods. Beware.

Cross post from dpreview:
As promised I was working on alternative way to run scripts off the SD card without entering the factory mode (as it limits several functions important to me).
Full text here
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode.md
What it does: it modifies your root filesystem in camera so it starts a shell script from SD card (if present) every time you start WiFi.
Yes, it's rough. This is a first release just to enable everybody else to test and play around.
Touchscreen works.
Bluetooth works.
Camera works faster than in factory mode.
This might help with increased bitrate as well (don't know, can't test).
Have fun

Cross post from dpreview:
As promised I was working on alternative way to run scripts off the SD card without entering the factory mode (as it limits several functions important to me).
Full text here
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode.md
What it does: it modifies your root filesystem in camera so it starts a shell script from SD card (if present) every time you start WiFi.
Yes, it's rough. This is a first release just to enable everybody else to test and play around.
Touchscreen works.
Bluetooth works.
Camera works faster than in factory mode.
This might help with increased bitrate as well (don't know, can't test).
Have fun

Cross post from dpreview:
As promised I was working on alternative way to run scripts off the SD card without entering the factory mode (as it limits several functions important to me).
Full text here
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode.md
What it does: it modifies your root filesystem in camera so it starts a shell script from SD card (if present) every time you start WiFi.
Yes, it's rough. This is a first release just to enable everybody else to test and play around.
Touchscreen works.
Bluetooth works.
Camera works faster than in factory mode.
This might help with increased bitrate as well (don't know, can't test).
Have fun

Cross post from dpreview:
As promised I was working on alternative way to run scripts off the SD card without entering the factory mode (as it limits several functions important to me).
Full text here
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode.md
What it does: it modifies your root filesystem in camera so it starts a shell script from SD card (if present) every time you start WiFi.
Yes, it's rough. This is a first release just to enable everybody else to test and play around.
Touchscreen works.
Bluetooth works.
Camera works faster than in factory mode.
This might help with increased bitrate as well (don't know, can't test).
Have fun

Collection of small utilities for bash scripting added to github repo:
popup_timeout ["text message"] [timeout_in_seconds] - displays a popup message for a given number of seconds
popup_ok [message] [ok label] [cancel label] - displays a OK / Cancel dialog, returns 0 if OK, 255 if Cancel
popup_entry [message] [OK label] [cancel label] [sample entry] - displays an entry box with OK/Cancel buttons and prefilled sample text, returns entered text and 0 code for OK or just 255 for cancel.

Collection of small utilities for bash scripting added to github repo:
popup_timeout ["text message"] [timeout_in_seconds] - displays a popup message for a given number of seconds
popup_ok [message] [ok label] [cancel label] - displays a OK / Cancel dialog, returns 0 if OK, 255 if Cancel
popup_entry [message] [OK label] [cancel label] [sample entry] - displays an entry box with OK/Cancel buttons and prefilled sample text, returns entered text and 0 code for OK or just 255 for cancel.

Collection of small utilities for bash scripting added to github repo:
popup_timeout ["text message"] [timeout_in_seconds] - displays a popup message for a given number of seconds
popup_ok [message] [ok label] [cancel label] - displays a OK / Cancel dialog, returns 0 if OK, 255 if Cancel
popup_entry [message] [OK label] [cancel label] [sample entry] - displays an entry box with OK/Cancel buttons and prefilled sample text, returns entered text and 0 code for OK or just 255 for cancel.

Collection of small utilities for bash scripting added to github repo:
popup_timeout ["text message"] [timeout_in_seconds] - displays a popup message for a given number of seconds
popup_ok [message] [ok label] [cancel label] - displays a OK / Cancel dialog, returns 0 if OK, 255 if Cancel
popup_entry [message] [OK label] [cancel label] [sample entry] - displays an entry box with OK/Cancel buttons and prefilled sample text, returns entered text and 0 code for OK or just 255 for cancel.

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

Argh! I typed a silly long post and then hit backspace outside of this box and ... poof ... it's gone
OK, shorter version:
If you start telnet server as described and connect to camera you can do following:
killall dfmsd; sleep 2; dfmsd -p &
This will kill original dfms daemon and start a new instance that we can now use by dfmstool command that sends commands to daemon like this:
dfmstool -s "this is a command"
Be careful, as soon as it encounters an invalid command it stops processing all other commands so we need to do killall... to restart it (it does not affect the camera state).
The command we want is sys_param movie size 2560_1440_30p. Yup, it's still in the firmware, it has no crop and it supports peaking. Why they removed it from the menu I have no idea. It's labelled as MJPEG on screen but it records HEVC as others and is limited to 29:59.
dfmstool -s "sys_param movie size 2560_1440_30p"
Here's what ffmpeg has to say (I have to find a way to set the quality as well):
Stream #0:1(eng): Video: none (hvc1 / 0x31637668), 2560x1440, 11280 kb/s, 29.97 fps, 29.97 tbr, 120k tbn, 120k tbc
Oh, yeah, remember how there is no 1080p at 120fps in NX500? Think again:
dfmstool -s "sys_param movie size 1920_1080_120p"
And output of ffmpeg:
Stream #0:0(eng): Video: none (hvc1 / 0x31637668), 1920x1080, 38589 kb/s, 119.88 fps, 119.88 tbr, 120k tbn, 120k tbc
If you really want to you can put just the command in the nx_cs.adj file and call it a day (dfmsd will parse it and finish) or put a small script in test.sh that will do it for you (there is no touchscreen available while dfmsd is running). You could have SD cards for special video modes to simplify it.
For NX500 full list of modes is
4096_2160_24p
3840_2160_30p
2560_1440_30p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_15p
1280_720_120p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
For NX1, full list of modes is (yeah fractional ones too, don't know whether they are just for show or are there really differences between 24 and 23.98 when recorded)
4096_2160_24p
3840_2160_30p
3840_2160_24p
3840_2160_23_98p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_23_98p
1920_1080_15p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
Well, that's it for now, have fun

I've never seen a file manager report a file size in bits. It's always bytes. Computer hardware typically cannot even store or operate on a unit smaller than a byte independently. Megabits are almost exclusively used for data rates, not storage sizes.
Just to be sure I downloaded the files and checked them myself (on linux). Sure enough they are all at least 1 million bytes.
Therefore the correct calculation for the 2048x1152x15fps stream is 1.5*10^6 bytes/frame * 8 bits/byte * 15 frames/s = 180*10^6 bit/s, which is approximately 180Mbit/s.
Which is exactly what one would expect from typical JPEG compression ratios.

I have it, it's a great lens, but not really made for 3D. First you are limited to effective T/6 "aperture", reduced resolution and interaxial distance is around 6-7mm (based on very rough tests). It works, it's just not that great for 3D alone.