Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Jeff Magidson on October 11, 2013, 11:19:20 am
-
I don't own a colormunki. When creating printer profiles with the munki, is it possible to tweak the profiles (adding or subtracting saturation for example) either during the profile creation process or after the fact?
If not, is there other software that I can use to edit the profiles?
~ Jeff
-
Not really. Yes, you can alter the perceptual table with differing settings (well you can in some versions, certainly i1Profiler). You can optimize the profile by printing more patches and updating the profile. But after creating the profile there is no editing functionality.
-
Jeff:
If you want to be able to create true custom profiles like you describe at a "reasonable" price, look at Data Color's SpyderPrint. Once you have read the patches, you have the options for many different sliders to fine tune the resulting profile including saturation and color balance and split toning. For B&W lovers, there is an extended gray patch set for creating precision toned B&W profiles.
Even though my Z3100 has the EyeOne Spectro built in, I prefer to use SpyderPrint because of these "tuning" capabilities. I would say the "default" profile with no tuning from the Spyder is just a touch better than that of the built-in spectro.
-
Spyder needs profiling editing (for a number of reasons, like the fact they don't provide a real Spectrophotometer like the ColorMunki and have to make a lot of assumptions). The question I'd ask the OP is WHY he feels the need to edit a profile? A good profile should not need any such editing. There are tweaks one can make to the perpetual table as this is fair game. So you can in some products do minor saturation editing that only affects that one table. But by and large, profile editing shouldn’t be necessary and is a high level function. It's sometimes needed for CMYK profiles to edit the paper white or when doing what is called cross rendering: Make my Epson match a CMYK proof. In such a case, minor tweaking is useful to force the match. But short of that, stay away from editing profiles.
-
The question I'd ask the OP is WHY he feels the need to edit a profile? A good profile should not need any such editing.
I'd like to be able to do this myself to convert a neutral profile to a 'toned' profile based on a color patch read from the Colormunki. The toning feature in ABW is pretty poor as it applies the tone globally with no ability to split tone. In my case, I have an old Canon printer that is totally NOT neutral with bluish shadows and off white highlights (that look fantastic), I would love to scan that Canon print with a ColorMunki and apply those hues to my neutral Epson profile. The feature from SpyderPrint looks interesting, can you enter a L*a*b* value directly ?
-
The question I'd ask the OP is WHY he feels the need to edit a profile? A good profile should not need any such editing. There are tweaks one can make to the perpetual table as this is fair game. So you can in some products do minor saturation editing that only affects that one table. But by and large, profile editing shouldn’t be necessary and is a high level function. It's sometimes needed for CMYK profiles to edit the paper white or when doing what is called cross rendering: Make my Epson match a CMYK proof. In such a case, minor tweaking is useful to force the match. But short of that, stay away from editing profiles.
Andrew, thanks for your comments and question.
Why do I want to edit a profile?: I have always felt that my Epson 3880 printed a tad low in saturation on luster paper with a custom profile based on printing the same file on other devices and comparing the output to my calibrated/profiled monitor. This was also reiterated when I purchased an IPF8300 and had Eric Chan make a custom profile for it and compared the output to my Epson 3880.
My goal it to get my Cannon IPF8300 and my Epson 3880 to match better.
-
Jeff:
If you want to be able to create true custom profiles like you describe at a "reasonable" price, look at Data Color's SpyderPrint.
Thanks John, Are the Spyderprint patches easy or difficult to read with the device that Data Color provides?
-
I'd like to be able to do this myself to convert a neutral profile to a 'toned' profile based on a color patch read from the Colormunki.
Why not tone the image and send it thought the profile?
-
I have always felt that my Epson 3880 printed a tad low in saturation on luster paper with a custom profile based on printing the same file on other devices and comparing the output to my calibrated/profiled monitor.
So the issue might be the preview portion of the profile isn't in sync with the output (it shows more saturation). A good profile tuning app can control either table (preview or output). Or you could apply a tiny saturation tweak to the profile with the available sliders for the perceptual table but if it up's the soft proof, you're back in this vicious cycle. But there's nothing out there that's inexpensive and easy to use that provides the capability to do such edits ala Kodak's old Custom Color ICC. Now that was an easy to use albeit not inexpensive profile editor. You might just have to soft proof, then add an output specific saturation layer tweak to match output to soft proof. Not ideal but simple and inexpensive.
-
Why not tone the image and send it thought the profile?
The files were converted from RGB to Grayscale, I didn't want to reconvert them back since the action is desctuctive - but maybe my fears are unfounded...
-
The files were converted from RGB to Grayscale, I didn't want to reconvert them back since the action is desctuctive - but maybe my fears are unfounded...
IF they are grayscale, why an ICC profile output profile I presume is RGB?
-
Thanks John, Are the Spyderprint patches easy or difficult to read with the device that Data Color provides?
The last iteration of the hardware/software works quite well. They do provide a "scanning" guide, which helps, but I found kind of clumsy. A visual scanning of the patches after reading to pick out misreads on screen is helpful and only takes a minute (the software also highlights major misreads). BTW, you can do readings in a "scanning mode" by line, or individual patch modes. It's very quick and easy to go back and re-read any patches you are suspicious of using the single patch mode and you will notice if there was a misread if the patch changes.
I have not used a Colormunki, so I could not tell you if the Spyder is easier or less so. But the ability to customize profiles, and to do extended gray scale calibrations for B&W printing are major plus' for the Spyder. If you are trying to match two prints from let's say, fine art paper, and canvas just using "straight" profiles you know how difficult that can be. Or as one poster noted, matching prints from two different printers, Spyder's profile customizing helps considerably.
As for the "accuracy" of the readings from the Spyder, I can't comment, but the resulting "straight" profiles from the Spyder & the EyeOne in the Z3100 are quite close.
Also, I've found that the 225 patch target does a good job vs. the 729 patch target. And when I've made profiles using both patch targets and compared, I've not seen an advantage to the larger set.
-
If you are trying to match two prints from let's say, fine art paper, and canvas just using "straight" profiles you know how difficult that can be.
Shouldn't be but you have to first find the profile with the smaller gamut, then cross render to that profile with an Absolute Colorimetric intent for paper white matching. You'd have to trim the non printable paper too. If you send two profiles 'as is' to two different papers, if they have differing gamuts and contrast ratio’s, you're going to see differences. Cross rendering is the process used to make printer A match printer B. Printer A has to have as large or larger gamut than the printer it hopes to match (you can't go backwards).
-
Shouldn't be but you have to first find the profile with the smaller gamut, then cross render to that profile with an Absolute Colorimetric intent for paper white matching. You'd have to trim the non printable paper too. If you send two profiles 'as is' to two different papers, if they have differing gamuts and contrast ratio’s, you're going to see differences. Cross rendering is the process used to make printer A match printer B. Printer A has to have as large or larger gamut than the printer it hopes to match (you can't go backwards).
Sounds like "goobly gook" to me Andrew!
But speaking from "real world experience", keeping the gamuts, contrast ratio's etc in mind, you can quickly and easily create modified profiles using Spyder, which you can't with the ColorMunki. Of course it won't be perfect, but a lot closer, depending on the medias you chose. And if you properly label and file your Spyder patch reads, you can go back in the future and modify the profile very quickly for other purposes.
-
Sounds like "goobly gook" to me Andrew!
Many concepts you don't understand seem like "goobly gook". Read this:
http://www.imagescience.com.au/kb/questions/88/Cross+Rendered+Proofing
http://www.computer-darkroom.com/ps8_proof/proof_1.htm
Cross rendering has been in Photoshop since version 5!
-
IF they are grayscale, why an ICC profile output profile I presume is RGB?
I'm not sure I understand, how else can I softproof my print ? I use an Epson icc profile for Hot Press Bright and was going to make my own profile with Colormunki. What should I be using ?
-
I'm not sure I understand, how else can I softproof my print ? I use an Epson icc profile for Hot Press Bright and was going to make my own profile with Colormunki. What should I be using ?
I've never tried it, but you're sending grayscale data through an RGB profile within the Print Dialog in Photoshop? Why soft proof if you're sending essentially grayscale data to the printer? Or to put it another way, IF you're sending RGB data, and the soft proof shows differences when you use different rendering intents, why not just stick with RGB documents? Now if you want to tone the prints as you suggest, I'd stick with RGB and do it in Photoshop proper (or Lightroom), then use the RGB ICC profiles in an attempt to match that. IOW, they are B&W toned images, treat them as RGB color images, which they are. That's how I handle toned images. Then you don't have to futz with profile editing. You use the same profile for both color and toned B&W work. You'll have far more control over the toning using an image editor than an ICC profile. If you're on a Mac, you could look into Quartz filters but again, compared to using an image editor for toning, it's not very powerful.
-
I don't own a colormunki. When creating printer profiles with the munki, is it possible to tweak the profiles (adding or subtracting saturation for example) either during the profile creation process or after the fact?
If not, is there other software that I can use to edit the profiles?
~ Jeff
Why not make printing adjustment layer to fine tweak the output ? This is what I do. As recommended by the eminent Jeff Schewe in ‘Real World Photoshop’.
-
I've never tried it, but you're sending grayscale data through an RGB profile within the Print Dialog in Photoshop? Why soft proof if you're sending essentially grayscale data to the printer? Or to put it another way, IF you're sending RGB data, and the soft proof shows differences when you use different rendering intents, why not just stick with RGB documents? Now if you want to tone the prints as you suggest, I'd stick with RGB and do it in Photoshop proper (or Lightroom), then use the RGB ICC profiles in an attempt to match that. IOW, they are B&W toned images, treat them as RGB color images, which they are. That's how I handle toned images. Then you don't have to futz with profile editing. You use the same profile for both color and toned B&W work. You'll have far more control over the toning using an image editor than an ICC profile. If you're on a Mac, you could look into Quartz filters but again, compared to using an image editor for toning, it's not very powerful.
Hi Andrew, I tried your suggestion over the weekend and I'm runnning into a strange problem. When I convert the grayscale image to RGB, some shadow detail is getting lost. Looking at the histogram, I get a sharp spike on the very left after the conversion and the end result is a "muddied" shadow. I've tried all sorts of conversions with differenct RGB color spaces and rendering intents. Any idea what might be going on ? Is there a better way of converting to RGB ?
-
What is the source for the grayscale? Gray Gamma, dot gain?
-
What is the source for the grayscale? Gray Gamma, dot gain?
Gray Gamma 2.2
-
Gray Gamma 2.2
So any difference when you convert to say sRGB (which has a 2.2 gamma) vs. ColorMatch RGB which has 1.8?
-
So any difference when you convert to say sRGB (which has a 2.2 gamma) vs. ColorMatch RGB which has 1.8?
I don't remember using sRGB, only AdobeRGB and ProPhotoRGB. I'm at work but I'll try it again tonight !
-
I don't remember using sRGB, only AdobeRGB and ProPhotoRGB. I'm at work but I'll try it again tonight !
You want to match the gray gamma to the RGB color working space gamma.
-
So any difference when you convert to say sRGB (which has a 2.2 gamma) vs. ColorMatch RGB which has 1.8?
Hello,
I'm sure you perfectly know that sRGB has not exactly a 2.2 gamma, it is overall similar but it is not a pure gamma curve: according to colorspace definition the very deep shadows are linear.
In addition all gamma curved colorspaces in Adobe software have a numerical implementation that limit the maximum slope, this affect the first 14 RGB triplets in AdobeRGB (the junction point being 14) and GrayGamma 2.2 and the first 4 RGB triplets in ProPhoto.
sRGB is not affected from this slope limit because the linear shape is already part of the colorspace definition itself and not an external implementation applied by the software color management engine.
For the sake of precision the exact gamma exponent in the AdobeRGB and Graygamma 2.2 is 2+(51/256)=2,19921875, as visible looking to the icc with a profile inspector.
Now, assuming an AdobeRGB and GrayGamma 2.2 working spaces in PS,
I bet the little spike you see growing in the histogram after Gray/RGB conversion is exactly at 14,14,14 (which is shifted toward 13,13,13 after the conversion).
You can easily verify it by doing a RGB/gray/RGB loop using a full wedge grayscale.
If this is the case, this is probably the slope limit implementation of Adobe ACE in action, it happens in 16 bit too obviously (which in reality are 15 bit in PS) and this is very curious because in theory the gamma curve (and the limited slope) should be exactly the same for the AdobeRGB and Graygamma 2.2 colorspaces.
Other than this, which is a numerical artifact, you should not see noticeable variations in the RGB values outside the slope limited region above mentioned.
I hope this could be useful,
Ciao.
Andrea :)
-
I'm sure you perfectly know that sRGB has not exactly a 2.2 gamma
Yes. The OP has to convert to an RGB working space so the gamma should match (closely). One could build a simplified 2.2 sRGB profile directly in Photoshop's Color Setting too. The original data is in color so it seems best to leave it that way but for the time being, the converted grayscale files need to be converted into some RGB color space.
-
Hello,
I'm sure you perfectly know that sRGB has not exactly a 2.2 gamma, it is overall similar but it is not a pure gamma curve: according to colorspace definition the very deep shadows are linear.
In addition all gamma curved colorspaces in Adobe software have a numerical implementation that limit the maximum slope, this affect the first 14 RGB triplets in AdobeRGB (the junction point being 14) and GrayGamma 2.2 and the first 4 RGB triplets in ProPhoto.
sRGB is not affected from this slope limit because the linear shape is already part of the colorspace definition itself and not an external implementation applied by the software color management engine.
For the sake of precision the exact gamma exponent in the AdobeRGB and Graygamma 2.2 is 2+(51/256)=2,19921875, as visible looking to the icc with a profile inspector.
Now, assuming an AdobeRGB and GrayGamma 2.2 working spaces in PS,
I bet the little spike you see growing in the histogram after Gray/RGB conversion is exactly at 14,14,14 (which is shifted toward 13,13,13 after the conversion).
You can easily verify it by doing a RGB/gray/RGB loop using a full wedge grayscale.
If this is the case, this is probably the slope limit implementation of Adobe ACE in action, it happens in 16 bit too obviously (which in reality are 15 bit in PS) and this is very curious because in theory the gamma curve (and the limited slope) should be exactly the same for the AdobeRGB and Graygamma 2.2 colorspaces.
Other than this, which is a numerical artifact, you should not see noticeable variations in the RGB values outside the slope limited region above mentioned.
I hope this could be useful,
Ciao.
Andrea :)
Hi Andrea, your knowledge of colorspaces is much better than mine, I'm still trying to wrap my brain around everything you said :) I'll have to check again but I believe 14 => 13 is where it's happening, the rest of tones are the same - only very deep shadows are being affected. The histogram changes after the conversion but is not visible on screen until I Softproof, and it is also visible in the final print. What can I do to counteract this ? Is there an alternate method of converting the file ? Unfortunately I have several grayscale file originals that were intended to be printed in QTR using piezography inks. But now I'm using my own printer and want to apply a split tone; aside from this shadow problem Andrew's toning suggestions gives a really nice result.
I tried sRGB but no difference... I can attach a crop of the file tonight if it might be helpful.
Paul
-
Yes. The OP has to convert to an RGB working space so the gamma should match (closely). One could build a simplified 2.2 sRGB profile directly in Photoshop's Color Setting too. The original data is in color so it seems best to leave it that way but for the time being, the converted grayscale files need to be converted into some RGB color space.
Some are RGB originals but I have several grayscale originals as well :( and months' worth of work tied into these images (I tried copying all my layers to an untouched RGB original but it's way off I really want to avoid having to redo all my work). How do I go about creating a 'simplified' 2.2 sRGB profile in Photoshop ?
-
How do I go about creating a 'simplified' 2.2 sRGB profile in Photoshop ?
If you go into the Color Settings, RGB working space drop down menu and select sRGB, save that out, the new profile (which you should rename) Photoshop will use a simplified 2.2 gamma curve to create this ICC profile. Not sure that will help or is necessary.
-
If you go into the Color Settings, RGB working space drop down menu and select sRGB, save that out, the new profile (which you should rename) Photoshop will use a simplified 2.2 gamma curve to create this ICC profile. Not sure that will help or is necessary.
Didn't help...
Here is the grayscale image softproof:
(http://www.paulozzello.com/ExternalImages/good.jpg)
And the the same softproof after converting to RGB:
(http://www.paulozzello.com/ExternalImages/bad.jpg)
And a small crop of the original image:
test.psb (http://www.paulozzello.com/ExternalImages/test.zip)
We're looking at the bottom left section of
(http://www.paulozzello.com/Images/selectedworks/large/chelsea_t.jpg)
PS - sorry Jeff for hijacking your thread :(
-
But do the two appear the same prior to the soft proof?
-
But do the two appear the same prior to the soft proof?
Hello Andrew and Paul,
from what I have seen the two appear nearly the same prior the soft proofing,
so this is something related to the soft proofing calculations/visualization imho...
I have tried several different paper profiles and got every time a different behavior on RGB and GrayGamma2.2 images.
The results are different even if you soft proof choosing perceptual rendering intent without BPC.
So at this point my opinion is to... don't trust the soft proof visualization too much for critical BW shadows appearance.
I know it could seem weird, but I think that if you print the little test crop for real in the RGB and Gray version, it does not show noticeable difference or at least not of the degree you see in the simulated soft proof visualization.
Regarding the not perfect conversion between Gray and RGB:
this is the result of the ACE numerical implementation of the slope limit. This occurs every time you convert between colorspaces based on gamma curve, and you can easily spot it by a simple RGB->Lab->RGB loop.
If you open a gray full wedge in AdobeRGB and then you make a Lab mode and then a RGB mode again, you will see the weird spike appearing in the histogram around RGB 14.
If you do the same in sRGB you will see that the spike does not appear, because there is not the slope limit active there.
If you set as working spaces sRGB and sGray and you make the RGB/Gray conversion you will see that no spike occurs.
Unfortunately I'm not aware of a simple conversion method in PS that could allow you to avoid this numerical artifact.
(note that this was one of the reason why I have decided to implement my Linearization curves in a DeviceLink icc by doing all the math in floating point: this allows me to make a virtual RGB->Lab->RGB trip with zero errors).
In any case I don't think that in real world prints the numerical mismatch of a single RGB/Gray conversion in the RGB 14 zone should be so noticeable, so my suggestion is to don't worry it too much and to try a test print of the crop without trusting the soft proof visualized mess too much...
Just my 2 cents...
Ciao.
Andrea :)
-
But do the two appear the same prior to the soft proof?
Yes, they do.
-
Hello Andrew and Paul,
from what I have seen the two appear nearly the same prior the soft proofing,
so this is something related to the soft proofing calculations/visualization imho...
I have tried several different paper profiles and got every time a different behavior on RGB and GrayGamma2.2 images.
The results are different even if you soft proof choosing perceptual rendering intent without BPC.
So at this point my opinion is to... don't trust the soft proof visualization too much for critical BW shadows appearance.
I know it could seem weird, but I think that if you print the little test crop for real in the RGB and Gray version, it does not show noticeable difference or at least not of the degree you see in the simulated soft proof visualization.
Regarding the not perfect conversion between Gray and RGB:
this is the result of the ACE numerical implementation of the slope limit. This occurs every time you convert between colorspaces based on gamma curve, and you can easily spot it by a simple RGB->Lab->RGB loop.
If you open a gray full wedge in AdobeRGB and then you make a Lab mode and then a RGB mode again, you will see the weird spike appearing in the histogram around RGB 14.
If you do the same in sRGB you will see that the spike does not appear, because there is not the slope limit active there.
If you set as working spaces sRGB and sGray and you make the RGB/Gray conversion you will see that no spike occurs.
Unfortunately I'm not aware of a simple conversion method in PS that could allow you to avoid this numerical artifact.
(note that this was one of the reason why I have decided to implement my Linearization curves in a DeviceLink icc by doing all the math in floating point: this allows me to make a virtual RGB->Lab->RGB trip with zero errors).
In any case I don't think that in real world prints the numerical mismatch of a single RGB/Gray conversion in the RGB 14 zone should be so noticeable, so my suggestion is to don't worry it too much and to try a test print of the crop without trusting the soft proof visualized mess too much...
Just my 2 cents...
Ciao.
Andrea :)
Thank you both for all the efforts trying to help me out :)
I did some further testing this weekend and went through some of my original scans. Turns out this particular image was scanned in AdobeRGB (I had converted it to grayscale myself). So without modifying the RGB file I softproofed it... and it showed the exact same problems in the shadows ! And stranger still after conversion TO Grayscale the softproof is fine ! So the problem appears to be elsewhere...
???
Unfortunately the effect is also noticeable in the final print (the above crop of is 4.5" x 11" of the final 44" print)
Paul
-
Hello Paul,
There are two things:
- the not perfect RGB/Gray conversion done by ACE for the above explained reasons, affecting the very deep shadows. There is no easy way to avoid this, but the visual real effect could be considered negligible for a single conversion in my opinion.
This is somewhat confirmed by the fact that your crops are looking nearly the same before soft proofing and you can spot the slight difference only by looking at the histograms.
So in any case I think this aspect is not something to be really worried about.
- the noticed difference in soft-proofing (and real prints to some degreee, as you have found) in the shadows zone between the same RGB and Gray converted images, even with colorspaces matching the same gamma value.
In addition the results are varying depending on the ICC profile used.
This is very tricky, and the fact that this is not only a visual effect but it is somewhat reflected in the real print is not so easy to explain, given that the source files are looking nearly identical on screen before soft proofing.
I hope someone more skilled than me cold put some light over this aspect.
In the meantime the further only thing I can suggest you is to try to print the RGB/Gray test crops even using "Perceptual" intent and NO black point compensation, and see if the printed results could be better matching the original file as seen on screen before soft proofing.
Maybe this workaround could mitigate the difference to an acceptable degree, let we know.
As last resort, if you could consider feasible avoiding the possibility to have split toned images and to soft proof the preview, try to bypass the ACE at all and print the RGB/Gray test crops letting the printer to manage colors and engaging ABW (neutral dark setting to start) on the Epson (I don't know if there is something equivalent on the big Canon). This will give you a bit of higher dmax too. it could be interesting to see if the printed crops in this case are better matching the files on screen. If the case you have at least another workaround available, I know that this is not ideal but it's still better than none.
Any further comment/opinion is welcome.
Ciao.
Andrea :)
EDIT: I'm suggeting to use "Perceptual" without BPC and not "Relative colorimetric" with BPC,
as wrongly written previously and as now corrected. Sorry for the typo.