Otto K

Samples 

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

It's hard to tell, the resolution is so low (~1%) that noise would be averaged anyway. Then again it probably has a different path in camera... 

I honestly doubt it. I think even mjpeg 4k would be huge improvement, but Vasile is more oriented towards video hacks, I'm more on basic and low level functionality as well as stills.  

@neosushi no chances at all, even stills mode 15fps are 12 bit images. 

OK, some advancements - namely a way to speed up applying mods as soon as the camera wakes up from sleep. See more here https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/doc/Boot_Process_and_Speeding_up_Mods.md

Also, a small poll and explanation:

If you don't want to do it from telnet, wait a few days, there will be a nicer, more automated way to do it.

If you are starting other things (bitrate hacks, whatever) - please do check if they are running already. You can use keyscan as test as it will return 0 only if it's not already running, like this /opt/usr/devel/bin/keyscan /dev/event0 /dev/event1 /opt/usr/devel/bin/ && my_program

Just to make things clear - it's not modifying the firmware.I have no intention to mess with firmware as I have no easy way to repair my camera.

We slightly tweak the "read only" rootfs (like we already do for BT hack - we just change a single line in script) and move our scripts from SD card to internal filesystem - the one mounted under /opt as "read write" by default. It's not going to brick a camera, I have even put a swap file to extend RAM on that filesystem and everything worked.

NB, I have been using and testing this for two days now - no side effects.

The main difference is that right now, when you pop out the SD card with mods and put in a clean one - your camera acts as if it was neved modded. With this it would be modded even without a SD card (ie, it would be modded with every SD card).

All modifications are fully reversible and would be reversible from aforementioned utility.

So, a small poll - do you want me to make an installer that will install mods to the camera internally in order to work faster?

Well, ASV is Adoptive Support Voltage and has 6 groups in NX1 (5 in NX500) so there's a complete group missing. Also, power delivery seems to be different even for two common blocks indicating probably different maximum power draw (frequency?). Such power constraints might be the reason for the crop.

Now, could we "overclock" it (or similar)? Who knows, but there still is the recording limit in place even when lifting "30 min tax" limitation (it's even present in 1080p60 at 25:00). I have done successive recordings with 4k for over an hour and it works without an issue but could cause issues in some corner cases.

The tricky thing is that we are examining what linux sees and it sees the same amount of RAM in both devices but the RAM difference is hidden from linux (and so might be the other IPs).

For people hoping that NX500 and NX1 have the same hardware, bad news, documented here https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/doc/NX1_NX500_hw_differences.md

TLDR - NX1 has more ove everything.

@Pavel MaÅ¡ek yes, I will make a usable gui in next few weeks (I first have to decide on what's best solution as it should be a single gui for everything, not just this "rooting"). 

Sorry, then it's a genuine bug, not something they just forgot to implement somewhere... 

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

You are not going to brick your camera this way. Also, bring another SD card - once you pop out your SD card with mods (or format it) the camera acts as it was never modded.

Best of luck shooting

Not all of the functions of st work, the st binary does hardly anything, it offloads it to other binaries (di-camera-app mostly) and libraries (various ones). 

Some of the functionality is not even declared in st but in di-camera-app, etc. 

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.

@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

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).

Syme is right. 

Edit - to clear things up - file managers will report sizes in base 10 (kilo is 10^3=1000) or in base 2 (kilo is 2^10=1024) but always in bytes, never in bits. 

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. 

50 minutes ago, RieGo said:

seems like that com.samsung.di-camera-app is something like the complete gui of the camera. at least it contains all icons and images.

so i'm currently taking a really close look at it as well 

too bad it's a compiled binary... 

 Actually, the user interface itself is stored in .edj files (like nx_style.edj) and can be extracted with edje_decc tool (but nx_style contains config.h file that lies outside of the allowed root directory so the decompiler exits). UI is a mix of images (icons, backgrounds, etc) and .edc files that are textual and describe the actual layout of the UI as well as the logic contained within (can contain even lua programs). Di-camera-app services signals from edje ui. 

@vaga it depends on the setting, but this tool is, IMHO, better for data gathering as it has access to things some others don't. Oh, and for backup. 

Interesting tool in firmware (at least on NX500): https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Prefman_tool.md

The issue is not with speed of SD card, it's just that swapon command complains about the file structure if it's on SD card (don't know why, it's works fine on my laptop with Linux). Either way, speed of swap is not important as it has to write around 500MB in over an hour. 

@SMGJohn that's not how rolling shutter works and nx1/nx500 have a separate hevc cpu (block). 

@Last Leaves is your card formated to exfat?