[BarryE]

What browser are you using?
In Chrome the image is dynamically rendered to resize as the window is sized... So no horizontal scrolling should ever be present.

Page formatting and comments look okay on my screen, and I'm on a macbook 13"
Also tested this thread on my work computer with a 1080 monitor without any horizontal scrolling.

Regardless, I'll remove the photo.
I didn't mean to cause peeve!

---------- Post added 05-16-16 at 10:44 PM ----------




Hey, here's the dropbox link as promised!

https://www.dropbox.com/sh/qak6n6l4nki75kr/AACgzLI_K3hxIPnEqcRlUResa?dl=0

Subject: Fingerling potatoes in a wooden bowl.

There are 4 images total.
3093 - DNG non-pixel shift - 31 MB
3094 - DNG pixel shift - 115.4 MB
3095 - JPG pixel shift - 14.9 MB
3096 - JPG non-pixel shift - 10.2 MB

Let us all know what kind of workflow you test out.
And if you need more samples just let me know!

Cheers!
Logan

Hi Logan, many thanks for taking the effort. What I saw:

# I inputted then via Bridge, directly into ACR (latest CC version 9.5.1.595)
# I could see straight away at 100% the difference between 3095 and 3096 jpegs, the pixel shifted version being sharper.
# BUT ... I could see NO difference between the two DNG files. I abused the files by extreme adjustments, but I could not distinguish any difference.

I assume the four files are straight out of the camera. Correct ?

From this I'm concluding that the pixel shift processing in camera works well to produce jpegs, BUT pixel shifted DNGs outputted from camera and then inputted directly in ACR are not able to be processed as a pixel shifted file in ACR. I'm guessing ACR is just using one of the embedded 4 RAW files and not in any way managing to merge the data. If this is true then the DNGs need to put through ('Pentax') software that understands pixel shift. However, I believe from what has been said here that DCU does NOT output RAW/DNG files, only jpeg or tiff.

*** So do I conclude correctly that from the K-3ii it is not possible to process RAW/DNG pixel shifted images in Adobe ACR ?????? That you are stuck using jpeg files and therefore have lost all the advantages of RAW processing possibilities. If so then then the pixel shift technology is (currently) not anything more than an interesting idea to me :-(. Hopefully, there's a way to get a pixel shifted file into ACR as a RAW/DNG file to be processed as any other RAW.

Many thanks, Logan. Your efforts have helped with my understanding a little more, but left me feeling somewhat deflated. I had hoped to be able to take extra high resolution shots of artworks with the pixel shift technology that I could then process carefully in ACR to ensure I achieve a near-perfect colour match (ie in colour managed RAW), before being able to enlarge these extra high res shots more satisfactorily than I can without the pixel shift technology. Seems it may be a no-starter at present.

Hopefully, I'm wrong and/or have missed something and there's a way round this ... Any ideas, anyone ?

[Rondec]

If you use the latest version of DCU (I think it is version 5), it allows for the reduction in artifacts with pixel shift that is helpful. I usually do a quick pass through DCU (this is with K-1, but I think it would be fine with K3 II as well). Set pixel shift to on with MC. I usually set the setting to natural as opposed to bright (which feels oversaturated) and I will often bump shadows just a bit. Then I save the image as a TIFF file which I import into Lightroom and do any final processing with it there.

I think you can also use some version of DCRAW which allows for the reduction of artifacts in the images.

If you don't have any artifacts (you are taking images without any movement at all), then it really shouldn't matter what you use they will all be OK. As I understand it, ACR can develop pixel shifted images, it just can't do any compensation for any movement within the image. As to loss of latitude with the generation of your TIFF image, I think it is pretty minimal. A Tiff file is still 207 megabytes in size, as compared to 160 megabytes for the DNG files and as far as I can tell, has just as much ability to bump shadows, etc as the original DNG file.

Anyway, that is my process and it has worked quite well and I am pleased with the results.

(a pixel shifted image taken with a K-1, run through DCU and then through Nik Silver Efex/Lightroom)

[UserAccessDenied]

Hi Logan, many thanks for taking the effort. What I saw:

# I inputted then via Bridge, directly into ACR (latest CC version 9.5.1.595)
# I could see straight away at 100% the difference between 3095 and 3096 jpegs, the pixel shifted version being sharper.
# BUT ... I could see NO difference between the two DNG files. I abused the files by extreme adjustments, but I could not distinguish any difference.

I assume the four files are straight out of the camera. Correct ?

From this I'm concluding that the pixel shift processing in camera works well to produce jpegs, BUT pixel shifted DNGs outputted from camera and then inputted directly in ACR are not able to be processed as a pixel shifted file in ACR. I'm guessing ACR is just using one of the embedded 4 RAW files and not in any way managing to merge the data. If this is true then the DNGs need to put through ('Pentax') software that understands pixel shift. However, I believe from what has been said here that DCU does NOT output RAW/DNG files, only jpeg or tiff.

*** So do I conclude correctly that from the K-3ii it is not possible to process RAW/DNG pixel shifted images in Adobe ACR ?????? That you are stuck using jpeg files and therefore have lost all the advantages of RAW processing possibilities. If so then then the pixel shift technology is (currently) not anything more than an interesting idea to me :-(. Hopefully, there's a way to get a pixel shifted file into ACR as a RAW/DNG file to be processed as any other RAW.

Many thanks, Logan. Your efforts have helped with my understanding a little more, but left me feeling somewhat deflated. I had hoped to be able to take extra high resolution shots of artworks with the pixel shift technology that I could then process carefully in ACR to ensure I achieve a near-perfect colour match (ie in colour managed RAW), before being able to enlarge these extra high res shots more satisfactorily than I can without the pixel shift technology. Seems it may be a no-starter at present.

Hopefully, I'm wrong and/or have missed something and there's a way round this ... Any ideas, anyone ?

Barry,

Glad you were able to discover something, even if it is a limitation. Always good to learn something new!

I'm not familiar with ACR. I have heard this applies in other software though - only a single image from the 4 in pixel shift is brought in as DNG. If you can't use TIFF as an output than that certainly prohibits usage until the proper software is found.

Could you use the TIFF output and save as DNG in LR?
Would that present any loss of data?

Another thought... I only shoot DNG, but if you want me to do the test again and include PEF files I can do that.
Just let me know.

Another excuse to break out the tripod and lights! lol

I'm 100% willing to help because this is something I am very curious about as well and think we need more of the PF community to chime in here!
Currently I just shoot JPG pixel shift because of my lack of knowledge with DNG pixel shift and how to PROPERLY work through PP. - Not ideal, I want to be able to use the DNG pixel shift for full control editing.

I hope we can figure this out!

[BarryE]

Barry,

Glad you were able to discover something, even if it is a limitation. Always good to learn something new!

I'm not familiar with ACR. I have heard this applies in other software though - only a single image from the 4 in pixel shift is brought in as DNG. If you can't use TIFF as an output than that certainly prohibits usage until the proper software is found.

Could you use the TIFF output and save as DNG in LR?
Would that present any loss of data?

Another thought... I only shoot DNG, but if you want me to do the test again and include PEF files I can do that.
Just let me know.

Another excuse to break out the tripod and lights! lol

I'm 100% willing to help because this is something I am very curious about as well and think we need more of the PF community to chime in here!
Currently I just shoot JPG pixel shift because of my lack of knowledge with DNG pixel shift and how to PROPERLY work through PP. - Not ideal, I want to be able to use the DNG pixel shift for full control editing.

I hope we can figure this out!

Hi Logan, I don't think the PEF route would help. The full editing of a RAW file rather than TIFF is what I'll need. At the moment I'm stumped.

I've added a post on the Adobe forum site to see if that gets a response, though as it's a Pentax problem, it's probably somewhat unlikely!

I agree about getting this question noticed by others. Don't know how to do that ...

[microlight]

I use DNG rather than PEF because Windows 7 64 bit doesn't display PEF thumbnails from the K-3II whereas it did with previous Pentaxes. Yes, DCU5 'only' outputs TIFF and JPG - but you can choose a 16-bit TIFF, which is uncompressed (and big!) and contains all of the RAW file's information so I don't think that you're losing any processability like you are with JPG. In-camera processing in the K-3II will output a TIFF (and of course a JPG), but I believe it's a 8-bit file.

DCU5, v5.5.1 will happily process both K-1 and K-3II pixel shift photos automatically, on MC setting as noted above, and will motion-correct movement in files from either camera. Lightroom and I believe the latest ACR have been said to accommodate pixel shift in their latest versions (although people are saying that the PS output from Lightroom is inferior to that from DCU5 - can't comment as I don't use Lightroom) and that even if ACR and Lightroom now have a pixel-shift algorithm, it's not as good as DCU5's - and they don't motion-correct.

So in a nutshell, to answer Barry's question: ACR won't do as good a job with pixel shift as DCU5 does and won't in any case do motion correction, so DCU5 is best for that. If you export from DCU5 as a 16-bit TIFF, you can then import into ACR, and you're away. This is exactly what I do. This way, you're not limiting yourself to JPG output as you have the full beans from the RAW file which you can then PP further in ACR if you don't want to use DCU5 any further. My first step is to modify exposure, colour balance, pixel shift if relevant and maybe shift in DCU5 before exporting as 16-bit TIFF and using ACR (or the free Faststone - some good tools in there) for further PP.

[UserAccessDenied]

I use DNG rather than PEF because Windows 7 64 bit doesn't display PEF thumbnails from the K-3II whereas it did with previous Pentaxes. Yes, DCU5 'only' outputs TIFF and JPG - but you can choose a 16-bit TIFF, which is uncompressed (and big!) and contains all of the RAW file's information so I don't think that you're losing any processability like you are with JPG. In-camera processing in the K-3II will output a TIFF (and of course a JPG), but I believe it's a 8-bit file.

DCU5, v5.5.1 will happily process both K-1 and K-3II pixel shift photos automatically, on MC setting as noted above, and will motion-correct movement in files from either camera. Lightroom and I believe the latest ACR have been said to accommodate pixel shift in their latest versions (although people are saying that the PS output from Lightroom is inferior to that from DCU5 - can't comment as I don't use Lightroom) and that even if ACR and Lightroom now have a pixel-shift algorithm, it's not as good as DCU5's - and they don't motion-correct.

So in a nutshell, to answer Barry's question: ACR won't do as good a job with pixel shift as DCU5 does and won't in any case do motion correction, so DCU5 is best for that. If you export from DCU5 as a 16-bit TIFF, you can then import into ACR, and you're away. This is exactly what I do. This way, you're not limiting yourself to JPG output as you have the full beans from the RAW file which you can then PP further in ACR if you don't want to use DCU5 any further. My first step is to modify exposure, colour balance, pixel shift if relevant and maybe shift in DCU5 before exporting as 16-bit TIFF and using ACR (or the free Faststone - some good tools in there) for further PP.

I'm going to give this a try when I get home.
I really want to find a way to use DNG pixel shift.

I've never used DCU5, don't even have it installed...
It's free on Ricoh's website, right?
Any words of advice for first time user?!

(Sorry Barry - no intention of hijacking the thread! )

[microlight]

@UserAccessDenied,

You should have had a copy of DCU5 in your K-3II package when you bought it - install that first - it's probably version 5.4.something. Download the update from the Ricoh website and install it over the version you just installed - you have to do this first as otherwise the update from the website won't install without jumping through hoops. This will give you v5.5.1 which has pixel shift motion correction. If you've never used DCU then there might be a learning curve as it's not ideally intuitive, but if all you're going to be doing is exporting a processed and pixel-shifted TIFF then you'll get that pretty quickly. I've used it and its predecessor for years so know my way around it.

Once you have your exported 16-bit TIFF, then there's a little trick in getting it into ACR; use 'open as' in Photoshop and then select Camera Raw from the drop-down, and you can load the TIFF (or even a JPG) from there.

[BarryE]

I use DNG rather than PEF because Windows 7 64 bit doesn't display PEF thumbnails from the K-3II whereas it did with previous Pentaxes. Yes, DCU5 'only' outputs TIFF and JPG - but you can choose a 16-bit TIFF, which is uncompressed (and big!) and contains all of the RAW file's information so I don't think that you're losing any processability like you are with JPG. In-camera processing in the K-3II will output a TIFF (and of course a JPG), but I believe it's a 8-bit file.

DCU5, v5.5.1 will happily process both K-1 and K-3II pixel shift photos automatically, on MC setting as noted above, and will motion-correct movement in files from either camera. Lightroom and I believe the latest ACR have been said to accommodate pixel shift in their latest versions (although people are saying that the PS output from Lightroom is inferior to that from DCU5 - can't comment as I don't use Lightroom) and that even if ACR and Lightroom now have a pixel-shift algorithm, it's not as good as DCU5's - and they don't motion-correct.

So in a nutshell, to answer Barry's question: ACR won't do as good a job with pixel shift as DCU5 does and won't in any case do motion correction, so DCU5 is best for that. If you export from DCU5 as a 16-bit TIFF, you can then import into ACR, and you're away. This is exactly what I do. This way, you're not limiting yourself to JPG output as you have the full beans from the RAW file which you can then PP further in ACR if you don't want to use DCU5 any further. My first step is to modify exposure, colour balance, pixel shift if relevant and maybe shift in DCU5 before exporting as 16-bit TIFF and using ACR (or the free Faststone - some good tools in there) for further PP.

But TIFF files are already processed, so immediately there's a loss in editability than RAW. RAWs files allow non-destructive editing so improving the workflow. And I use pro-photo colour space to edit as it gives more room. So unfortunately TIFF files will be a poor substitute for RAW files. Several degrees better than jpegs, though, so a remote possibility if I was forced down this route.

I am still disappointed in this lack of functionality. Hopefully someone can pick this thread up and explain why the limitation - if there is indeed one ...

[Darcy]

There is some good info here on Adobe issues with pixelshift from K-1: diglloyd - Blog

[microlight]

Barry, can you help me understand why 16-bit TIFFs are such a poor substitute for RAW? Yes, by the time you've saved a TIFF, some processing has taken place - but there is also processing before the RAW file itself is created in camera, for example setting of ISO based on sensor output amplification, Bayer interpolation. So the RAW file has already been processed to an extent even though at this stage it's not displayable as a picture, as it's a data container. What's visible on the screen of a camera is not the RAW file itself, but a low-res embedded JPG created from the RAW data by the camera that allows the photographer to see what they just shot.

K-3II RAW files are output at 14 bits into a 16-bit TIFF container and with no compression (or even lossless compression), nothing is lost; indeed, TIFF files are larger than their RAW counterparts. If you set all the JPG modifiers in camera flat, then surely there should be little or no image modification, leaving it all to be done in PP. Also, if TIFF is such a poor substitute, why don't manufacturers allow options to save as RAW in software, rather than as a TIFF? If I'm missing something here, please help me out.

An alternative of course would be to do your processing from RAW in DCU5!

[Oakland Rob]

FRV is fine. Its lightroom that seems to insist on only updating DNG and ignore sidecars once its been edited in LR. Its odd behavior I haven't seen before in Canon.

Lr does NOT write sidecars to DNG files and never has AFAIK.

As I noted above, Lr ignores sidecars to DNGs if the DNG has been modified more recently than the sidecar, otherwise it reads the sidecar. But DNG is designed to hold metadata within the file so sidecars with DNG is a bit of an anomaly. FRV ratings/labels not written to DNG files? | FastRawViewer

It's not odd behavior; that's normal. Canon cr2 RAW fles use sidecars, but if you convert them to DNG, the same rules apply.

And see the FRV manual here, especially the part about embedded (not sidecar) XMP at the bottom: Metadata: Ratings, Labels, Title, and Description | FastRawViewer

[Darcy]

Lr does NOT write sidecars to DNG files and never has AFAIK.

As I noted above, Lr ignores sidecars to DNGs if the DNG has been modified more recently than the sidecar, otherwise it reads the sidecar. But DNG is designed to hold metadata within the file so sidecars with DNG is a bit of an anomaly. FRV ratings/labels not written to DNG files? | FastRawViewer

It's not odd behavior; that's normal. Canon cr2 RAW fles use sidecars, but if you convert them to DNG, the same rules apply.

And see the FRV manual here, especially the part about embedded (not sidecar) XMP at the bottom: Metadata: Ratings, Labels, Title, and Description | FastRawViewer

Thanks for this. What I was finding was that LR was ignoring the xmp even though they were newer. I even tried Syncing the folder.

[BarryE]

Barry, can you help me understand why 16-bit TIFFs are such a poor substitute for RAW? Yes, by the time you've saved a TIFF, some processing has taken place - but there is also processing before the RAW file itself is created in camera, for example setting of ISO based on sensor output amplification, Bayer interpolation. So the RAW file has already been processed to an extent even though at this stage it's not displayable as a picture, as it's a data container. What's visible on the screen of a camera is not the RAW file itself, but a low-res embedded JPG created from the RAW data by the camera that allows the photographer to see what they just shot.

K-3II RAW files are output at 14 bits into a 16-bit TIFF container and with no compression (or even lossless compression), nothing is lost; indeed, TIFF files are larger than their RAW counterparts. If you set all the JPG modifiers in camera flat, then surely there should be little or no image modification, leaving it all to be done in PP. Also, if TIFF is such a poor substitute, why don't manufacturers allow options to save as RAW in software, rather than as a TIFF? If I'm missing something here, please help me out.

An alternative of course would be to do your processing from RAW in DCU5!

TIFF isn't a poor substitute it's just that RAW isn't an output format whereas TIFF, like JPEG, is. That's one bit covered, ish.

RAW files allow non destructive editing, this is important as it allows a base file to have changes applied without any changes to the original. Which creates a powerful workflow for any future processing that needs to be done. The modifications just being held in a small sidecar file, so it's efficient.

Add this non-destructive editing in ACR to opening the RAW files as objects in PS and the ease of moving back and forwards between ACR and PS is very powerful.

Nothing is baked in in RAW so the files can be fully editable. Data has been lost in the creation of TIFFs which can't be recovered.

Using RAW gives an efficient, fully editable, non-destructive , method of working with the usable data that comes as near as possible off the sensor, without any interpretation having been made by the camera.

Well that's how I see it. Does that help ?

[Oakland Rob]

I disagree with the proposition that Lr only uses the first frame.

If that's what it did, there would be NO artifacts from movement. But there are (unfortunately). Hence it does use all the frames.

TIFF or DNG? that may or may not matter depending on what you're trying to do. But if you run a DNG through DCU and get a TIFF some operations have been done, even though it's lossless, and the PS process is different than regular demosaicing. But it would bake in something like WB, which you might want to have more flexibility in changing. But since you've still got the original RAW, if you find that the results of working on the TIFF are unacceptable, you just go back and use DCU to render another TIFF, this time with a different WB. Some choices have to be made, even if they are "flat," and that can affect what you do later.

And as you say you're always looking at a rendering of a RAW. The DNG contains a JPEG, and usually a pretty neutral one. That's the whole selling point of FastRawViewer; it generates it's own previews/renderings really quickly and so you get a better idea of what's recoverable from the RAW data than using Lr's rendering or DCU's or Apple's or whatever. It allows you to preview some stuff like WB and EV and can demonstrate that some images you maybe thought were junk are in fact quite usable.

And to repeat, you can't save as a DNG from DCU.

And in Lr (and I think ACR) you have to at least increase the sharpening to see the effects of PS. I can't see any difference between DCU and Lr (aside from MC) although I can get better results from Lr/Ps. But it starts out way blah, not only in apparent sharpness but also other criteria. DCU (when it gets around to finishing...) is rather more perky initially, although it also benefits from some work.

[UserAccessDenied]

Do most people use ACR in their typical workflow, or are you still just talking pixel shift?

My typical workflow is:
import DNG to LR, edit, export to JPG, done.

Am I missing an advantage of using all these extra software/programs?