[ewelot]

If I remember correctly there were additional NR settings in the debug menu.
If PK-Tether works with the K5iis then you could try accessing it.

Pk-Tether seems to work (partially) with this camera (see here). I didn't try it by myself.
The NR settings available to the user that I know of are "High-ISO NR" and "Slow Shutter Speed NR". What do you mean by the debug menu and what is it used for? If this is going to be rather Pk-Tether specific I would kindly suggest to post to the forementioned thread. I'd happily discuss it there with you.

[smigol]

The debug menus allow some manufacturer level options to be controlled in the camera sometimes via new menu options on the LCD or via a text file on the SD card. This has been a slow process of discovery as there has been little documentation on the capability of this function. For instance, it's only been recently found that lens-based firmware can be rewritten via these debug files. It may be possible that NR controls could be enabled via this process.

EDIT: In looking at the SYSPARAM options on the pentax-hack site, I see DISABLEBLC for Disable black level correction.

I think that this will be the focus of what to look at next. I'm not sure if the correct MODSET file name has been found for the K5IIs.

Another update: I tried adding the DISABLEBLC to the SYSPARAM file for the K10D and it did turn off the resetting of the black point for all shots. I see an average ADU of 500 or so. The shape of the histogram is not clipped. Looks like I have some work ahead of me to rebuild the library of darks I have already. I'm very excited about what I can do with this camera now. The major disadvantage of the debug mode is that it forces the LCD to be on all the time. This wears down the batteries -- not a problem if you have an external power source -- and it generates a lot of heat -- which is a big issue.

One last update: While I see that the DISABLEBLC does stop the truncation of the data, there is a problem with it leaving the data susceptible to clipping on the high end. Also, white balance is completely trashed, as expected. If possible, this may be a setting that is used solely for recording darks and bias signal with minimal clipping. Not sure where this leaves the K5IIs.

[ewelot]

The debug menus allow some manufacturer level options to be controlled in the camera sometimes via new menu options on the LCD or via a text file on the SD card. This has been a slow process of discovery as there has been little documentation on the capability of this function. For instance, it's only been recently found that lens-based firmware can be rewritten via these debug files. It may be possible that NR controls could be enabled via this process.

EDIT: In looking at the SYSPARAM options on the pentax-hack site, I see DISABLEBLC for Disable black level correction.

I think that this will be the focus of what to look at next. I'm not sure if the correct MODSET file name has been found for the K5IIs.

Another update: I tried adding the DISABLEBLC to the SYSPARAM file for the K10D and it did turn off the resetting of the black point for all shots. I see an average ADU of 500 or so. The shape of the histogram is not clipped. Looks like I have some work ahead of me to rebuild the library of darks I have already. I'm very excited about what I can do with this camera now. The major disadvantage of the debug mode is that it forces the LCD to be on all the time. This wears down the batteries -- not a problem if you have an external power source -- and it generates a lot of heat -- which is a big issue.

One last update: While I see that the DISABLEBLC does stop the truncation of the data, there is a problem with it leaving the data susceptible to clipping on the high end. Also, white balance is completely trashed, as expected. If possible, this may be a setting that is used solely for recording darks and bias signal with minimal clipping. Not sure where this leaves the K5IIs.

That's very good news! At least for your camera. Unfortunately from what I read there is currently no known MODSET file name for the K5IIs.

[smigol]

I'm not 100% sure that the modset file is needed once you enable debug mode with some other tool. You could try the SYSPARAM file and see what it does for you. I had to completely power off the camera (remove battery) to switch the debug off to clear the temporary settings.

For what it's worth, I did some testing of darks and bias at different temperatures.

From left to right the images increase in duration: bias, 1/125 sec, 10 second, 30 second, 5 minutes, 20 minutes

Note the shape of the histogram and compare with the truncated version and it's also interesting to see the ranges of the standard deviation and the lowest value. What I'll probably do is run the a collection of darks at different temperatures and see what the lowest value becomes. Once I have a profile, I'll probably switch off this feature and use the camera normally.

Attached Images

         

[Gimbal]

Once I have a profile, I'll probably switch off this feature and use the camera normally.

This might be a stupid question, but is a dark frame usable with a light frame if they have different noise distributions?

[ewelot]

This might be a stupid question, but is a dark frame usable with a light frame if they have different noise distributions?

Any light frame with a level of just a few counts above dark level will have a noise distribution without truncation - regardless of using normal camera operation or beeing set to debug mode. What we need in the image reduction process is a master dark which has all intrinsic structures/patterns preserved to be able to remove those from the light frame. Of cause, dark and light frames have to be taken at same conditions (mainly ISO, temperature, exposure time). The noise distribution will be different (in terms of variance) because with any light frame you are adding shot noise as well.

Stephen, the way to get the master dark done you describe is exactly what I would suggest too.

[Gimbal]

Any light frame with a level of just a few counts above dark level will have a noise distribution without truncation

Ok, so if I add a couple of stars there is no truncation even in bulb mode. Weird.

[ewelot]

Back again on this topic because there is really good news I should spread around ...

First I spent a little time in testing the remote control program pktriggercord and the author has kindly added support for both K-5 II and K-5 IIs lately - thanks a lot Andras! Just grab sources from svn and give it a try.
Next I adopted the relevant pieces of code to my astro image acquisition program and tested it just a few days ago. And when analyzing first bulb exposure data I found - to my big surprise - that the black point issue didn't show up and dark frames exhibit a nice gaussian intensity distribution! It appears that accessing the in-memory raw image data of the camera via PC control software offers data at a less processed state and - most importantly - the image pixel mean intensity is not shifted to zero level.

Side note: There are more differences between images stored on SD card in the camera and in-camera in-memory images, e.g. I notized different image dimensions where in-memory images keep several additional rows of unexposed sensor area data at bottom of an image.

The bottom line of this means: if you are going for deep-sky astrophotography and stacking of many long exposures (or otherwise need the unaltered noise distribution of raw image data) you should access in-camera in-memory images via PC control software. That's it!

[jbinpg]

Thanks for the pktriggercord tip. Latest version works fine on my Ubuntu 13.04 laptop with K-30, K-5 and K-5 IIs. Only thing is by default the USB device is owned by root so you have to launch via sudo but that is no biggee. Will have to see if/how it works with the O-GPS1.

Jack

[jbinpg]

After a bit of experimentation, it is clear that using Liveview with pktriggercord leads to immediate hard lock of both the camera and the laptop. So using pktriggercord with the O-GPS1 is a no-op.

Jack

[ewelot]

Thanks for the pktriggercord tip. Latest version works fine on my Ubuntu 13.04 laptop with K-30, K-5 and K-5 IIs. Only thing is by default the USB device is owned by root so you have to launch via sudo but that is no biggee. Will have to see if/how it works with the O-GPS1.

Jack

No, you don't need to be root. Just install the provided udev rules files (via make install or manually). On Ubuntu systems (at least 12.04 which I have running on a laptop) I'd recommend to name it with higher number prefix, e.g. 95_pentax.rules, which means that the rule is applied later (and therefore with higher priority). Additionally I prefer to set MODE="0660" in the rules files to really limit read/write access to members of the group plugdev. Not a big issue - just my 2cents tip.

Thomas

[jbinpg]

Thanks, Thomas. Renaming the rules file to 095 did the trick.

Jack

[smigol]

This looks rather promising! I want to see if the same effect is noticed with my K10D.

I tried loading the software to my astrophotography computer (Win XP netbook). After installing the GTK2 runtime installer and theme pack, the pktriggercord throws an error at gtk_range_get_value: assertion `GTK_IS_RANGE (range)' failed.

Looks like there's a mis-match between the latest GTK 2 installer and what the pktriggercord software wants. I'll try again when I have the chance.

[ewelot]

This looks rather promising! I want to see if the same effect is noticed with my K10D.

I tried loading the software to my astrophotography computer (Win XP netbook). After installing the GTK2 runtime installer and theme pack, the pktriggercord throws an error at gtk_range_get_value: assertion `GTK_IS_RANGE (range)' failed.

Looks like there's a mis-match between the latest GTK 2 installer and what the pktriggercord software wants. I'll try again when I have the chance.

Stephen, I'd recommend using pktriggercord-cli for quick testing. That is the command-line version which comes with the windows zip archive and does not require GTK libraries. To capture a single image with current camera settings you could e.g. run the command

Code:

pktriggercord-cli -o test.pef

.

Thomas

[bobD]

Sorry to revive an old thread.

Having searched for several days this is the first thread I've found where with contributors having such high level insights into the workings of tethering, Linux, and Pentax..

I have recently acquired a K10D that I need to run tethered using Linux. (Ubuntu)
Unfortunately it will not work with Pktriggercord nor the much older Pkremote.
I had suspected a GTK problem, as smigol had noted with their K10D, until I tried my K200D with the same set up and it worked just fine.

I suspect that, with K10D firmware 1.20 and beyond, the introduction of compatibility with Pentax's own 'Remote Assistant software has broken the Linux operability somehow.

My K10D is running firmware 1.31 which can no longer be downgraded and so I cannot test this.

Pktether does work without any problems but can't be run using Wine (no usb support)
I have tried running it using WinXP in Virtualbox on Ubuntu but there seems to be a known issue in VBox where their claimed usb 2.0 only transfers at 1.1 speeds. This then is also not a workable option.

Has anyone suggestions ?
or light to shed upon this conundrum ?
Comments most welcome..(excepting.."buy a new camera" )