View Full Version : Sacrilege? sRGB Jpegs
Peter Mendelson
June 6th, 2006, 08:04 PM
Preface: I am an amateur who shoots for fun.
I have been shooting exclusively RAW for a long time now, and constantly read about how people should be converting to aRGB Tiffs for best quality. I have generally been doing most of my adjustments in my RAW converter, and converting to sRGB JPEGs and have been pretty happy with the result. I mostly take candids of friends and family, and some travel and landscape as well. For my best travel and landscape shots, I convert to aRGB Tiffs (and convert these to sRGB for emailing/web).
I just could not imaging converting all my RAW shots to TIFFs rather than JPEGs - it seems like a huge waste of space for shots that I don't plan to print (is a candid of a friend I am going to email or post to the web really worth storing as a 79mb TIFF in addition to the smaller web copy?).
My question is: am I one of the only ones who do this? Are most discussions of what file formats and color spaces to use aimed at pros selling prints or shooting professionally? What do you pros do when shooting more casual shots for fun - do you use the same workflow and save to TIFF, etc., or do you try to save space and time and save to JPEG, etc.? I am really curious, because in all of the PSCS2 and Raw books I have read I almost never read about having a different workflow based on the seriousness of the shot - I get the impression the authors convert all their Raw files to 16-bit TIFFs or the like.
Thanks,
Peter
Nill Toulme
June 6th, 2006, 08:29 PM
I shoot all RAW, all the time. I don't consider myself a good enough shooter to shoot jpg; I need the substantial room for error that RAW gives me. As to your questions, very briefly and FWIW:
It seems to me that what you convert to or whether you convert at all depends on your intended use of the particular image. If you're just going to e-mail it to a friend, of course what you want is an sRGB jpg.
If you're going to print it, why *not* convert to tif rather than jpg?
If there are intermediate steps called for in the way of post-processing, again, why *not* convert to tif, and depending on your system resources, perhaps even 16-bit tif?
Now, setting that aside, how you *save* the image is another matter entirely. Obviously you save the RAW file; that's your "negative." If you're not going to e-mail the pic again to someone else, why save the jpg too? Similarly, if you're not going to print it again, and assuming that you haven't done a lot of post-processing work that you might have to recreate later, why save the tif?
On the other hand, if you've worked an image heavily, you probably want to save all that work. That means saving not only the RAW file, but also the .psd version with all its layers, and maybe a flattened tif copy of it for quick reprinting. But how many of your images fit that description?
Bottom line: I throw out the non-keepers (another philosophical discussion entirely) and for the keepers, as a general rule, I just save the RAW files. Caveat: I mostly shoot sports and events. If I were a "fine art" photographer, the previous paragraph would probably describe my usual practice.
Nill
~~
www.toulme.net
Peter Mendelson
June 6th, 2006, 08:56 PM
Thanks Nill. I guess since about 75% of what I shoot does not get printed, I find it hard to justify saving everything as a TIFF, and since I always keep the RAW file, I feel I can always go back and reconvert to a TIFF if I decide later want to print a particular file (although frankly I have been getting very nice prints from my JPEGs as well).
However, your point about converting to a 16-bit TIFF at first for editing purposes is a good one - I have a reasonably fast PC with 2GB of ram so I should be doing this as a matter of course.
I am still struggling with the whole sRGB/aRGB thing, though, since I post and email way more photos than I print, and it doesn't make sense to me to work with aRGB as my default when what I am doing with most of my files is better served by sRGB. Again, for more important files I am going to print, I can convert to aRGB.
Thanks,
Peter
Nill Toulme
June 6th, 2006, 09:15 PM
This one starts to get a little over my head, but I think it's better to work in Adobe RGB and then convert to sRGB as and when necessary. Because the latter is a smaller color space than the former, converting in the other direction accomplishes nothing because the information is already lost. Converting to sRGB is trivial, so there's no reason not to work in Adobe. But that's assuming you're working at all. If it's just a straight conversion to web or e-mail use, then you might as well go right to sRGB.
Hmmm... on re-reading your message, I think we're saying the same thing. I don't think you're proposing to work your files in sRGB and then convert them from there to Adobe for print. But just in case... don't do that.
Nill
~~
www.toulme.net
Stan Jirman
June 6th, 2006, 09:30 PM
Let me throw in my two cents. I shoot everything raw + S, that way I can get a very quick preview which I use for editing, and then the images that I really want to use I convert from raw to sRGB JPG using C1Pro (usually). What happens to these images? They get batch processed for web use, 90% of them anyway.
I print only a small fraction of images, and I think the majority of people out here are in the same boat. Those pictures that I want to print - or keep "prepared" for posterity - I convert to 16-bit TIFF with WideGamut RGB color space, also in C1. These images are then cleaned up and stashed away (in small numbers), and can be further processed (sharpened) for printing.
The sRGB JPGs from the first C1 pass are trashed. I don't need them anymore; but I do keep the C1 image settings - the recipes - so that I can re-process the images any time I want again. And indeed it happened that I went back 2-3 years and dug out a particular image that didn't seem worth archiving then, processed it with the original C1 recipe (or an adjusted one), and voila, ready to print.
The reason why I don't use aRGB with JPGs is simple: the wider the gamut, the worse the precision per bit (more likely to get banding, for instance). To me, JPGs are intended purely for the web, and the best screens available today are just about sRGB in gamut. Plus, no matter what you do, a PC browser will interpret an image always as sRGB, even if it had a different profile embedded - so the majority of the people could not see the benefits, anyway. So anything wider would be wasted, since you still can't see it on the intended output device, and the precision suffers. With TIFFs, where I can go 16 bit, using a really wide gamut (one that can preserve the color of my yellow hat, for instance) is a good idea.
A few people around here know me and what I've done over the past 2 years with regard to color; so I hope I am making an at least somewhat believable case :)
As an aside, another reason why I always shoot raw+S is that the JPG file has the full EXIF embedded. Even when you process a CR2 file with DPP, the resulting JPG won't have as much EXIF data in it as the "original" JPG would. Since I am in no way interested in using DPP (unless they totally overhaul it), being able to read even somewhat strange EXIF tags without access to OEM software is important to me.
Nill Toulme
June 6th, 2006, 09:38 PM
Interesting points Stan. I take your point about going straight to sRGB for web-bound images. But why straight to jpg if further batch processing for web is intended? That means saving as jpg at least twice, which means loss of info and gain of artifacts, no? Why not convert those at least to 8-bit tifs and then do the batch processing?
Also very interesting re the EXIF info. Do you happen to know if the separate jpg embedded within the CR2 RAW file also contains the full panoply of EXIF? BreezeBrowser Pro at least will extract that jpg.
Nill
~~
www.toulme.net
Stan Jirman
June 6th, 2006, 09:47 PM
Nill,
first of all, the embedded JPG in the CR2 has no EXIF whatsoever. If it did I would have stopped using JPG a long time ago (and use the embedded JPG for previewing, too).
The reason why I use sRGB JPGs for batching to web is convenience. The pictures that end up on the web are 800-1024 wide; max. 1280. I shoot with a 1Ds2, so you are looking at a scaling factor of 4-5x. Between that, no JPG artifacts will survive, take my word for it. However, I save quite some space on disk (don't know about you, but I am always tight :)) and there's also loading time; a 1:10 compressed JPG takes a much shorter time to load and decompress than a "straight" TIF.
Because sometimes I keep these "intermediate" JPGs around for quite a while, this space savings matters to me. I have yet to see any quality differences - again, for printing (and thus more strict post processing) I use 16b TIFF.
Nill Toulme
June 6th, 2006, 09:52 PM
Makes sense to me. And yes, I'm usually tight on space, but I just built myself a 1.1TB RAID so I'm breathing easier on that score... for a few months at least. ;-)
Nill
~~
www.toulme.net
Doug Kerr
June 6th, 2006, 09:59 PM
Hi, Nill,
On the other hand, if you've worked an image heavily, you probably want to save all that work. That means saving not only the RAW file, but also the .psd version with all its layers . . .
I save a .ppf file in that situation. It loads must faster in the editor.
Stan Jirman
June 6th, 2006, 10:03 PM
Hehe. I built a 5x400GB RAID-5 (Vanguard AV) about a year ago, and I am down to 180G free - and that's after evicting all my old neg/slide scans to a separate drive. At that point, the RAID5 performance goes seriously to hell. My last 2-day assignment which filled 80G didn't help things... I will hold out until the next big project, and then probably go to the new 750G drives which should last a couple of years.
Ray West
June 7th, 2006, 04:26 AM
A slightly different take, prompted by Stans's post.
Many years ago, I prepared a table comparing the physical size of storing data, I guess you know the sort of thing, a cd with a volume of half a cubic inch, holds the same information as a shelf full of encylopedia, or a stack of A4 typed sheets 3 miles high, whatever.
I wonder what the ratio is wrt 35mm film, and say 16bit tiffs from a 20m pixel camera (or whatever digital size you assign to 35mm film quality). It may be that 35mm film is more compact then we initially think.
Best wishes,
Ray
Don Cohen
June 7th, 2006, 04:55 AM
As a first general comment:
My personal workflkow at this point is to use Capture One to process all the Raw files I keep (this is after being very heavy with the delete key, getting rid of image that really just don't "cut the mustard"), adjusting exposure, levels, WB, cropping, etc. I downsample perhaps 50-75% to reduce file size, keep in sRGB, and generate a set of Jpegs. These are used for casual viewing on my computer, emailing to friends, etc. This will bring the images to perhaps 90% of their potential.
For a much smaller group of images, that I'll be posting on my website, or more importantly, printing, I'll re-convert the Raw file, with fairly conservative settings in Capture One, and then do a "full court press" in PSCS2 to get that last 10% of image potential. The ones that I'll be printing are upsampled, generally using Genuine Fractals, and are saved as 8-bit TIF's.
I archive all my Raw files, the working Jpegs, and the 8-bit TIF's for that smaller group of better images. If I have a request for an image where I only have the working Jpeg, I'll go back, reconvert, re-edit, etc. This seems to work for me, conserves storage space, etc.
Stan
As an aside, another reason why I always shoot raw+S is that the JPG file has the full EXIF embedded. Even when you process a CR2 file with DPP, the resulting JPG won't have as much EXIF data in it as the "original" JPG would. Since I am in no way interested in using DPP (unless they totally overhaul it), being able to read even somewhat strange EXIF tags without access to OEM software is important to me.
On this topic - after I generate a set of "working" Jpegs, I use Breeze Browser's "EXIF Copy" function, and it will transfer a full set of complete EXIF data from the original Raw file, to these Jpegs. That way I can access the full set of EXIF information without having to go back to the Raw files.
Nill Toulme
June 7th, 2006, 05:48 AM
... I downsample perhaps 50-75% to reduce file size, keep in sRGB, and generate a set of Jpegs. These are used for casual viewing on my computer, emailing to friends, etc....
Oh good grief... your post made me realize that I do save sRGB jpg's after all. I have 45,000 of them on my website! ;-)
... after I generate a set of "working" Jpegs, I use Breeze Browser's "EXIF Copy" function, and it will transfer a full set of complete EXIF data from the original Raw file, to these Jpegs. That way I can access the full set of EXIF information without having to go back to the Raw files.
Does that generate the full set of EXIF that Stan mentions is missing from DPP conversions, but present in the camera-generated jpg's? And I wonder if BB also does that, or can be configured to do that, as part of its html gallery-building function... no, of course it can't, unless it's working from the original RAW file. Hmmm. Well, what exactly is missing from the EXIF after C1 conversion?
Nill
~~
www.toulme.net
Michael Tapes
June 7th, 2006, 06:39 AM
My flow is this...
Shoot 100% Raw
Cull to some degree
Make first pass adjustments...WB (WhiBal!), exposure, etc
Use RSP FastProofHQ to generate 800w JPEGs, sRGB. This only takes 1-2 seconds per image and is of high quality. If in rush and quality is not an issue, I use FastProof (no HQ) and JPEGs are generated at the incredible rate of 2 or 3 per second. This is NOT extracting the embedded JPEG. This is a true Raw conversion using the adjustments I have made. HQ is high quality conversion, non-HQ is low quality conversion. (JPEG quality is a separate parameter to set).
Use those for galleries (draft posting) and emails
Do serious adjustments on web keepers in RSP, convert to 8 bit TIFF sRGB if no additional editing is needed
TIFF8 files are resized for web (bicubic) and sharpened using PhotoKit Sharpener
All except RAW+Adjustments are dumped
Print Keepers are adjusted and converted to TIFF16 aRGB
PS adjustments are made and PSD file is saved as master file for this print keeper
File is now sharpened to print size in PKS and printed, or both are done in Qimage (still experimenting)
File is saved as Print master JPEG in aRGB with print size as part of filename (060603_SHCwChickPRNT10x15.jpg). This becomes my print master if I need to reprint the 10x15 size. If I need to print a different size i will either go back to the PSD master and sharpen for new size, or if small size I might use the JPEG 10x15 depending on use of the print and for whom.
So I never save the TIFFS. I save sRGB JPEG Print Masters for a specific size, and the PSD master for all portfolio images. If no PS work is done on a conversion, I will still save it as a PSD so I know it is the final edited master. All RAWs are kept with Adjustments. With RSP I can also save different adjustments by saving different renditions of the conversion as different snapshots, that are labeled.
OK then.....
Don Cohen
June 7th, 2006, 08:13 AM
Does that generate the full set of EXIF that Stan mentions is missing from DPP conversions, but present in the camera-generated jpg's? And I wonder if BB also does that, or can be configured to do that, as part of its html gallery-building function... no, of course it can't, unless it's working from the original RAW file. Hmmm. Well, what exactly is missing from the EXIF after C1 conversion?
As far as I can see, BB's "EXIF Copy" function places the entire set of EXIF data contained in the original Raw file into a Jpeg of the same name. Capture One conversion mangles the "Maker Note" information, as I recall, while maintaining some of the basic functions. PSCS2 also does a poor job of maintaining the EXIF info. I was actually one who encouraged Chris Breeze, way back in the D30 days, to add this EXIF copy function to BB, and I've used it ever since.
Peter Mendelson
June 7th, 2006, 08:59 AM
Michael, in your last step, how come you don't save the file as Print master TIFF rather than JPEG? Is there no difference in quality? I use Qimage to print TIFFs for my best shots.
Nill, you mentioned loss of info and gain of artifacts in saving as JPEG at least twice, and I have seen this mentioned many times in books, on the web, etc. I really wonder how noticeable it is for large high quality JPEGs with normal adjustments and resaving only once or twice. I have committed this "error" and have adjusted thousands of JPEGs from my 5D and resaved them as JPEGs, and never once saw noticeable artifacts being created as a result. In the illustrations I have seen showing degradation from resaving as JPEGs, it is never mentioned how many times the JPEG has been resaved and what size and quality JPEG is used. Maybe it was resaved 10 times with fairly major editing? Who knows? I would be really interested to see if anyone has done real life comparisons using normal adjustments on their files and resaving only once or twice - I bet the difference is less than people expect (but then again, I could be wrong).
Regards,
Peter
Nill Toulme
June 7th, 2006, 09:03 AM
Peter... exactly why I asked the question. Theory is one thing, practice another. OTOH, if this is just an intermediate step and the first save will not be kept, why not err on the side of caution and use the lossless format? Speed?
Nill
~~
www.toulme.net
Peter Mendelson
June 7th, 2006, 10:16 AM
Nill, yes, I was thinking in terms of processing speed.
Peter
Stan Jirman
June 7th, 2006, 10:34 AM
As far as I can see, BB's "EXIF Copy" function places the entire set of EXIF data contained in the original Raw file into a Jpeg of the same name.
I do this sometimes, too, except I do it on Unix command line with the handy 'jhead' tool. There's one problem with copying an EXIF header verbatim: take an image that's been shot as a vertical, and the camera tagged it as such. Then you process it in say C1, which "positions it right". Then you copy the original EXIF header into that jpg file - including the "needs rotation" flag...
There are a number of apps out that get it right, but say PSCS will turn the image 90 degrees once more, on top of the rotation, and other confusion ensues.
Sean DeMerchant
June 7th, 2006, 02:22 PM
First and foremost, please type out at least Adobe RGB if you mean Adobe RGB 1998 as aRGB is nothing while sRGB is an official designation. I ask this not because it is unclear to me, but because it cripples search facilities and creates confusion for people new to the topics. i.e., a search for "Adobe RGB sRGB" would have failed on this thread until I posted this even though it is on topic. It may also get confused with a 32-bit image with 8-bit color (RGB+Alpha).
That said, my workflow:
Review RAW mages in a tool (RSE, Bridge) and delete those that have issues (poor focus, undesired motion blur, bad composition, ...).
Convert the better images from RAW to a working directory as 16-bit ProPhoto RGB images (note I make all final color tweaks in PS as there is not a single RAW converter that handles saturation well IMO).
Review the images in the working directory and delete some.
Process and save images as 8-bit sRGB image for the web. Delete if a print will not be considered and excessive post processing was not performed.
Save the better images as 16-bit ProPhoto RGB in a print candidates directory.
Review the candidate images, delete the culls.
Review the print candidate images and prepare 8-bit sRGB TIFF files of appropriate size for printing (4x6, 5x7, 8x10, 8x12, ...). Also, at this time the 16-bit full resolution original is moved to a base files directory so that it is available to be repurposed to another printer as need be.On top of all of this, backups are also done at multiple points during the workflow as needed.
All this said, the following is what I have distilled as the prevailing color space wisdom (not necessarily right for all, but in general it is widely agreed upon).
ProPhoto RGB, a.k.a. ROMM RGB, is a huge color space containing colors your monitor cannot create and your eyes cannot see. This is an awful color space for 8-bit work due the huge gaps between colors in 8-bit. It is a spectacular workspace for 16-bit workflows and it is likely to have a larger gamut than any printing device you are likely to have in the near future.
sRGB is a good workspace for web output and it is the lowest common denominator for many commercial printers. It is an adequate workspace but has a limited gamut.
Adobe RGB 1998 is a good but not perfect workspace for many applications. It works well with both 8 and 16-bit workflows. Its gamut does not contain the entire gamut of many printing devices, but it is still far better than sRGB. It is a much better space for a RAW workflow as it can contain more saturated tones which you can selectively desaturate in PS to fit within the sRGB color space for output.Other workspaces exist and have value, but they are less common and I will ignore them.
some thoughts,
Sean
Michael Tapes
June 8th, 2006, 06:04 AM
Michael, in your last step, how come you don't save the file as Print master TIFF rather than JPEG? Is there no difference in quality? I use Qimage to print TIFFs for my best shots.
Peter
Peter,
Essentially, there is no difference in quality. I save the print Master JPEG at quality 10 in PS. As this file will never be re-compressed or edited, there is simply no reason to waste the space on a TIFF. You will not see any difference in the resultant print, as it has been resized and sharpened before it was saved as the JPEG Print Master.
HTH
Sean DeMerchant
June 8th, 2006, 01:33 PM
Peter,
Essentially, there is no difference in quality. I save the print Master JPEG at quality 10 in PS. As this file will never be re-compressed or edited, there is simply no reason to waste the space on a TIFF. You will not see any difference in the resultant print, as it has been resized and sharpened before it was saved as the JPEG Print Master.
HTH
I disagree in general but not in specific for many situations. If your camera is lower resolution than your print target, then you will see a difference by working in JPEG. The difference between an 8x10 inch @ 300 DPI from a JPEG from a 3.3 MP camera versus one from a RAW file and TIFF/PSD based workflow will differ. Most of this will be JPEG induced chroma noise which can be reduced through using higher quality JPEGs. The problem is JPEG compression schemes tend to be proprietary and that leaves some uncertainty of what to use for those not educated in reading the hexidecimal data in a JPEG file.
Albeit, an 8x10 inch print from a 5+ MP camera with a JPEG all the way will likely yield a much better print than anything from a 3.3 MP camera so long as the lenses are comparable in quality.
That said, with modern 8+ MP cameras you are not likely to see a difference in an 8x10 or 8x12 inch print without a loupe. But if you are increasing the resolution (in pixels) of the image to print a 16x20 or 16x24 you may see a difference in smoothness of final tonality as opposed to posterization from doing your interpolation (Image->Size in PS) on a 16-bit color image. The why is that the extra bits yield data that is in essence blurred from the extra hidden bits into visible spatial bits by the interpolation function.
In short, for most workflows and utilizations of images (web, and 4x6, 5x7, 8x10, 8x12 inch prints, and etcetera) you will be unlikely to see any difference. If you are working from a tight crop of a frame, then a lossless workflow may yield better results. I say may, because compression induced noise could have a positive effect on the final image depending on your tastes.
some thoughts,
Sean
Michael Tapes
June 9th, 2006, 07:03 AM
Sean,
Perhaps you did not follow my workflow from top to bottom. My JPEG comments related to saving a print specific file, long after RAW conversion and PS tweaking. I only shoot RAW, and do not advocate JPEG shooting, less for the compression than the fact that one has a developed image as opposed to an undeveloped image that can be optimized during development in the RC.
Sean DeMerchant
June 9th, 2006, 01:25 PM
Michael,
My apologies. I did read your workflow (JPEG for output only) and my comment was more addressed to usage of JPEG as intermediaries as Peter Mendelson addressed in the original post.
all the best,
Sean
Michael Tapes
June 10th, 2006, 06:34 AM
Cool. Thanks for your post..
Wolfgang Borrs
June 20th, 2006, 03:59 PM
I shoot RAWs in Adobe RGB for magazines.
I am editing my Images on a monitor only able to diplay sRGB, my question is now, is this a blind flight, am I working on colors which I canīt see? Wouldnīt it be better to shoot and work in sRGB, as long as I do not have an Adobe RGB Monitor.
Wolfgang
Tom Yi
June 20th, 2006, 04:16 PM
In reply to original poster, I don't think it's sacrilege to go from RAW to sRGB JPEG. Especially if your monitor is only in sRGB or the printer only prints in sRGB.
I shoot almost all in RAW and edit as much as I can in RAW then convert to sRGB JPEG. If I really like the shot, I have the RAW and it's editing parameters as RSP and I think DPP allows. That way you can convert the RAW image to sRGB/aRGB, TIFF 8/16bit, Pro Photo, JPEG or what ever format you want. I think this is the most memory space conscientious way to do store your image.
I guess if you do heavy Photoshop manipulation, then the TIFF may be the way to go, so you don't have to redo the PS stuff on your RAW image.
Also, I may be wrong, but doesn't working in non sRGB color gamut a moot point unless your monitor can handle aRGB/pro photo and printer can print in those gamut as well?
I don't every recall seeing a RAW shot, converted to sRGB aRGB in JPEG and same in TIFF printed out to a large print size and comparing their color and details. I'd like to see this to really see how much visible difference there is among all these formats and color gamuts. Perhaps someone here can tackle this project so we can all see.
Don Lashier
June 20th, 2006, 04:24 PM
When using Adobe RGB working space, having a monitor limited to sRGB doesn't seem to be too much of a hindrance/nuisance. True, you may not be able to view exactly the end result, but proper CM will still give you a reasonable view, and assuming you're using a printer profile, the extra saturated "fringes" will still carry thru to the printer. If you're concerned about gamut clipping, soft-proofing will help you deal with it.
- DL
Bart_van_der_Wolf
June 20th, 2006, 04:55 PM
Especially if your monitor is only in sRGB or the printer only prints in sRGB.
Ah, but are they really only sRGB capable?
When comparing the monitor and printer profiles I created with the EyeOne Pro spectrophotometer (Profile comparison (http://www.iccview.de/index_eng.htm)), I came to the conclusion that my printer provided such a large gamut for some colors that even Adobe RGB was almost selling it short, in particular at the Red/Orange end.
Your printer may also be capable of more subtle color distinctions than you seem to assume. My current display, a LaCie 321 LCD, apparently was quite close to my Trinitron CRT's gamut, but also has a bit wider gamut than sRGB on some colors.
Bart
Tom Yi
June 20th, 2006, 05:08 PM
My point being that you need to know those things before you start dabbling in wider gamuts. I believe default is set to sRGB, so unless you get your monitor and printer to show/print in a wider gamut, what's the point.
I'm assuming the original poster has his set up to sRGB here.
I'd still like to see prints to look at the differences. I'm not saying that the differnce isn't there. I'm just wondering how much of a difference it is.
Don Lashier
June 20th, 2006, 05:16 PM
> I'm just wondering how much of a difference it is.
Not dramatic - you probably won't even notice it unless you're printing pictures of flowers or covettes, but quality is often made up of the sum of small differences and given that with properly setup workflow it's really no harder than working in sRGB, I switched to an Adobe RGB workflow quite a while ago even though I was a (former) skeptic also.
- DL
Sean DeMerchant
June 21st, 2006, 01:50 AM
I shoot RAWs in Adobe RGB for magazines.
I am editing my Images on a monitor only able to diplay sRGB, my question is now, is this a blind flight, am I working on colors which I canīt see? Wouldnīt it be better to shoot and work in sRGB, as long as I do not have an Adobe RGB Monitor.
Wolfgang
No, it is not a blind fight. The real value of a huge color space is that you can transform the image to retain image data in super-saturated tones in the smaller color space. We know that saturation will be lost in the output, but there is no good reason to lose detail too. This demarks the difference between a fine print and sloppy print IMO.
Sean DeMerchant
June 21st, 2006, 01:57 AM
Also, I may be wrong, but doesn't working in non sRGB color gamut a moot point unless your monitor can handle aRGB/pro photo and printer can print in those gamut as well?
Your working space (sRGB, Adobe RGB 1998, ProPhoto RGB, ...) are not directly related to your output color space. Working spaces are designed to make the underlying mathematical operations intuitive (i.e., R,G,B=27,27,27 is a dark gray rather than a dark color with a magenta hue).
What your monitor can display and what your printer can print are another issue. These are device spaces that describe what colors can be output by that device. These are not working spaces and in a device space 57,57,57 could be a dark magenta or a dark violet.
And I have never heard of a monitor that can display only the sRGB color space. I have heard of monitors that have psuedo sRGB calibration, but this is intended to allow the average user who cares little about results (i.e., not very picky) to get decent results from an uncalibrated workflow. This is good enough for a rather low standard of good enough.
Most printers ($100 US inkjets) can print many colors outside the sRGB gamut. Do you really want duller and flatter colors from a printer that can do more just because of your workflow?
some thoughts,
Sean
Andrew Rodney
June 21st, 2006, 07:08 AM
There are three areas where you need to look with respect to color gamut:
1. The gamut of the capture device. In reality, digital cameras and scanners don't have a gamut (they have what is called a color mixing function). None the less there is a gamut to film (which limits what the scanner produces). There's a real world of color gamut we see and it's pretty huge. Anytime you see one of those horseshoe plots of color (CIE chromaticity diagram), you're seeing the gamut of human vision. A digital camera can capture a huge range of color. All you need to do is take a RAW file of a very colorful scene in Adobe Camera RAW and examine it's Histogram for color clipping. I have tons of images that fall far outside Adobe RGB gamut. IF (big if) I want to contain the colors I shot, I need to use a much larger gamut like ProPhoto RGB (in 16-bit).
When you set your camera to sRGB or Adobe RGB (1998) and throw away the RAW file, you have no control over this. However, there's no question that selecting Adobe RGB will provide a larger gamut of captured colors compared to sRGB assuming the scene has a larger gamut than sRGB. That's pretty likely. Is capturing those important to you?
2. The gamut of the output device. You've decided that you do want to contain colors in the scene your capture device has collected. Now there's the gamut of the output device. Anyone that tells you "no output device exceeds sRGB" is smoking some very bad stuff or simply doesn't know what they are talking about. Again, by viewing a gamut plot (in 3D preferably), you can find all kinds of output devices that have colors that it can reproduce outside of sRGB. Are those color important to you? As I mentioned, the new K3 inkset from Epson produces colors that fall outside of Adobe RGB (1998)!
3. There's the gamut of your display. 99.9% of users have a gamut that's no larger than sRGB. There are new displays on the market that exceed Adobe RGB (1998) but at a huge cost (today). So there ARE colors you can capture and output you can't see on your sRGB display. The question becomes, do you throw away those colors you captured AND CAN reproduce away because you can't see them all? I think not but maybe some do.
This is all about flexibility and future output needs. IF you know that the scene gamut/camera can't exceed sRGB AND you know your printer can't produce anything larger than sRGB (get a new printer ), then sure, stick with sRGB. But if you look at just Epson and the evolution of increasing gamuts in ink technology, why paint yourself into a corner???
Those silly labs that tell you "just send is sRGB and all is well" are either lazy, don't understand color management or simply don't want YOU to decide how to handle YOUR files! There are NO printers on the planet that produce sRGB!!! The only sRGB device is a CRT display in a very fixed and defined environment. In fact sRGB is a totally synthetic color space designed using pure math (as are all the other RGB working spaces). These labs just don't want to profile their devices so you can soft proof the image, they don't want to worry about embedded profiles and want their automatic systems to simply assume all files are sRGB. Then they do a conversion to the printer color space on the fly. It makes them very productive. However, you lose a lot of control over how you render an image for an output device.
John_Schwaller
June 23rd, 2006, 03:30 PM
What is wrong, if using ACR->CS2, to start with Raw and do all follow on PP in ProPhoto-16bit....and then convert to jpeg at the very end.....sRGB for web and ProPhoto-8bit for printing (using Qimage)?
My thoughts are it maintains the best space for all the processing steps and the initial jpeg (minimal compression) is more than just fine for printing. I do not believe TIFFs will give any better results.
John
Andrew Rodney
June 23rd, 2006, 03:58 PM
Nothing wrong (it's right!).
Bart_van_der_Wolf
June 23rd, 2006, 06:11 PM
What is wrong, if using ACR->CS2, to start with Raw and do all follow on PP in ProPhoto-16bit....and then convert to jpeg at the very end.....sRGB for web and ProPhoto-8bit for printing (using Qimage)?
Depending on your printer's (ink/paper) Profile, I'd prefer using a slightly smaller gamut colorspace than ProPhoto RGB for 8-bit/channel conversion. Profile conversions in 8-b/ch space may (depending on actual gamut differences, subject, and magnification) cause visible posterization.
You can test for that by assigning the ProPhoto RGB colorspace to this (http://www.brucelindbloom.com/RGB16Million.html) image, and converting it to the printer's profile. Just like in the RGB vs Lab conversions on that web page, you may or may not experience visible artifacting.
I never asked Mike Chaney whether Qimage, which is mainly an 8-b/ch application, uses dithering with profile conversions. If it does then there is a smaller chance of visible posterization.
Bart
John_Schwaller
June 26th, 2006, 08:44 AM
Depending on your printer's (ink/paper) Profile, I'd prefer using a slightly smaller gamut colorspace than ProPhoto RGB for 8-bit/channel conversion. Profile conversions in 8-b/ch space may (depending on actual gamut differences, subject, and magnification) cause visible posterization.
You can test for that by assigning the ProPhoto RGB colorspace to this (http://www.brucelindbloom.com/RGB16Million.html) image, and converting it to the printer's profile. Just like in the RGB vs Lab conversions on that web page, you may or may not experience visible artifacting.
I never asked Mike Chaney whether Qimage, which is mainly an 8-b/ch application, uses dithering with profile conversions. If it does then there is a smaller chance of visible posterization.
Bart
OK...I understand your concerns. I am not sure what Mike is doing either. I have read some posts of his (from about a year ago) where he is not high on the use of ProPhotoRGB, prefering aRGB or ddiRGB (which is not available in ACR). With ProphotoRGB to "printer profile" he mentions the possibility of banding with relative intent, but not perceptual. I am not sure if he was specific to the bit size in making that statement.
Assuming your concerns are valid, what would be your recommendation? Do all printing in TIFF? If so, what color space? If using jpeg for printing, would you recommend starting with aRGB direct from ACR or use ppRGB and at end convert to aRGB or ddiRGB (possible in PP??) before changing to 8-bit and jpeg?
Thanks for your advice....JOHN