[Glorfindelrb]

The TCSTV example was done with motion correction on. We had been told repeatedly that it was possible to use use PixelShift in these scenarios, and we were obviously underwhelmed by the Lightroom results. As you can see, the Pentax Software does the job properly. Just trying to spread the word so photographers weren't stuck thinking the subpar Adobe results were as good as it gets.

Yes obviously the result in skylpix is good so no reason to restrain yourself to use PS. Thanks for this example Jordan.

[TCSJordan]

Are you shooting DNG or PEF files? I imported my DNG Pixel shift samples into Lightroom and didn't have any problem - they look good.

Everything we shot was DNG. Try importing your DNG files into SilkyPix and see if the results are better, I suspect they will be.

[Class A]

We had been told repeatedly that it was possible to use use PixelShift in these scenarios, and we were obviously underwhelmed by the Lightroom results.

It is possible to use PixelShift in these scenarios but note that this is realised by not using the PixelShift processing for any area in which movement occurs.

In other words, anything that moves is rendered with standard Bayer-AA resolution. Only non-moving parts benefit from the PixelShift approach.

Of course, PixelShift with automatically accounting for movement is still a very nice feature, saving one the effort to do the respective compositing and masking manually.

It would be interesting to see how LR compares to PDCU for static subjects.

[Rondec]

I said in the other thread, but will say here too, that I have found best results shooting pixel shift with DNG files, running them through DCU to create TIFF files and then doing any final adjustments in Lightroom. Particularly for images that require motion control version of pixel shift, it seems to do a lot better.

The other option, as Adam mentioned, is just to shoot jpegs. But your ability to post process those will be limited significantly by the fact that jpegs do throw away a lot of information in their creation.

[joostdh]

Has anyone noticed any issues with pixelshift images and lightroom?

I have. See the same image below which illustrates the problem well. I actually added some red to the shadows in LR via Split Toning to make it less blue than it was! In both images there is some local adjustment on the eye (clarity, lightening) and the RAW had some additional general lighting correction.

This is what Lightroom did with a pixel shift RAW:


And here is the same photo but then taken from the in-camera JPG:

[dakight]

Are you shooting DNG or PEF files? I imported my DNG Pixel shift samples into Lightroom and didn't have any problem - they look good.

Always DNG.

[phoebus]

It almost looks as if LR is taking the 4 DNGs and adding the RBGG pixel data additively, giving double weighting to the green info. Would that explain the strange colour shift?

But then should the white background also have a green tinge??

Just a thought, anyway.

From a scant test LR certainly doesn't do motion correction as well as DCU (if at all).

[Not a Number]

TheCameraStore in Canada posted a field test video of the K-1.

You Tube

You Tube

The Horror! The Horror! They took pixel shift shots of running water scenes.



They also add a note that at the moment Lightroom doesn't process pixel shift properly but will process non-pixel shift RAW file perfectly fine. It looks to me that Lightroom doesn't handle Motion Correction. It might be interesting to turn off MC but keep Pixel Shift on and see if Lightroom handles those.

[Mock]

I've installed DCU now, I only have pixel shift examples with motion correction off. DNG files. Comparing it to the latest LR update 6.5.1

Contrast and saturation in an image containing a lot of green are more pleasing in DCU than LR looking at them from a default non-edited state, or looking at it another way - the files in Lightroom seem more "flat" and need help. However, I don't have anything as dramatic as the differences portrayed by TCS. In LR, They need a bump in contrast, and a little shift in white balance away from green in cases where the subject has lots of green. This doesn't occur with non-pixel-shift images, those are identical in DCU and LR.
Detail seems to be identical with the pixel-shift images in either program.

An example with lots of red/magenta by comparison fares much better in LR, in my opinion. The DCU default is over-saturated and would need to be dialed back. So I'm not seeing the kind of dramatic differences others are experiencing, I'll need to try some shots that require motion correction, since obviously the water-shot above is unacceptable. Here are the default images side-by-side out of each program, click-through for higher resolution:

[Mock]

Okay, did one with motion correction. Look what Lightroom did to this poor duck!



One more dramatic example, moving subject on the river. phoebus already said it, but I think DCU is actually doing the thing properly and only taking one set of pixels from the moving areas, while LR is averaging out all 4. It can handle pixel shift images fine, just not ones that require motion correction.



Neither of these were done on a a tripod, just braced partially against a hard surface (railing, then rock). Don't pay any attention to what should be the static areas of the scenes, since I moved ever so slightly during the shooting.

One more edit...found the button for turning off MC in DCU. Turn it off and you get something like the LR result.

[mooobr]

Ok, the Pentax software (in camera, PDCU) can very well correct for the movement in Superresolution images by droping the superresolution in moving areas, whereas Lightroom not. Allright, it's good to know.

But I think the real question here is how to use the PixelShift sensibly, so that you not only inflate the file size, but also gain from it.
If you take a picture, where 70% of the picture is moving, e.g. a river, you'll gain some extra pixels for trees in corners and stones that are not washed by water. It probably depends on what you expect from your picture and if you are going to make a large print and say: "Hey, look at this stone and its resolution!"
Or if your only object in focus is moving, and will probably be corrected in favor of a single bayer frame, you just get a pixel-precise bokeh, which will likely be very difficult to tell from that non-PixelShifted.

However, I think that the original purpose, why they'd implemented it, is when you are up for landscape shooting with PixelShift... in windy conditions. As the slightest breeze can cause you artifacts and pain, it is very helpful, if this is already taken care of by the software.
Or I could imagine scenarios, where everything but what you are interested in is moving, like in object tracking (probably bad example, as you are not going to track precisely enough) or when your background is moving - like pictures taken inside a moving vehicle, boat...

But this makes me raise a question, whether it is possible to get good (or at least some) results with handheld PixelShift with K-1 and its 5-axis stabilisation? I was able to get sharp handheld images with K-3 II and a 16mm lens even at shutter speeds of 0,3-0,5 s. The keeper rate was something like 15%, but still...

[dakight]

Ok, the Pentax software (in camera, PDCU) can very well correct for the movement in Superresolution images by droping the superresolution in moving areas, whereas Lightroom not. Allright, it's good to know.

But I think the real question here is how to use the PixelShift sensibly, so that you not only inflate the file size, but also gain from it.
If you take a picture, where 70% of the picture is moving, e.g. a river, you'll gain some extra pixels for trees in corners and stones that are not washed by water. It probably depends on what you expect from your picture and if you are going to make a large print and say: "Hey, look at this stone and its resolution!"
Or if your only object in focus is moving, and will probably be corrected in favor of a single bayer frame, you just get a pixel-precise bokeh, which will likely be very difficult to tell from that non-PixelShifted.

However, I think that the original purpose, why they'd implemented it, is when you are up for landscape shooting with PixelShift... in windy conditions. As the slightest breeze can cause you artifacts and pain, it is very helpful, if this is already taken care of by the software.
Or I could imagine scenarios, where everything but what you are interested in is moving, like in object tracking (probably bad example, as you are not going to track precisely enough) or when your background is moving - like pictures taken inside a moving vehicle, boat...

But this makes me raise a question, whether it is possible to get good (or at least some) results with handheld PixelShift with K-1 and its 5-axis stabilisation? I was able to get sharp handheld images with K-3 II and a 16mm lens even at shutter speeds of 0,3-0,5 s. The keeper rate was something like 15%, but still...

Since the shift is only 1 pixel in each direction, any motion in the picture, even a movement of a single pixel will negate the ability of the software to process the image as a pixel shift image. Shake reduction is good, but I doubt that it's that good. even with a tripod it will be tricky if there's anything more than a light breeze.

[Darcy]

Always DNG.

why always DNG? The files are twice the size. From what I can tell LR processes them the same. Only difference is not having to worry about xmp files.

[Oakland Rob]

We've been doing this with K-3II PS images for a while.

You've got several routes.

One is to let the camera's computer do motion correction (MC).

Second, use DCU on say a RAW. It has options for PS on, PS off, PS with MC, PS without MC. I can't seem to get these to work consistently, in that I can switch between them on a DNG and see no difference.

In my experience with both K-1 and K-3IIs I think the real question isn't whether motion gets corrected. PDCU or the camera will do that. The question is whether enough of your remaining photo benefits from the non-MC PS. I have some doubts how effective that is; in some stuff like a moving stream it seems to work great in DCU. With a bunch of rustling leaves maybe not so much.

Many of us have been assuming that it's a kind of masking that MC does. But maybe not, or at least always. Maybe it simply blurs it at some level, say in the case of edge fringing.

In any case, if you want total control you just stack non-PS and PS and mask away in say Photoshop. Or use a tool in Lr and adjust sharpness; it can effectively eliminate motion artifacts, and if it's rustling grass or water you might WANT that blurry anyway.

I'd like to use DCU, but it's so awful. I don't like it's default "natural" rendering, and it's so glacial it's terrible to use. dcrawps is better, in that you can set the threshold for motion for it to correct. The PS images have such detail that in some cases the artifacts aren't even visible unless you do some serious peeping. drawps users recommends a 20% threshold for decent results if I remember correctly; check the thread here for more info. https://www.pentaxforums.com/forums/172-pentax-k-3/311865-pixel-shift-finicky-3.html

[dakight]

why always DNG? The files are twice the size. From what I can tell LR processes them the same. Only difference is not having to worry about xmp files.

I began with a K-50 which did not produce PEF files, only DNG. I continued with DNG for consistency. The file size is not a major issue at this point in time. I never fill the memory card and I have plenty of hard disk space. The difference in download/upload time is negligible for the volume of files that I deal with. Finally I've read anecdotal reports of compatibility issues with PEF format and 3rd party software so I just stayed with DNG.


*Edit*
Unless you're talking specifically about pixel shift images, there isn't that much difference in the file size anyway. I just ran a quick test and got a DNG file size of 24mb and PEF File size of 23mb for the same scene using my K-5 IIs. The PEF is smaller, but not even close to half the size.