Mike Chaney's Tech Corner
November 17, 2024, 11:50:45 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Qimage registration expired? New lifetime licenses are only $59.99!
 
   Home   Help Login Register  
Pages: [1] 2
  Print  
Author Topic: Understanding Best Practices For Highest Quality Print  (Read 12985 times)
ghuggins
Newbie
*
Posts: 3



WWW Email
« on: January 03, 2019, 11:17:58 PM »

I have been using the latest QImage for years.  I have been printing on an Epson 7900.  It died and I am now printing on an Epson P9000.  In the process of getting it calibrated I think I have found a flaw in my workflow that needs improvement for the best prints possible.  Here is my current workflow:
I calibrate my monitor with Colormunki
Then I develop icc profiles for each paper with Colormunki
I then put those two profiles in QImage Ultimate for printing (turning off profiles in Epson driver of course)

Now here is my image workflow:
Shoot images using Nikon D850 in raw with 14bit depth
Transfer raw files to hard drive and open/process in Lightroom
Once I get my "keepers" I export them from Lightroom using a low-res image with sRGB for web posting and export to jpeg with Adobe RGB full resolution JPEG
Print from those JPEGS as needed using QImage Ultimate.

Here is where I think I have a problem:  BY SAVING AS JPEG WITH ADOBE RGB AND PRINTING FROM THOSE JPEG FILES INSTEAD OF FROM LIGHTROOM DIRECTLY (using Qimage in Lightroom) have I potentially thrown out pixels because they were saved in Adobe RGB?  Because Lightroom is using Prophoto color space would all pixels printable by my P9000 be captured by changing my workflow?  Maybe this is cutting hairs/unnecessary?Huh? It's certainly easier to print directly from QImage rather than Lightroom.

This color management seems a bit complex and I want to do all I can to print the best prints possible. 

Thanks for any help/thoughts.

Greig
Logged
BrianPrice
Sr. Member
****
Posts: 265



WWW Email
« Reply #1 on: January 05, 2019, 11:56:34 AM »

Grieg

Your workflow is exactly the same as mine, and I believe is the best one to use.
First, you do not lose any pixels when saving in aRGB as opposed to Prophoto - it's only the colour of the most saturated pixels that is changed when aRGB is used. These colours cannot be captured by your camera, cannot be seen on your monitor, and your printer can only print a very limited number of the saturated colours which lie outside the aRGB gamut, but are included in Prophoto. I doubt very much if these colours ever occur in a photograph, so saving in Prophoto is using a sledgehammer to crack a nut, and can lead to more problems that it solves.

Brian
Logged
ghuggins
Newbie
*
Posts: 3



WWW Email
« Reply #2 on: January 10, 2019, 07:24:17 AM »

Brian,
Thanks for the input.  I have been trying to save/print in Prophoto and it is a mess trying to keep everything straight. 
Where I get sidetracked is when I plot aRGB in Perfx Gamut Viewer and then overlay my Colormunki printer profile, the yellows and dark blues are outside aRGB color space.  I think your point is that they are likely never seen in a photograph and are likely not captured in the first place.
I think I will keep my "old" workflow as you suggest!
Thanks again!
Logged
Terry-M
The Honourable Metric Mann
Forum Superhero
*****
Posts: 3251



WWW
« Reply #3 on: January 10, 2019, 08:15:56 AM »

Quote
Where I get sidetracked is when I plot aRGB in Perfx Gamut Viewer and then overlay my Colormunki printer profile, the yellows and dark blues are outside aRGB color space
The whole point of colour management is to deal with different color spaces and out of gamut  colours. When you print in QU, there's a choice of how this is done: Perceptual or Relative are the main choices for normal photographic printing.
You may find some useful information here: https://www.cambridgeincolour.com/color-management-printing.htm
Terry
Logged
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #4 on: January 10, 2019, 03:37:17 PM »

It's a complex subject but just to try to break down the basics...

In order for a color that is outside aRGB gamut to make it to print, a lot has to happen:

(1) Your subject's color has to be outside the aRGB gamut: let's say a super saturated yellow flower in bright sunlight.
(2) The lighting and exposure generally has to be such that the subject (yellow flower) is the brightest object in the frame.
(3) Your camera's sensor has to have enough gamut to capture that color in the first place (shooting in raw of course).
(4) Your raw developing software has to have internals (a camera ICC profile) that can support that out-of-aRGB color on developing.
(5) Your printer has to be able to reproduce that color given the ink, paper type, and printer profile you are using.

Now, for an image that makes it through all those checkpoints, technically ProPhoto would produce better color for those saturated yellows.  Whether or not you notice in print would depend on how much of the yellow flower is out of gamut, whether you use perceptual or RC intent, and other factors.  These are rare cases but that's not to say they don't happen.  I've never personally seen a case where I actually needed ProPhoto to reproduce bright colors and I tend to take a lot of flower shots with very saturated colors.  But part of that is because I let Qimage develop my raws.  If you develop your raws in Qimage there is no need to select a color space like aRGB or ProPhoto because Qimage has camera profiles for most of the popular cameras: it uses the camera profile rather than converting to a color space.  That means that color stays in the optimal color space (the color space of the camera) and in 16 bits/channel all the way to when the data is delivered to the driver for printing.  And even at print time, it does a 16 bit/channel dither so you get effective 16 bit/channel dithering even on 8 bit printer drivers.

If you develop your raws in other software and have to save them out to print in Qimage, I'd just use aRGB because it'll be sufficient for 99.9% of photos.  Then you could use ProPhoto on that .1% only if you notice a problem with bright colors in print.  Again, never happened for me but I suppose given the infinite variety of conditions going through steps 1-5 above, some could run into that more than others.  Some people may be working with specialized logo colors, for example, that may be outside the aRGB gamut in which case ProPhoto makes sense.  But for nearly all "in the wild" photographic content, ProPhoto is overkill.

Regards,
Mike
Logged
ghuggins
Newbie
*
Posts: 3



WWW Email
« Reply #5 on: January 11, 2019, 07:20:01 AM »

Mike,
Thanks for spending the time to outline this.  It just re-affirms the fact that my original workflow is more than adequate for nearly all of my photographs.
This is a great forum for a great product.

Greig
Logged
JeffR
Newbie
*
Posts: 24


Email
« Reply #6 on: January 11, 2019, 07:48:22 PM »

But you ARE throwing away important color information by using jpgs which are 8 bit rather than tiffs or RAW or even PSDs which support 16 bit files.  See https://www.youtube.com/watch?v=LqE8FBiDLwE, beginning about 59:58
Logged
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #7 on: January 11, 2019, 08:23:50 PM »

But you ARE throwing away important color information by using jpgs which are 8 bit rather than tiffs or RAW or even PSDs which support 16 bit files.  See https://www.youtube.com/watch?v=LqE8FBiDLwE, beginning about 59:58

While I agree you should never throw away data when editing, that video is beyond misleading.  In order to see a difference (8 vs 16 bit), he had to compress the image to near zero dynamic range by dragging both the shadow and highlight sliders inward to middle gray, and then expand it back out?  Who does that?  And if you keep watching a few minutes, his description of what perceptual vs relative colorimetric intents actually do is just wrong.

Mike
Logged
JeffR
Newbie
*
Posts: 24


Email
« Reply #8 on: January 11, 2019, 10:36:46 PM »

I respect the fact that you know more than I do re bit depth. However I have seen issues, ie. banding, when editting anjpg vs z16 bit tiff image. This has convinced me to donall editting as 16 bit files.
Logged
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #9 on: January 12, 2019, 12:21:01 AM »

I respect the fact that you know more than I do re bit depth. However I have seen issues, ie. banding, when editting anjpg vs z16 bit tiff image. This has convinced me to donall editting as 16 bit files.

You can easily run into banding and other problems if you try to push a JPEG which is why the editing phase is always best done in 16 bits/channel: editing the raw in refine in Qimage or in LR, PS, whatever.  If you need to make larger adjustments in exposure such as trying to re-expose for clouds or you took a shot where a bright spot caused the image to be underexposed and you need to increase exposure a lot... you can't do that sort of thing with a JPEG.  But once you've done the major editing steps and you've adjusted exposure, shadows, highlights, that final image will hold up without banding in either 8 or 16 bits/channel.  If I have an image with high dynamic range, I'd probably still save in 16 bits/channel so Qimage can optimize the gradients when sending it to the printer driver.

Mike
Logged
JeffR
Newbie
*
Posts: 24


Email
« Reply #10 on: January 12, 2019, 01:26:43 PM »

Makes perfect sense
Logged
JeffR
Newbie
*
Posts: 24


Email
« Reply #11 on: January 12, 2019, 01:27:49 PM »

What was your objection to the description of perceptual v relative rendering ?
Logged
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #12 on: January 12, 2019, 05:45:22 PM »

What was your objection to the description of perceptual v relative rendering ?

The graphic looked good and I thought he was going to explain it right but what he said was:

Perceptual: "Compresses colors that are outside to be inside, but keeps the colors that are inside basically the same."
RC: "Moves them all relative.  So the colors that are outside move in, but the colors that are in also get moved closer together."

The above verbal description is basically backwards.  If you swap his two verbal descriptions and remove the "Moves them all relative" statement, it'd be basically correct.  The point being, perceptual scales all colors, even those that are in-gamut which can have an overall dulling (desaturation) effect even on colors that could have been reproduced accurately (are in-gamut).  Unlike perceptual, relative colorimetric renders in-gamut colors correctly and doesn't move them and only moves out-of-gamut colors inward... generally to the gamut hull, that is, the closest color that CAN be reproduced.  This is why RC is often recommended: because many images won't contain out-of-gamut colors or at least few out-of-gamut colors and with RC, you know the colors that can be reproduced will be reproduced accurately rather than being "dulled" via scaling.

Mike
Logged
JustGeorge
Jr. Member
**
Posts: 93


« Reply #13 on: January 12, 2019, 08:02:59 PM »


-<snip>-

The above verbal description is basically backwards.  If you swap his two verbal descriptions and remove the "Moves them all relative" statement, it'd be basically correct.  The point being, perceptual scales all colors, even those that are in-gamut which can have an overall dulling (desaturation) effect even on colors that could have been reproduced accurately (are in-gamut).  Unlike perceptual, relative colorimetric renders in-gamut colors correctly and doesn't move them and only moves out-of-gamut colors inward... generally to the gamut hull, that is, the closest color that CAN be reproduced.  This is why RC is often recommended: because many images won't contain out-of-gamut colors or at least few out-of-gamut colors and with RC, you know the colors that can be reproduced will be reproduced accurately rather than being "dulled" via scaling.

Mike

My brain just hit a speed bump.  It sounds like you're suggesting that RC is a better intent to use in most cases, but the "Color Management" dialogue in QU shows Perceptual as the default.  I understand that factors such as image source, editing process, final output/media can contribute to choosing between RC & PC.  So my question is:  why did you choose PC as the default over RC?

--George
Logged

~I'm not a photographer, but I play one in real life.~
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #14 on: January 12, 2019, 11:09:45 PM »

My brain just hit a speed bump.  It sounds like you're suggesting that RC is a better intent to use in most cases, but the "Color Management" dialogue in QU shows Perceptual as the default.  I understand that factors such as image source, editing process, final output/media can contribute to choosing between RC & PC.  So my question is:  why did you choose PC as the default over RC?

--George


The two offer different tradeoffs when it comes to printing images that contain out-of-gamut colors.  RC is often considered a more "advanced" approach because when you do run into an image that has out-of-gamut colors in the main subject, you have to be able to recognize what is causing the loss of detail or other issues you might be seeing.  At that point, you can decide how to handle that situation and whether to use perceptual for that image, adjust the exposure, etc.  The reason perceptual is the default is because it produces consistent results and results in the fewest "what is causing this" complaints.

It's a bit like telling someone to "just shoot raw" without first learning to properly expose the scene, how to pick the proper aperture, what shutter speeds are acceptable for various focal lengths and lighting, etc.  So we start with perceptual and work our way up to the "more accurate" RC once we've gotten our printing workflow straightened out, profiles created, and so on.

Regards,
Mike
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Security updates 2022 by ddisoftware, Inc.