vasile

You may want to read this :-). Enjoy.

Well, I simply wanted to say that the di-camera-app does send the current NR parameters to the T-Kernel for execution, as part of the configuration parameters that are sent after pressing record button. This is consistent with the fact that the NR user interface is not specific to photo or video mode but it is in a common submenu. So if there's any dodgy stuff happening, it is in the T-Kernel. What I could use is to have someone make a test shot, twice, using early firmware (that a member of the board stated it did not have NR), and the firmware immediately following that. If he will convince you guys that indeed the earlier firmware did not have permanent NR turned on, I will look into the T-Kernel (but remember the mantra: no promises :-), I am only promising to look into it). And I need the comparative test to be done between successive firmwares in order to minimize the differences between them to narrow down my searches. The reason I stopped looking is two-folded: T-Kernel is a realtime kernel and cannot be debugged "live" making things a lot more difficult, and Since the di-camera-app does pass the NR to the T-Kernel, why should it ignore it? Does not make a lot of sense. So I am unconvinced that there is any "meat" in the "NR on" claims vs. the possibility that it is just the noise curve of the sensor, and this makes me a bit reluctant to pursue it given that the effort is likely to be very significant. Any takers? High/low pass discussion was basically waste of time. The references were in a section related to LCD. "NX500 does not have NR in UHD nor 4k video mode" - did you shoot in same conditions w/ and w/o NR and saw a difference? Can you post this for us to see? But it is not really comparable because on NX500 the UHD is pixel to pixel taken from the sensor whereas on NX1 there is some downscaling done which probably changes the end-result visible noise patterns.

No. They planned all along to update the Android app to MM compatibility, and took advantage of this ongoing (at the time) project to bolt on some additional things to annoy us. You cannot do a complex update like they did (MM communications) (and just look at the binaries they changed - many) on the back of the hand. Look how slowly they manage to update important hardware (how many of their flagship phones have moved to MM?). Do you think they would move faster on the NX than on their Galaxy devices? Do you really think a mod would piss them off enough to put resources in (starting from zero) to kill it? No way, and even if they did want it, they would not be able to do it in just a couple of months. IMO the MM update was on the roadmap from Sep/Oct, and they planned to start working on NX update once the Galaxy MM ROM's were in an "almost baked" state - that is, probably somewhere in Jan. Add to this the ramp-up time, tests, etc. and you get to May. It just so happened that the mods came when they had resources already working on NX and they could accommodate a bit of extra work just for us :-) without major changes to their schedule. just my 2 cts. Not me, I did not say that - @KinoSeed tested and reported. I am just starting to look into the bitrates. What I did state was that current mods do not work (and I said that because I saw the patched libraries change position in RAM) and then, after some preliminary tests showed that the DEV menu access seemed to disappear, I looked into it and discovered their handiwork - really interesting - on trying to disable access for us by hiding the new method of access. Remains to be seen exactly what and how they did to the bitrates and why KinoSeed was unable to relocate the patches (something that he did previously) - I am setting up my environment with partition dumps, etc. etc. so I can properly look for differences but cannot yet say anything about what they did to the bitrates beyond simply relocating the library. I will have more news this weekend.

Hi Dean, Thanks for this - if you like the new video bit rates :-) here's how you can help me get a 16-50S: http://goo.gl/7I67Rq kind regards

Two points: 1. this 2. If you want to know what me and otto are busy with, the most recent information can be found here. Bookmark it so you do not need to ask in the forum.

come on, Marco. They created a great camera, and just updated it when no one expected any more. We should stop bitching (I stopped) and get on to using it. Do you prefer the situation of last week today to the one of today? We'll eventually work around the restrictions (I hope) and if not, so what - we can keep v1.40 / v1.11.

This may also be of interest: http://***URL removed***/forums/post/57786472

This may be of interest: http://***URL removed***/forums/post/57785089

... and burner is burned :-( - that was quick :-( $&^%$

not yet, keyscan is killed in the process of updating the hibernation image. Please be patient, I received the burner so i am working on it.

Nope. This will require T-Kernel break-in and neither me nor any sane person would attempt this on anything BUT a burner cam. If burner cam available and significant effort/time then chance > 0. Nope. Kino Seed saw it in the kernel sources but from there to modding anything is like going from being me (hint: I am not a string theorist) to being a string theorist (like, for example, Sheldon Cooper). Comparison intentional because the fact that an interface (API) has been published does not mean it has also been implemented (just like Sheldon who has not yet discovered anything AFAIK).

Hi, please check second line of this. Kind regards.

Please take a look at the top of this - I am trying to keep it permanently up to date (not difficult :-). Kind regards. edit: If you want a bit of background about my work, take a look at this (download into Excel preferable):

Hi cisco150, Well, the effort is/was spread between various contributors (in temporal order of first contribution): Otto - initial break in the camera (through information gleaned from the NX500 service manual, which allowed access to a root shell); also various utilities that are enhancing the photo side of the camera as well as providing the user interface you can see used by various mod packs, and the bluetooth hook; low bitrate 2.5K mod for NX500. Myself: all my work to date was basically about video: access to DEV menu to (among others) disable video recording limits, high bitrates for all video modes for NX1 and NX500 and high bitrate for NX500 / 2.5K. I am also looking into other more difficult aspects of the camera operation but I won't comment about it because nothing came out yet. Kino Seed (and maybe others) - packaging and fine tuning the results of 1. and 2. above. If you would like to recognize the above work there's no one place for everything: Otto suggests you contribute to a charity as a recognition of his efforts. I am looking to get some more NX lenses (so far I am about 1/3 :-( of the way to my first wish (take a look here), and Kino Seed did not mention anything. In addition, you might pledge here to help make a camera available to me to (a) stop using my own camera for my investigations - two months of intensive research use resulted in a loose power button that needs replacement and (b) to enable some dangerous experiments for which I do not dare risk my own camera but which might benefit the user base - an example would be a permanent hook that does not depend on bluetooth and would be instantly available upon power on. Hope this helps regards

He he, I don't think it's a bug, it's a feature :-) Otto could not check whether the LCD is on or off in his programs without access to a NX1 to find out how - NX500 has no VF - :-) so he did his best under the circumstances... Just make sure you do any stuff which pops messages on the screen, while the screen is on and not while using the viewfinder.

(1) and (2): Some explanations. 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. 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. 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: 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. 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. Ideally, a mod should go through multiple stages: 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 internal when determined as safe for camera and changes are not so frequent 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

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

hope you find it useful ;-)

Well I cannot stop anyone from asking, but I will keep with my "no promise" vow. And "keep that in mind" does not constitute a promise BTW, in case you were wondering :-)

Ok did not realize more would be useful. Will keep this in mind.

Tonight's challenge for you all - see at end of this post:http://***URL removed***/forums/post/57665536 And a bonus: if you read the rest of that post you might also see some other interesting stuff... Vasile

http://***URL removed***/forums/post/57659433 http://***URL removed***/forums/post/57659433 regards :-)

in principle it is possible.

@vaga http://www.adorama.com/ISGNX1.html?utm_source=rflaid912994 $1199 doubt it, but might also, later on, release a complete resolution mod à la my bitrate mod.

But that is OK, if you could positively confirm that. The question is not whether they completely eliminated NR but whether they influenced NR. Actually an even better question is whether they make, right now, even a minor difference between high NR and no NR setting. Because if yes it might mean that the image is NR-ed before being encoded, and that Samsung imposes a floor NR level - that is, refuses to turn it completely off and limits it at say "low" for video, even if the setting might be "off".