kinoseed

... does RS really matter? (we can't really change or make it better, can we?)
however, I don't know if it's just me, but looking at the great example @Geoff CB showed here, don't you feel like the effect is much higher at the acceleration points, and when the speed is stable, the effect is negligible ?

@Otto K, if you are interested if the 2.5K is line-skipping (which it looks it does), maybe the moire effect will be more telling (and maybe it could show how much skipping is does), but again, (how) can we use that info?

edit:
On a more positive note, last thing before the summer, I think we got two addresses which load LUT at recording start, so maybe we can modify and get those customized, however at the time I didn't recognize the format (they are not 3D LUTs).
And if we can find a way to read exposure levels maybe we can get the time-lapse to auto-correct the exposure, and completely automate it for sun sets/rises.

... does RS really matter? (we can't really change or make it better, can we?)
however, I don't know if it's just me, but looking at the great example @Geoff CB showed here, don't you feel like the effect is much higher at the acceleration points, and when the speed is stable, the effect is negligible ?

@Otto K, if you are interested if the 2.5K is line-skipping (which it looks it does), maybe the moire effect will be more telling (and maybe it could show how much skipping is does), but again, (how) can we use that info?

edit:
On a more positive note, last thing before the summer, I think we got two addresses which load LUT at recording start, so maybe we can modify and get those customized, however at the time I didn't recognize the format (they are not 3D LUTs).
And if we can find a way to read exposure levels maybe we can get the time-lapse to auto-correct the exposure, and completely automate it for sun sets/rises.

... does RS really matter? (we can't really change or make it better, can we?)
however, I don't know if it's just me, but looking at the great example @Geoff CB showed here, don't you feel like the effect is much higher at the acceleration points, and when the speed is stable, the effect is negligible ?

@Otto K, if you are interested if the 2.5K is line-skipping (which it looks it does), maybe the moire effect will be more telling (and maybe it could show how much skipping is does), but again, (how) can we use that info?

edit:
On a more positive note, last thing before the summer, I think we got two addresses which load LUT at recording start, so maybe we can modify and get those customized, however at the time I didn't recognize the format (they are not 3D LUTs).
And if we can find a way to read exposure levels maybe we can get the time-lapse to auto-correct the exposure, and completely automate it for sun sets/rises.

Give it a try, and let us know how it goes:
Mod-menu > Custom Func. > Mod Resolutions > (select) VGA as UHD
*note: if you have NX1, you need nx-ks v2.49
Set your camera to VGA, and check what comes out from the HDMI

To tweak the hdmi-out, you can execute the codes above (via telnet), and see if there's any (there may not be any) difference in the output.
 

Give it a try, and let us know how it goes:
Mod-menu > Custom Func. > Mod Resolutions > (select) VGA as UHD
*note: if you have NX1, you need nx-ks v2.49
Set your camera to VGA, and check what comes out from the HDMI

To tweak the hdmi-out, you can execute the codes above (via telnet), and see if there's any (there may not be any) difference in the output.
 

for recording - nope

if you think of using HDMI - no idea (and I can't test it here)
Change the VGA resolution, and see what comes out on the HDMI
you can play and change the HDMI output:

The possible settings are: 576P / 720P / 1080i / UD / UD_4K

st cap capdtm setusr HDMIOUT 0x350001
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_576P (0x350001)

st cap capdtm setusr HDMIOUT 0x350002
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_720P (0x350002)

st cap capdtm setusr HDMIOUT 0x350003
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_1080I (0x350003)

st cap capdtm setusr HDMIOUT 0x350004
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_UD (0x350004)

st cap capdtm setusr HDMIOUT 0x350005
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_UD_4K (0x350005)

for recording - nope

if you think of using HDMI - no idea (and I can't test it here)
Change the VGA resolution, and see what comes out on the HDMI
you can play and change the HDMI output:

The possible settings are: 576P / 720P / 1080i / UD / UD_4K

st cap capdtm setusr HDMIOUT 0x350001
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_576P (0x350001)

st cap capdtm setusr HDMIOUT 0x350002
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_720P (0x350002)

st cap capdtm setusr HDMIOUT 0x350003
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_1080I (0x350003)

st cap capdtm setusr HDMIOUT 0x350004
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_UD (0x350004)

st cap capdtm setusr HDMIOUT 0x350005
st cap capdtm getusr HDMIOUT
UserData is HDMIOUT_UD_4K (0x350005)

UHD at 50/60 fps was reported as possible only as HDMI output (via the VGA channel), however I have not personally tested it.

NX500/NX1 have programmable hardware and in essence you set up the hardware which resized the input for the encoder. We found the registers, but working with them directly is problematic as soon as you update part of the registers stream gets out of sync and drops out (outerbeat gets the credit for that one). Modifying the encoder's resolution can't be effective at all by itself, as no matter how you change it's recording resolution the feeding video will be already downsized. This at least should be quite clear.
You can change any resolution to any other (with NX-KS it was available even for the last firmware) as they in fact only shuffle the available resolution, so you don't set anything "real".

When it comes to MJPEG, something similar will be much easier achievable by setting  IPeriod: 1 (or 0?), thus forcing HEVC with I-frames only. This is something that I shared with the vasile more than a month ago, when there was still some illusion for cooperative work. ; )  My linux skills are far less advanced and takes me more time to figure some of the things, and this was not on my list.

cheers

NX500/NX1 have programmable hardware and in essence you set up the hardware which resized the input for the encoder. We found the registers, but working with them directly is problematic as soon as you update part of the registers stream gets out of sync and drops out (outerbeat gets the credit for that one). Modifying the encoder's resolution can't be effective at all by itself, as no matter how you change it's recording resolution the feeding video will be already downsized. This at least should be quite clear.
You can change any resolution to any other (with NX-KS it was available even for the last firmware) as they in fact only shuffle the available resolution, so you don't set anything "real".

When it comes to MJPEG, something similar will be much easier achievable by setting  IPeriod: 1 (or 0?), thus forcing HEVC with I-frames only. This is something that I shared with the vasile more than a month ago, when there was still some illusion for cooperative work. ; )  My linux skills are far less advanced and takes me more time to figure some of the things, and this was not on my list.

cheers

NX500/NX1 have programmable hardware and in essence you set up the hardware which resized the input for the encoder. We found the registers, but working with them directly is problematic as soon as you update part of the registers stream gets out of sync and drops out (outerbeat gets the credit for that one). Modifying the encoder's resolution can't be effective at all by itself, as no matter how you change it's recording resolution the feeding video will be already downsized. This at least should be quite clear.
You can change any resolution to any other (with NX-KS it was available even for the last firmware) as they in fact only shuffle the available resolution, so you don't set anything "real".

When it comes to MJPEG, something similar will be much easier achievable by setting  IPeriod: 1 (or 0?), thus forcing HEVC with I-frames only. This is something that I shared with the vasile more than a month ago, when there was still some illusion for cooperative work. ; )  My linux skills are far less advanced and takes me more time to figure some of the things, and this was not on my list.

cheers

NX500/NX1 have programmable hardware and in essence you set up the hardware which resized the input for the encoder. We found the registers, but working with them directly is problematic as soon as you update part of the registers stream gets out of sync and drops out (outerbeat gets the credit for that one). Modifying the encoder's resolution can't be effective at all by itself, as no matter how you change it's recording resolution the feeding video will be already downsized. This at least should be quite clear.
You can change any resolution to any other (with NX-KS it was available even for the last firmware) as they in fact only shuffle the available resolution, so you don't set anything "real".

When it comes to MJPEG, something similar will be much easier achievable by setting  IPeriod: 1 (or 0?), thus forcing HEVC with I-frames only. This is something that I shared with the vasile more than a month ago, when there was still some illusion for cooperative work. ; )  My linux skills are far less advanced and takes me more time to figure some of the things, and this was not on my list.

cheers

I guess some clarifications are in order.
NX-KS works with the new fw versions (1.12 / 1.41) for both cameras, and sets the bitrates as before, with one addition of 400Mbps for time-lapses.
@MountneerMan, vasile was never really part of NX-KS, from the very start I did uses his mod, but very soon after Otto made "poker" I started using that, which allowed for faster loading, and higher stable bitrates. Vasile, even tough apparently he obfuscated the bitrates and had to be "hacked" to be used with "poker" was given full credit.

Lets say that "falling out" is put mildly as there was never a "functioning team", often resulting him demanding of proof for this or that, like when I posted a very high-bit video, he demanded that I show him jump-table for a hack or give him credit for the video that I made, as "apparently I modified the bitrates using his spreadsheet" ... and so forth. Lets say the constant slander was almost a harassment.

When the new FW showed up, I gave him the new addresses, but the values were suspect, and after waiting a week for him to produce the new bitrates (as I suspected were different) he just said "they are the same" while apparently he's been working on his "mod". Well something didn't add up as the values from Samsung did not match Vasiles.
So I redid his hack, and found he had miscalculated the values 4 bits out of 8 bytes, (which was not critical in the end, but gave different values) maybe it was not from his calculations, but error from his obfuscation - no idea, didn't really care to check his work that much.

I can't speak of his new "mod", as I have not checked it, and don't intend to.
But since he didn't contribute anything for the latest NX-KS mod, and only made sure his work can't be really used as opensource, was enough to let him go and do his own thing, although teaming with Otto was great.

That about sums it up. : )

But of course I had to say Otto has my full respect!
He is the one that made it all possible.

I guess some clarifications are in order.
NX-KS works with the new fw versions (1.12 / 1.41) for both cameras, and sets the bitrates as before, with one addition of 400Mbps for time-lapses.
@MountneerMan, vasile was never really part of NX-KS, from the very start I did uses his mod, but very soon after Otto made "poker" I started using that, which allowed for faster loading, and higher stable bitrates. Vasile, even tough apparently he obfuscated the bitrates and had to be "hacked" to be used with "poker" was given full credit.

Lets say that "falling out" is put mildly as there was never a "functioning team", often resulting him demanding of proof for this or that, like when I posted a very high-bit video, he demanded that I show him jump-table for a hack or give him credit for the video that I made, as "apparently I modified the bitrates using his spreadsheet" ... and so forth. Lets say the constant slander was almost a harassment.

When the new FW showed up, I gave him the new addresses, but the values were suspect, and after waiting a week for him to produce the new bitrates (as I suspected were different) he just said "they are the same" while apparently he's been working on his "mod". Well something didn't add up as the values from Samsung did not match Vasiles.
So I redid his hack, and found he had miscalculated the values 4 bits out of 8 bytes, (which was not critical in the end, but gave different values) maybe it was not from his calculations, but error from his obfuscation - no idea, didn't really care to check his work that much.

I can't speak of his new "mod", as I have not checked it, and don't intend to.
But since he didn't contribute anything for the latest NX-KS mod, and only made sure his work can't be really used as opensource, was enough to let him go and do his own thing, although teaming with Otto was great.

That about sums it up. : )

But of course I had to say Otto has my full respect!
He is the one that made it all possible.

I guess some clarifications are in order.
NX-KS works with the new fw versions (1.12 / 1.41) for both cameras, and sets the bitrates as before, with one addition of 400Mbps for time-lapses.
@MountneerMan, vasile was never really part of NX-KS, from the very start I did uses his mod, but very soon after Otto made "poker" I started using that, which allowed for faster loading, and higher stable bitrates. Vasile, even tough apparently he obfuscated the bitrates and had to be "hacked" to be used with "poker" was given full credit.

Lets say that "falling out" is put mildly as there was never a "functioning team", often resulting him demanding of proof for this or that, like when I posted a very high-bit video, he demanded that I show him jump-table for a hack or give him credit for the video that I made, as "apparently I modified the bitrates using his spreadsheet" ... and so forth. Lets say the constant slander was almost a harassment.

When the new FW showed up, I gave him the new addresses, but the values were suspect, and after waiting a week for him to produce the new bitrates (as I suspected were different) he just said "they are the same" while apparently he's been working on his "mod". Well something didn't add up as the values from Samsung did not match Vasiles.
So I redid his hack, and found he had miscalculated the values 4 bits out of 8 bytes, (which was not critical in the end, but gave different values) maybe it was not from his calculations, but error from his obfuscation - no idea, didn't really care to check his work that much.

I can't speak of his new "mod", as I have not checked it, and don't intend to.
But since he didn't contribute anything for the latest NX-KS mod, and only made sure his work can't be really used as opensource, was enough to let him go and do his own thing, although teaming with Otto was great.

That about sums it up. : )

But of course I had to say Otto has my full respect!
He is the one that made it all possible.

I guess some clarifications are in order.
NX-KS works with the new fw versions (1.12 / 1.41) for both cameras, and sets the bitrates as before, with one addition of 400Mbps for time-lapses.
@MountneerMan, vasile was never really part of NX-KS, from the very start I did uses his mod, but very soon after Otto made "poker" I started using that, which allowed for faster loading, and higher stable bitrates. Vasile, even tough apparently he obfuscated the bitrates and had to be "hacked" to be used with "poker" was given full credit.

Lets say that "falling out" is put mildly as there was never a "functioning team", often resulting him demanding of proof for this or that, like when I posted a very high-bit video, he demanded that I show him jump-table for a hack or give him credit for the video that I made, as "apparently I modified the bitrates using his spreadsheet" ... and so forth. Lets say the constant slander was almost a harassment.

When the new FW showed up, I gave him the new addresses, but the values were suspect, and after waiting a week for him to produce the new bitrates (as I suspected were different) he just said "they are the same" while apparently he's been working on his "mod". Well something didn't add up as the values from Samsung did not match Vasiles.
So I redid his hack, and found he had miscalculated the values 4 bits out of 8 bytes, (which was not critical in the end, but gave different values) maybe it was not from his calculations, but error from his obfuscation - no idea, didn't really care to check his work that much.

I can't speak of his new "mod", as I have not checked it, and don't intend to.
But since he didn't contribute anything for the latest NX-KS mod, and only made sure his work can't be really used as opensource, was enough to let him go and do his own thing, although teaming with Otto was great.

That about sums it up. : )

But of course I had to say Otto has my full respect!
He is the one that made it all possible.

NX-KS has been available for the new firmwares for a few days now:
https://www.facebook.com/NXKS2/
(there is absolutely no need to stay with the old firmware)

I found it easier to shoot public if you wear an uniform or look like a tourist, I dunno why but people just automatically just ignore you.
You occasionally get children coming up to you though who wants to be on television, after a while its gets VERY annoying but its not like you can yell at them in the public.

Bulbramping (minus the need for a "bulb")
just keep in mind, that NX500 when in rolling-shutter mode will not do longer than 1/15 exposures
have fun

Doubt it.
Sharpening has nothing to do with the debayer, and there was only one such pattern in the kernel that I saw, and if you were right, there would be only 2 settings.
However the most common (and seems here is no difference) is the USM (hence the halos). And yes, even debayer is done in software. ; )
imho to avoid the USM use -10

cheers
 

Doubt it.
Sharpening has nothing to do with the debayer, and there was only one such pattern in the kernel that I saw, and if you were right, there would be only 2 settings.
However the most common (and seems here is no difference) is the USM (hence the halos). And yes, even debayer is done in software. ; )
imho to avoid the USM use -10

cheers
 

Doubt it.
Sharpening has nothing to do with the debayer, and there was only one such pattern in the kernel that I saw, and if you were right, there would be only 2 settings.
However the most common (and seems here is no difference) is the USM (hence the halos). And yes, even debayer is done in software. ; )
imho to avoid the USM use -10

cheers
 

Bulbramping (minus the need for a "bulb")
just keep in mind, that NX500 when in rolling-shutter mode will not do longer than 1/15 exposures
have fun

Bulbramping (minus the need for a "bulb")
just keep in mind, that NX500 when in rolling-shutter mode will not do longer than 1/15 exposures
have fun

Bulbramping (minus the need for a "bulb")
just keep in mind, that NX500 when in rolling-shutter mode will not do longer than 1/15 exposures
have fun