Pixel Shift results export

Submitted by John Malik on

Forums: 

Hi,
there is a camera which takes four pictures at full resolution each shifted by a subpixel and computes JPGs not needing any Debayering, the Pentax K-3II. This is somewhat related to Foveon technology.
The resulting Raw files DNG and PEF contain 4 subdatasets accordingly.

Would it be possible to:
a) access any of the 4x raw data in the raw files (I think current rawdigger grabs the first one and ignores the rest)?
b) more importantly export full resolution tiff files for each RGGB color which are assembled from the four individual parts? These then would not need debayering.

Sample raw files for testing purposes can be found here:
http://www.pentaxforums.com/forums/172-pentax-k-3/296122-k3ii-pixel-shif...

Dear John,

Submitted by lexa on

Dear John,

thank you for the link to the samples, this is 1st one we have.

After quick examination of EXIF/DNG/PEF metadata: the data from four shots are stored as separate images within both DNG and PEF files, so both options
 - inspect separate planes
 - or join planes on file read
are possible.

Unfortunately, only one option may be implemented without deep changes of RawDigger internals (because RD do not support image joining/stitching on export phase) and now we do not know how we'll do it.

For image/raw data inspection (RawDigger main goal), four separate planes (selectable via frame #) is preferred. For 'raw conversion' (but RawDigger is not Raw Converter), four planes should be stitched.

We need more time to think about it.

RawDigger supports Pentax 4

Submitted by lexa on

RawDigger supports Pentax 4-shot files since version 1.2.0

To merge 4 shots into one raw representation, you'll need to turn on Preferences - Data Processing - Vendor Specific - [Pentax K3-II section] - Merge data for 4-shot frames.

RawDigger Research and Profile editions are able to export data as TIFF file as 3- or 4-channel TIFF.

DNG creation is not supported by RawDigger.

K1 TIFF Export

Submitted by Jack Hogan (not verified) on

Lexa,

I assume that when one exports to TIFF a raw channel from a K-1 pixel-shifted capture (with the proper box checked in preferences) one gets the fully populated channel with all the pixels in the right place. Is this correct?

If so, what do you think about the GIF animation at the bottom of this thread (ignore the rest)?
http://www.dpreview.com/forums/post/57766628

Jack

For some unknown reason, my

Submitted by lexa on

For some unknown reason, my Firefox browser do not show anything animated in bottom of post you link.

BTW, DPR's K1 pixel-shift files looks far from perfect for me. Files downloaded from Imaging-resource shows much more difference between single frame/merged image, while DPR's ones looks blurry. May be weak tripod or shutter-shock or something like it.

And, yes, export of single raw channel will export fully populated for 4-shot merged image and not populated (see export options: 2x2 or holes or half-size) for bayer one.

Here is comparison (Red channel from IR image): https://www.dropbox.com/s/t5umkyx0c2azcw5/K1hSLI000100_PSR-RAW-R4.png?dl=0

Please note, that you need to re-open image in RawDigger if you change 4-shot processing option (we'll change it to auto-reload on change in 1.2.11 release)

Problem with the beta version

Submitted by Nick Hawkes (not verified) on

Hi,

I've been having the discussion with Jack on DPReview regarding the K-1 pixel shift images. I downloaded the OSX beta for the Rawdigger version that supports K-1 pixel shift, but what I'm seeing in the preview looks like it isn't rendering correctly. I've changed the preference setting as instructed and reloaded RawDigger, but that didn't fix the problem. The K-3ii pixel shift image I've tried seems to be rendered correctly. Are there other preference settings that need to be set to render the K-1 correctly in the beta version?

FYI, I only have the basic version of RawDigger, so I can't output TIFFs and check them to see if the problem is just in the viewer. However, I've taken a couple of screen grabs and posted them here:

http://www.dpreview.com/forums/post/57770693

As you can see the composite display of the K-1 is rendered very oddly. There's also lots of aliasing and false color in the RGB rendering.

Thanks.

Dear Sir:

Submitted by lexa on

Dear Sir:

K3-II and K-1 images are processed exactly same way in RawDigger, no logic based on model name (fortunately, pixel shift order/direction is same in these models).
The only difference is file auto-reopen after Preferences->merge data for 4shot changed: the K3-II image to be reread/reloaded automatically, while K-1 is not, so you need to go to Recent files - last file to re-open it.

The thing one need to check is real image sub-frames shift in DPR files. If sub-frames are not shifted exactly to 1 pixel (due to shutter shake or weak tripod), merged result will be bad

Thanks for the response. It

Submitted by Nick Hawkes (not verified) on

Thanks for the response. It appears to me that my viewing problem is not unique to the pixel shift K-1 image from DPR. I see very similar false color/moire and aliasing when I load the resolution chart shots from Imaging Resources for the Nikon D810 and D800E. The problem looks like a really bad demosaicing algorithm was used with lots of colored checkerboarding in the converging lines of the resolution chart. Since Jack Hogan and (I think) Iliah Borg are not seeing the same problem I'm having with the K-1 and now I've discovered similar behavior for several other cameras, I'm thinking there's something amiss with my RawDigger configuration. Do you have any suggestions on what settings I should experiment with in Preferences? I've tried tweaking a number of them but to no avail so far. (Please let me know which changes would require a reload of RawDigger to take effect.)

FYI, I'm using OSX, the Exposure Edition of RawDigger and the beta version that you linked to in your exchange with Jack Hogan for support of the K-1 pixel shift.

Thanks again!

Dear Sir:

Submitted by Iliah Borg on

Dear Sir:

RawDigger is not a raw converter, and the composite/RGB preview is more of a tool to know what the image is, and where to place selections and samples.

As to K-1, we are stydying the issue.

There is no need for demosaicking in pixel shift mode, neither for K-3 II, nor for K-1, as the raw date in this mode is already composite, all colours are captured for all pixel locations.

I do not think something is wrong with your configuration.

--
Best regards,
Iliah Borg

The GIF animation works for

Submitted by Steve Sprengel (not verified) on

The GIF animation works for me if I open the View: Original Size link in a new tab. The reduced-size preview embedded in the reply, isn't animated.

Add new comment