Forgot Password
Pentax Camera Forums Home
 

Reply
Show Printable Version Search this Thread
05-17-2016, 09:18 AM   #31
Loyal Site Supporter
Loyal Site Supporter




Join Date: Apr 2015
Photos: Albums
Posts: 663
QuoteOriginally posted by Darcy Quote
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.
It's a bit of a drag but the sequence really matters. Maybe try turning off the option in Lr to automatically write metadata to files? doing some things in Lr that aren't obvious changes can result in a write to the file when that wouldn't be intutive. I just try to leave Lr closed when I'm using ingesters like FRV or Photo Mechanic or others. I do all my work in those, and only after they are closed do I open Lr and import or synch or whatever.

Saves me from making an oopsie and undoing what I just spend a lot of time doing.

05-17-2016, 09:41 AM   #32
Forum Member




Join Date: Apr 2016
Location: Edmonton
Photos: Gallery
Posts: 63
QuoteOriginally posted by Oakland Rob Quote
It's a bit of a drag but the sequence really matters. Maybe try turning off the option in Lr to automatically write metadata to files? doing some things in Lr that aren't obvious changes can result in a write to the file when that wouldn't be intutive. I just try to leave Lr closed when I'm using ingesters like FRV or Photo Mechanic or others. I do all my work in those, and only after they are closed do I open Lr and import or synch or whatever.

Saves me from making an oopsie and undoing what I just spend a lot of time doing.
Ok, thats good advise and simple.
05-17-2016, 10:15 AM   #33
Pentaxian
microlight's Avatar

Join Date: Sep 2011
Location: Hampshire, UK
Posts: 728
Thanks for the explanation. I understand what you're driving at, which seems to be going straight into ACR with RAW DNG pixel-shift files, without having to go through a RAW developer like DCU5 first. An issue is that ACR - at the moment - doesn't do the pixel-shift handling as well or as completely as DCU5 does, so there needs to be an intermediate in getting the information from one program to the other. I think that the DCU5 process is also non-destructive as the program remembers what you do as modifications (don't know how! Sidecar maybe) - from your perspective the downside is that this isn't happening in ACR. There is the intermediate 16-bit TIFF which although modified has not lost any information. This is not as efficient as your preferred ACR/PS workflow as there is the addition of the intermediate TIFF, but I'm not sure that there's much of an option at the moment if pixel shift is a preferred way of working for you. And it is good!

This may of course change if Adobe chooses to develop its pixel shift integration further. In the interim, a transit via TIFF looks like your best option.

---------- Post added 05-17-16 at 10:31 AM ----------

Logan,
I only use ACR if I have a specific need. Usually it's
DCU5 -> TIFF -> Faststone (good tools! Clone is better here than in Photoshop IMO) and finalising to JPG,
or occasionally
DCU5 -> TIFF -> ACR -> Photoshop for finalising to JPG.

Faststone, nor RawTherapee, nor ACR are to me as good as DCU5 in both raw development of non-pixel-shift photos (especially noise handling) and pixel shift, but they work well with TIFFs. Most of my pre-work on DNGs is done in DCU5; colour balance, exposure, lens corrections, shift etc before finishing off in the other programs. As Oakland Rob says above, if you ultimately decide that you didn't get it right first time with the TIFF, just make another one from the RAW.

Last edited by microlight; 05-17-2016 at 10:33 AM.
05-18-2016, 05:38 AM   #34
Site Supporter
Site Supporter
UserAccessDenied's Avatar

Join Date: Jan 2015
Location: Maryland
Photos: Gallery | Albums
Posts: 1,632
QuoteOriginally posted by stevebrot Quote
Firefox on Windows...


Steve
Yeah...
I prefer Chrome for this forum site.
Firefox is good for resource conscientious usage.

CPU or RAM, pick one.

Firefox presents issues with me when viewing pictures on this forum and while watching youtube videos.
It doesn't scale properly; while Chrome has no problem scaling images to the current display extent.

05-18-2016, 09:27 AM   #35
Otis Memorial Pentaxian
Loyal Site Supporter
stevebrot's Avatar

Join Date: Mar 2007
Location: Vancouver (USA)
Photos: Gallery | Albums
Posts: 30,461
QuoteOriginally posted by UserAccessDenied Quote
Yeah...
I prefer Chrome for this forum site.
Firefox is good for resource conscientious usage.

CPU or RAM, pick one.

Firefox presents issues with me when viewing pictures on this forum and while watching youtube videos.
It doesn't scale properly; while Chrome has no problem scaling images to the current display extent.
I may be a few years behind the curve, but it used to be that image scaling was done by declaration in the CSS with the browser following the direction of the developer.

Now comes the point of true confession. I should probably not complain about giant images on this site. I have a fast Internet connection* and the forum software has provision to set limits for image display on a per user basis.** (This is done by tailoring the CSS.) I used to have mine set to 1500 pixels horizontal and 800 vertical which allowed for reasonable horizontal and vertical scroll. I currently have that feature turned off because the browser-based down-sampling (scaling) affected image quality and users often submit larger example images for troubleshooting purposes.

Now back to the sharing of full-sized images. Here are a few bullet points to consider with no judgement or preaching on my part intended:
  • Page bloat can be a problem, particularly if several full-sized images are present. A high quality 36 Mpx JPEG is pretty good sized, bit-wise, and all those bits must be moved across the wire. This is particularly an issue on mobile devices where bandwidth is more dear and more expensive.
  • A 3:2 image above 16 Mpx size is not viewable as a whole (without scrolling) on commonly available displays. Impressive as one's work may be, nobody will be able to appreciate it.
  • All browsers suck at scaling. Regardless of whether done via CSS or native feature, the algorithms used are optimized for speed, not quality. The best way to respect screen real estate and user experience while maintaining quality is to use photo editing software to downsize to "Web" resolution.***
  • If one needs to provide a full-sized image for whatever purpose, providing a link (Drop Box, Flickr, etc.) in the body of the post is a good solution
  • If there is a need to show something at full pixel resolution, one or more full-resolution (100%) crops are easy on the user and fully informative. Snipping tools are useful for this chore.


Steve

* While dial-up is rare, relatively slow Internet access is still common in many areas and some users have reported bandwidth issues with extended page load times on image-heavy threads.
** The default setting for this feature is no restriction on image dimension.
*** "Web resolution" is hard to define, though most image posts on this site are the range of 800-1200 pixels on the long axis.

Last edited by stevebrot; 05-18-2016 at 09:34 AM.
05-18-2016, 10:16 AM   #36
Loyal Site Supporter
Loyal Site Supporter




Join Date: Apr 2015
Photos: Albums
Posts: 663
QuoteOriginally posted by microlight Quote
Thanks for the explanation. I understand what you're driving at, which seems to be going straight into ACR with RAW DNG pixel-shift files, without having to go through a RAW developer like DCU5 first. An issue is that ACR - at the moment - doesn't do the pixel-shift handling as well or as completely as DCU5 does, so there needs to be an intermediate in getting the information from one program to the other. I think that the DCU5 process is also non-destructive as the program remembers what you do as modifications (don't know how! Sidecar maybe) - from your perspective the downside is that this isn't happening in ACR. There is the intermediate 16-bit TIFF which although modified has not lost any information. This is not as efficient as your preferred ACR/PS workflow as there is the addition of the intermediate TIFF, but I'm not sure that there's much of an option at the moment if pixel shift is a preferred way of working for you. And it is good!

This may of course change if Adobe chooses to develop its pixel shift integration further. In the interim, a transit via TIFF looks like your best option.

---------- Post added 05-17-16 at 10:31 AM ----------

Logan,
I only use ACR if I have a specific need. Usually it's
DCU5 -> TIFF -> Faststone (good tools! Clone is better here than in Photoshop IMO) and finalising to JPG,
or occasionally
DCU5 -> TIFF -> ACR -> Photoshop for finalising to JPG.

Faststone, nor RawTherapee, nor ACR are to me as good as DCU5 in both raw development of non-pixel-shift photos (especially noise handling) and pixel shift, but they work well with TIFFs. Most of my pre-work on DNGs is done in DCU5; colour balance, exposure, lens corrections, shift etc before finishing off in the other programs. As Oakland Rob says above, if you ultimately decide that you didn't get it right first time with the TIFF, just make another one from the RAW.
I don't agree that DCU does a better job with PS, except for automatic motion correction, than ACR/Lr. YMMV. See below.

ACR is also completely non-destructive in that in Ps it generates a file to work on, and leaves the RAW alone. Usually a PSD. Lr doesn't do anything but generate a preview using the same RAW conversion, so it's also non-destructive. Any differences in resolution I lose by foregoing DCU for PS I think are outweighed by the speed, efficiency, and other retouching options I get in using better software, be it Lr, FRV, Ps, etc etc.

And I agree about RawTherapee; I think it uses dcraw, no? if so, maybe it could be modified to do PS using the PS capable dcraw fork.
Attached Images
 
05-18-2016, 10:18 AM - 1 Like   #37
Site Supporter
Site Supporter
UserAccessDenied's Avatar

Join Date: Jan 2015
Location: Maryland
Photos: Gallery | Albums
Posts: 1,632
QuoteOriginally posted by stevebrot Quote
I may be a few years behind the curve, but it used to be that image scaling was done by declaration in the CSS with the browser following the direction of the developer.

Now comes the point of true confession. I should probably not complain about giant images on this site. I have a fast Internet connection* and the forum software has provision to set limits for image display on a per user basis.** (This is done by tailoring the CSS.) I used to have mine set to 1500 pixels horizontal and 800 vertical which allowed for reasonable horizontal and vertical scroll. I currently have that feature turned off because the browser-based down-sampling (scaling) affected image quality and users often submit larger example images for troubleshooting purposes.

Now back to the sharing of full-sized images. Here are a few bullet points to consider with no judgement or preaching on my part intended:
  • Page bloat can be a problem, particularly if several full-sized images are present. A high quality 36 Mpx JPEG is pretty good sized, bit-wise, and all those bits must be moved across the wire. This is particularly an issue on mobile devices where bandwidth is more dear and more expensive.
  • A 3:2 image above 16 Mpx size is not viewable as a whole (without scrolling) on commonly available displays. Impressive as one's work may be, nobody will be able to appreciate it.
  • All browsers suck at scaling. Regardless of whether done via CSS or native feature, the algorithms used are optimized for speed, not quality. The best way to respect screen real estate and user experience while maintaining quality is to use photo editing software to downsize to "Web" resolution.***
  • If one needs to provide a full-sized image for whatever purpose, providing a link (Drop Box, Flickr, etc.) in the body of the post is a good solution
  • If there is a need to show something at full pixel resolution, one or more full-resolution (100%) crops are easy on the user and fully informative. Snipping tools are useful for this chore.


Steve

* While dial-up is rare, relatively slow Internet access is still common in many areas and some users have reported bandwidth issues with extended page load times on image-heavy threads.
** The default setting for this feature is no restriction on image dimension.
*** "Web resolution" is hard to define, though most image posts on this site are the range of 800-1200 pixels on the long axis.
Thanks for that input!
Great info here!

One question I have, if I'm linking from Flickr I've read the proper way to do so is with the BBCode copy and pasted into my post.
Is there a way to only post a "web res" version of the full Flickr image while avoiding redundancies?

I could save a copy of it at a smaller scale, but then I would have duplicate images which I want to avoid...

I haven't found an easy way to do this from Flickr, and that's my primary storage source for 'final' products.


SCRATCH THAT!
I completely ignored the fact that I could select the image size with BBCode...
Woops!

I'll post at 800x532 from now on:


Thanks!
05-18-2016, 11:16 AM   #38
Site Supporter
Site Supporter




Join Date: Mar 2008
Location: Prince George, BC
Photos: Gallery | Albums
Posts: 2,599
As I understand it, non-destructive editing is a function of the editing program being used, not image format.

05-18-2016, 12:40 PM   #39
Otis Memorial Pentaxian
Loyal Site Supporter
stevebrot's Avatar

Join Date: Mar 2007
Location: Vancouver (USA)
Photos: Gallery | Albums
Posts: 30,461
QuoteOriginally posted by jbinpg Quote
As I understand it, non-destructive editing is a function of the editing program being used, not image format.
Yes, that is true. What distinguishes destructive from non-destructive is that non-destructive editing is able to persist changes without overwriting the original file or creating multiple interim versions.*


Steve

* Depending on how it is used, some programs (e.g. Lightroom) may be configured to write edit and other metadata out to the source DNG rather than using the catalog alone. In that mode, the edits are not technically non-destructive.
05-19-2016, 02:42 AM   #40
Pentaxian
microlight's Avatar

Join Date: Sep 2011
Location: Hampshire, UK
Posts: 728
Thanks for the fascinating discussion, everyone. Most of it I understood, but some I didn't (e.g. 'using the PS capable dcraw fork')! Clearly different opinions out there regarding what constitutes a non-destructive edit but that's fine, each to his or her own way of doing it. I've never been happy in having all my eggs in one Lightroom basket, and I do like how DCU5 renders, but that's me. And of course, there's motion correction which now makes K-3II pixel shift pictures much more friendly.
05-19-2016, 09:20 AM   #41
Loyal Site Supporter
Loyal Site Supporter




Join Date: Apr 2015
Photos: Albums
Posts: 663
QuoteOriginally posted by microlight Quote
Thanks for the fascinating discussion, everyone. Most of it I understood, but some I didn't (e.g. 'using the PS capable dcraw fork')! Clearly different opinions out there regarding what constitutes a non-destructive edit but that's fine, each to his or her own way of doing it. I've never been happy in having all my eggs in one Lightroom basket, and I do like how DCU5 renders, but that's me. And of course, there's motion correction which now makes K-3II pixel shift pictures much more friendly.
Sorry...that was uber geeky.

dcraw is a raw editing application written by Dave Coffin, http://www.v7f.eu/public/pentax/dcrawps.c

A Pentax user has modified it to work with pixel shift files, hence the fork or variant of dcraw. It can do manipulations that nothing else can do, like separate out each frame of the four into separate TIFF files, or mark the motion artifacts with a color so you can visualize them, etc. Examples are in the "pixel shift is finicky" thread on this forum.

It can be run from the command line on lots of various systems. It's also used within some other applications that have graphical user interfaces, although I don't think any of those have incorporated the PS components.
05-19-2016, 01:19 PM   #42
Otis Memorial Pentaxian
Loyal Site Supporter
stevebrot's Avatar

Join Date: Mar 2007
Location: Vancouver (USA)
Photos: Gallery | Albums
Posts: 30,461
QuoteOriginally posted by Oakland Rob Quote
dcraw is a raw editing application written by Dave Coffin, http://www.v7f.eu/public/pentax/dcrawps.c
The link is to the source code for the pixel shift fork of dcraw and is of limited usefulness unless you have a C compiler The cdraw Web site is at:

Decoding raw digital photos in Linux

...and the documentation is at:

Manpage of dcraw

...and tutorial is at:

GUILLERMO LUIJK >> TUTORIALS >> DCRAW TUTORIAL

...and precompiled Windows executables may be downloaded from (get one of these if you don't have a compiler for Windows):

dcraw


Yes, geeky, but playing a little with the program can take a bit of the mystery out of RAW processing and how your favorite tool does its work. I was particularly impressed when I was able to generate a TIFF with flat/linear response curves...the rawest of the RAW. Bring that into Lightroom if you care to appreciate what the import profile does for you.


Steve

(...big fan of dcraw...)
05-19-2016, 03:08 PM   #43
Loyal Site Supporter
Loyal Site Supporter




Join Date: Apr 2015
Photos: Albums
Posts: 663
QuoteOriginally posted by stevebrot Quote
The link is to the source code for the pixel shift fork of dcraw and is of limited usefulness unless you have a C compiler The cdraw Web site is at:

Decoding raw digital photos in Linux

...and the documentation is at:

Manpage of dcraw

...and tutorial is at:

GUILLERMO LUIJK >> TUTORIALS >> DCRAW TUTORIAL

...and precompiled Windows executables may be downloaded from (get one of these if you don't have a compiler for Windows):

dcraw


Yes, geeky, but playing a little with the program can take a bit of the mystery out of RAW processing and how your favorite tool does its work. I was particularly impressed when I was able to generate a TIFF with flat/linear response curves...the rawest of the RAW. Bring that into Lightroom if you care to appreciate what the import profile does for you.


Steve

(...big fan of dcraw...)
And you Mac users have one. Here's the instructions for the dcraw version, but it would work for dcrawps too. vk.photo.blog: DCRAW 9.21 for OS X Mavericks: compiling the program
Reply

Bookmarks
  • Submit Thread to Facebook Facebook
  • Submit Thread to Twitter Twitter
  • Submit Thread to Digg Digg
Tags - Make this thread easier to find by adding keywords to it!
acr, comments, faststone, image, images, information, input, jpg, k-3ii, mb, option, pdcu, photography, photoshop, pixel, pixel shift, play, shift, tiff, workflow
Thread Tools Search this Thread
Search this Thread:

Advanced Search


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pixel shift experiment wizofoz Pentax K-1 45 05-18-2016 04:14 AM
K1 Pixel Shift tjstimbo Pentax K-1 6 05-06-2016 10:11 AM
Landscape Pixel Shift devem Photo Critique 7 04-09-2016 01:22 AM
Pixel Shift Questions jatrax Photographic Technique 7 03-02-2016 08:38 AM
Pixel Shift brophyart Troubleshooting and Beginner Help 6 10-31-2015 02:53 PM



All times are GMT -7. The time now is 12:50 AM. | See also: NikonForums.com, CanonForums.com part of our network of photo forums!
  • Red (Default)
  • Green
  • Gray
  • Dark
  • Dark Yellow
  • Dark Blue
  • Old Red
  • Old Green
  • Old Gray
  • Dial-Up Style
Hello! It's great to see you back on the forum! Have you considered joining the community?
register
Creating a FREE ACCOUNT takes under a minute, removes ads, and lets you post! [Dismiss]
Top