Pixel Shift: bigger files? B&W results?

tomO2013 · 05-22-2016, 04:30 PM - **1 Like**

Originally posted by stevebrot

How are you processing for B&W using pixel shift...anything special?

Steve

Truthfully - I'm still working my way around what will be my optimal workflow.

For obvious reasons, right now, in the absense of a working ACR and lightroom, the Pentax/Silkypix digital camera utility 5.5.1 is still the best option for converting pixel shift files.

Typically I open the pixel shift files in DCU, use normal profile, sometimes add a little shadow recovery, and then add in a little sharpening (fs mode rather than 's' on the sharpening slider) and then export out a TIFF that I now import and work within lightroom/Photoshop. Generally I use try and make sure that I have an even histogram when exporting so that I am exporting a full fat TIFF file to play around with in LR/PS.

Pansottin · 05-23-2016, 04:33 PM

diglloyd: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility

Not good .-(

tomO2013 · 05-23-2016, 05:16 PM

That's a subscription required link. Can you provide a synopsis of what you've read???

Pansottin · 05-23-2016, 05:18 PM

Sorry.
diglloyd: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility

The link is not working here.

Google this:
Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility.

tomO2013 · 05-23-2016, 07:31 PM

Originally posted by Pansottin

Sorry.
diglloyd: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility

The link is not working here.

Google this:
Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility.

He basically says that it is a make it or break it feature for motion correction to work in order to allow pixel shift work with more types of work. I agree with him 100% on that point. It's important that it works to have much wider applicability than merely still life and scenes where there is zero motion.
However the key takeaway is that Pixel Shift MC does work, you just need to use Pentax digital camera utility to benefit.
Lloyd pins the blame for the lack of ACR support squarely on the shoulders of Pentax.
From a software development, nevermind business perspectives, this does not make any sense to me.

Let's be clear - unless Lloyd Chambers has evidence to prove otherwise, we cannot say for definite whether or not it was a case that Ricoh reached out to Adobe previously to aid support in ACR or whether Ricoh simply did not bother contacting Adobe to let them know the direction that they were going with Pixel Shift.
I feel that the more likely scenario is that Adobe simply does not feel like this is a feature worth expending additional development effort on until there is a bigger market penetration in the number of devices supporting the feature - chicken and egg.

Adobe has a history of lacklustre support for new technologies that stray from the traditional bayer demosaicing process - look at Fuji's XTrans. If we make an educated guess, this time based on past software development history over at Adobe, particularly with respect to Fuji's XTrans support, this is likely to be very far down Adobe's list of priorities given the market penetration. https://forums.adobe.com/thread/1493324
To wire support for Pixel Shift into ACR, Ricoh would need to have access to the source code that provides support for demosaicing inACR. Guess who owns that - yes, Adobe.

I really enjoy Lloyd Chambers articles , but this time I personally feel that his statement of blame is somewhat unbalanced.

Zen4Life · 05-25-2016, 11:25 AM

Originally posted by tomO2013

To wire support for Pixel Shift into ACR, Ricoh would need to have access to the source code that provides support for demosaicing inACR. Guess who owns that - yes, Adobe.

This line should read Pixel Shift MC (motion control) as ACR does, indeed, support pixel shift files with no movement. Also, Ricoh would need to provide the motion correction algorithm and/or actual source code to Adobe and then it would be Adobe's job to incorporate that into ACR. Like you say, we have no way of knowing what, if any, collaboration was done between Pentax and Adobe. From what I have read on Adobe forums, their response is that motion correction is not supported at this time with no mention on whether they will include it in the future.

If we can learn anything from Adobe's support of X-Trans, we should not hold our breath...

dflorez · 06-01-2016, 10:25 AM

Hey everyone. I'm still working out the kinks/features of the k1, among them the pixel shift.

Looking at files from it, I'm seeing a massive (3.5x) increase in filesize, but no huge difference in imagery via lightroom. I assume having the color information on every pixel (among other moire/aliasing benefits) is that you can push/pull the file a bit further? Please correct me if there's a more important benefit. With all the hype surrounding it, I'm excited to use this feature to full benefit.

But also I noticed some of you have written that adobe isn't supporting it, via lightroom. How so? Is my lightroom file different from it should be on a pixelshift image?

enoeske · 06-01-2016, 10:37 AM

Originally posted by dflorez

Hey everyone. I'm still working out the kinks/features of the k1, among them the pixel shift.

Looking at files from it, I'm seeing a massive (3.5x) increase in filesize, but no huge difference in imagery via lightroom. I assume having the color information on every pixel (among other moire/aliasing benefits) is that you can push/pull the file a bit further? Please correct me if there's a more important benefit. With all the hype surrounding it, I'm excited to use this feature to full benefit.

But also I noticed some of you have written that adobe isn't supporting it, via lightroom. How so? Is my lightroom file different from it should be on a pixelshift image?

The file is 3.5x (closer to 4x) bigger because its just 4 RAW images stacked together. The camera isn't really doing anything other than putting all 4 files into 1 DNG wrapper. Its up to the RAW development software to create the final pixel shift image. And ACR does not do it correctly. As of now, you can use a few different programs, like the included DCU5 or DCRAW to do it right.

stevebrot · 06-01-2016, 12:08 PM

Originally posted by dflorez

Looking at files from it, I'm seeing a massive (3.5x) increase in filesize, but no huge difference in imagery via lightroom.

Which version LR? The version must be 6.x and up-to-date. Older versions only process the first image in the stack. As enoeske noted above, LR's pixel shift implementation is faulty and not generally recommended. PDCU 5.5.1 does a good job on the merge followed by a save as a 16-bit TIFF for processing in LR.

Steve

Class A · 07-17-2016, 02:36 AM

Originally posted by dflorez

I assume having the color information on every pixel (among other moire/aliasing benefits) is that you can push/pull the file a bit further? Please correct me if there's a more important benefit.

The main advantage of the PixelShift approach is that it obviates the need for demosaicing.

Demosaicing is the process of reconstructing full RGB values for each pixel based on only having captured either R, G, or B at each pixel position. Being able to replace this (necessarily incomplete) reconstruction process with actual R, G, and B measurements means

there is an increase in colour resolution. Note that red and blue are captured with only half the resolution of green in a conventional capture.
colour moiré and other colour artefacts resulting from chroma undersampling are avoided.
pixel locations that normally would only be sampled for one colour (say, red), will now also be sampled with green (twice) and blue, meaning that more luminance information is available. Each colour filter has different transition properties so it helps to also switch in the ones with the highest transparency, in particular, if the subject only provided information in a range that the originally assigned colour filter completely blocked.
each pixel location is sampled four times, resulting in a doubling of SNR (signal to noise ratio).

Winder · 07-17-2016, 05:52 PM

The big question is.... Can Ricoh implement the Olympus/Hassy version of pixel shift with firmware. This would give us one more option.

Class A · 07-17-2016, 06:51 PM

Originally posted by Winder

The big question is.... Can Ricoh implement the Olympus/Hassy version of pixel shift with firmware.

They already did during development and did not see sufficient improvement.

This was mentioned in one of the Ricoh interviews/presentations a while ago.

05-23-2016, 07:31 PM	#20
tomO2013 Senior Member Join Date: Mar 2016 Posts: 155	Originally posted by Pansottin Sorry. diglloyd: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility The link is not working here. Google this: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility. He basically says that it is a make it or break it feature for motion correction to work in order to allow pixel shift work with more types of work. I agree with him 100% on that point. It's important that it works to have much wider applicability than merely still life and scenes where there is zero motion. However the key takeaway is that Pixel Shift MC does work, you just need to use Pentax digital camera utility to benefit. Lloyd pins the blame for the lack of ACR support squarely on the shoulders of Pentax. From a software development, nevermind business perspectives, this does not make any sense to me. Let's be clear - unless Lloyd Chambers has evidence to prove otherwise, we cannot say for definite whether or not it was a case that Ricoh reached out to Adobe previously to aid support in ACR or whether Ricoh simply did not bother contacting Adobe to let them know the direction that they were going with Pixel Shift. I feel that the more likely scenario is that Adobe simply does not feel like this is a feature worth expending additional development effort on until there is a bigger market penetration in the number of devices supporting the feature - chicken and egg. Adobe has a history of lacklustre support for new technologies that stray from the traditional bayer demosaicing process - look at Fuji's XTrans. If we make an educated guess, this time based on past software development history over at Adobe, particularly with respect to Fuji's XTrans support, this is likely to be very far down Adobe's list of priorities given the market penetration. https://forums.adobe.com/thread/1493324 To wire support for Pixel Shift into ACR, Ricoh would need to have access to the source code that provides support for demosaicing inACR. Guess who owns that - yes, Adobe. I really enjoy Lloyd Chambers articles , but this time I personally feel that his statement of blame is somewhat unbalanced. Last edited by tomO2013; 05-23-2016 at 08:44 PM.

07-17-2016, 02:36 AM	#25
Class A Pentaxian Join Date: Aug 2008 Location: Wellington, New Zealand Posts: 11,251	Originally posted by dflorez I assume having the color information on every pixel (among other moire/aliasing benefits) is that you can push/pull the file a bit further? Please correct me if there's a more important benefit. The main advantage of the PixelShift approach is that it obviates the need for demosaicing. Demosaicing is the process of reconstructing full RGB values for each pixel based on only having captured either R, G, or B at each pixel position. Being able to replace this (necessarily incomplete) reconstruction process with actual R, G, and B measurements means there is an increase in colour resolution. Note that red and blue are captured with only half the resolution of green in a conventional capture. colour moiré and other colour artefacts resulting from chroma undersampling are avoided. pixel locations that normally would only be sampled for one colour (say, red), will now also be sampled with green (twice) and blue, meaning that more luminance information is available. Each colour filter has different transition properties so it helps to also switch in the ones with the highest transparency, in particular, if the subject only provided information in a range that the originally assigned colour filter completely blocked. each pixel location is sampled four times, resulting in a doubling of SNR (signal to noise ratio).

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Can't use Pixel Shift Resolution in B mode	astrojim	Photographic Technique	15	05-21-2020 10:16 AM
Pixel shift results from DPreview	rlatjsrud	Pentax Full Frame	35	05-07-2016 11:55 AM
Request Adobe to support Pentax HDR and Pixel Shift RAW files	Pentor	Digital Processing, Software, and Printing	16	06-24-2015 01:49 PM
Is there a difference between shooting b&w and processing as b&w?	justtakingpics	Digital Processing, Software, and Printing	5	04-25-2010 07:10 PM
For Sale - Sold: DA 50-200mm, B&W Polarizer, B&W Step Up Ring	camperguy01	Sold Items	5	02-15-2009 08:39 PM

05-22-2016, 04:30 PM - 1 Like	#16
tomO2013 Senior Member Join Date: Mar 2016 Posts: 155	Originally posted by stevebrot How are you processing for B&W using pixel shift...anything special? Steve Truthfully - I'm still working my way around what will be my optimal workflow. For obvious reasons, right now, in the absense of a working ACR and lightroom, the Pentax/Silkypix digital camera utility 5.5.1 is still the best option for converting pixel shift files. Typically I open the pixel shift files in DCU, use normal profile, sometimes add a little shadow recovery, and then add in a little sharpening (fs mode rather than 's' on the sharpening slider) and then export out a TIFF that I now import and work within lightroom/Photoshop. Generally I use try and make sure that I have an even histogram when exporting so that I am exporting a full fat TIFF file to play around with in LR/PS.

05-23-2016, 04:33 PM	#17
Pansottin Junior Member Join Date: Jun 2015 Posts: 41 Original Poster	diglloyd: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility Not good .-(

05-23-2016, 05:16 PM	#18
tomO2013 Senior Member Join Date: Mar 2016 Posts: 155	That's a subscription required link. Can you provide a synopsis of what you've read???

05-23-2016, 05:18 PM	#19
Pansottin Junior Member Join Date: Jun 2015 Posts: 41 Original Poster	Sorry. diglloyd: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility The link is not working here. Google this: Motion Correction for Pentax K1 SuperRes Images via Pentax Digital Camera Utility.

05-25-2016, 11:25 AM	#21
Zen4Life Forum Member Join Date: Feb 2012 Posts: 63	Originally posted by tomO2013 To wire support for Pixel Shift into ACR, Ricoh would need to have access to the source code that provides support for demosaicing inACR. Guess who owns that - yes, Adobe. This line should read Pixel Shift MC (motion control) as ACR does, indeed, support pixel shift files with no movement. Also, Ricoh would need to provide the motion correction algorithm and/or actual source code to Adobe and then it would be Adobe's job to incorporate that into ACR. Like you say, we have no way of knowing what, if any, collaboration was done between Pentax and Adobe. From what I have read on Adobe forums, their response is that motion correction is not supported at this time with no mention on whether they will include it in the future. If we can learn anything from Adobe's support of X-Trans, we should not hold our breath...

06-01-2016, 10:25 AM	#22
dflorez Forum Member Join Date: Dec 2010 Location: Florida Posts: 91	Hey everyone. I'm still working out the kinks/features of the k1, among them the pixel shift. Looking at files from it, I'm seeing a massive (3.5x) increase in filesize, but no huge difference in imagery via lightroom. I assume having the color information on every pixel (among other moire/aliasing benefits) is that you can push/pull the file a bit further? Please correct me if there's a more important benefit. With all the hype surrounding it, I'm excited to use this feature to full benefit. But also I noticed some of you have written that adobe isn't supporting it, via lightroom. How so? Is my lightroom file different from it should be on a pixelshift image?

06-01-2016, 10:37 AM	#23
enoeske Veteran Member Join Date: Jul 2009 Location: Surprise, Az Photos: Gallery Posts: 2,136	Originally posted by dflorez Hey everyone. I'm still working out the kinks/features of the k1, among them the pixel shift. Looking at files from it, I'm seeing a massive (3.5x) increase in filesize, but no huge difference in imagery via lightroom. I assume having the color information on every pixel (among other moire/aliasing benefits) is that you can push/pull the file a bit further? Please correct me if there's a more important benefit. With all the hype surrounding it, I'm excited to use this feature to full benefit. But also I noticed some of you have written that adobe isn't supporting it, via lightroom. How so? Is my lightroom file different from it should be on a pixelshift image? The file is 3.5x (closer to 4x) bigger because its just 4 RAW images stacked together. The camera isn't really doing anything other than putting all 4 files into 1 DNG wrapper. Its up to the RAW development software to create the final pixel shift image. And ACR does not do it correctly. As of now, you can use a few different programs, like the included DCU5 or DCRAW to do it right.

06-01-2016, 12:08 PM	#24
stevebrot Otis Memorial Pentaxian Join Date: Mar 2007 Location: Vancouver (USA) Photos: Gallery \| Albums Posts: 42,007	Originally posted by dflorez Looking at files from it, I'm seeing a massive (3.5x) increase in filesize, but no huge difference in imagery via lightroom. Which version LR? The version must be 6.x and up-to-date. Older versions only process the first image in the stack. As enoeske noted above, LR's pixel shift implementation is faulty and not generally recommended. PDCU 5.5.1 does a good job on the merge followed by a save as a 16-bit TIFF for processing in LR. Steve

07-17-2016, 05:52 PM	#26
Winder Veteran Member Join Date: Apr 2010 Location: Tennessee Posts: 6,617	The big question is.... Can Ricoh implement the Olympus/Hassy version of pixel shift with firmware. This would give us one more option.

07-17-2016, 06:51 PM	#27
Class A Pentaxian Join Date: Aug 2008 Location: Wellington, New Zealand Posts: 11,251	Originally posted by Winder The big question is.... Can Ricoh implement the Olympus/Hassy version of pixel shift with firmware. They already did during development and did not see sufficient improvement. This was mentioned in one of the Ricoh interviews/presentations a while ago.