Jesse Evans wrote:
Do you have a source for this? I’m interested.
This is shit we learned literally twenty years ago when we were making our first custom profiles of the early Epsons at the time. Source? It's been so long I don't remember the source, only the fact that it's true. It's how all standard print drivers work. Do a little dive yourself into how this shit works and you'll soon find your own source. I remember the the very first inkjet I ever printed on back then and thinking I was smarter than it and I'd send it CMYK because that's what the inks were. Ha. What an idiot I was. The results proved it. Soon after, when I got the Spectrolino I still use today I learned about print drivers.
Peter Figen wrote:
This is shit we learned literally twenty years ago when we were making our first custom profiles of the early Epsons at the time. Source? It's been so long I don't remember the source, only the fact that it's true. It's how all standard print drivers work. Do a little dive yourself into how this shit works and you'll soon find your own source. I remember the the very first inkjet I ever printed on back then and thinking I was smarter than it and I'd send it CMYK because that's what the inks were. Ha. What an idiot I was. The results proved it. Soon after, when I got the Spectrolino I still use today I learned about print drivers.
Okay, so no source. Some of your claims are pretty hard / impossible to prove without a reference. Most significantly: that CMYK is transformed to RGB internally in the printer, then output back to CMYK.
Although printers work with CMYK and your images are in RGB, you should not perform a CMYK conversion prior to printing your images unless you are producing a hard proof to send to a client for colour matching. The printer drivers will do the appropriate conversion from RGB to CMYK to ensure the best results from your digital files.
This confirms a couple points (with respect to Canon’s printers, at least): the printers use CMYK as their print model internally, and that one should not convert their images to CMYK prior to printing.
It also implies that CMYK images sent to the printer will not be converted back to RGB and then reconverted to CMYK internally. Though we can’t be certain this is the case due to the lack of a clear, unambiguous statement saying so.
the manual is saying that the RGB data sent to the printer is converted to CMYK by the printer driver. then the printer driver sends the CMYK data set to the printer for printing.
1st off, we must remember that the printer is a CMYK devices that accepts RGB input data, not a RGB device. the ink itself is CMYK pigmented ink. the heavy lifting (RGB to CMYK conversion) is performed by the printer driver. in other words the conversion process is 'under the hood' and transparent to the operator.
there is a point that Peter and i don't agree on. i on the 1 hand, let the Canon's printer driver control the CM (Color Management). he allows photoshop to manage the CM. he has stated that PS effectively has only 1 usable colour rendering mode, Relative Colormetric that is sent to the printer driver.
for Canon users this is not true when working in Canon's 16 bit RAW workflow or Canon's printer plug-in module. in Canon's workflow, we actual have the ability to choose from the 2 rendering intents, Perceptual or Relative Colormetric. we can actually see the ∆s in print and in soft proofing. we can also see the colour gamut ∆s in ColorThink Pro. this in turn is critical when colour matching a print with out of gamut colours with a high degree of accuracy. the 2 rendering intents map the out of gamut colours to the printer driver differently with different results in print.
the printer being a CMYK device, there is no logical explanation or reason for the driver to convert the to the data back to RGB. nor can it, once that data is passed by the printer driver to the printer for print. if instructed the driver will save the printing parameters to the printers internal hard drive for re-printing. however, i don't know what format the data is saved in RGB or CMYK?
moondigger agreed.
ooppss Jesse Evans, give Peter a break on this one. he is just having a senior moment.....lol
besides the old boy has probably forgot more than most know on fm.
"It also implies that CMYK images sent to the printer will not be converted back to RGB and then reconverted to CMYK internally. Though we can’t be certain this is the case due to the lack of a clear, unambiguous statement saying so. "
No it doesn't imply that at all. Unless you've got a PostScript CMYK RIP print driver that can actually accept real CMYK data, the CMYK data IS converted back to RGB and then again internally to whatever the driver needs to do for that printer. The standard print drivers simply can't accept CMYK. They have to convert it but they don't tell you that. If you're printing from Photoshop and you're trying to proof a CMYK image, you actually can send the CMYK document and be safe with it as it will be converted back to your Working RGB space and then to the paper profile you chose and then internally to the required CMYK and finally on to the printer. And there's the big clue for all you naysayers out there - you're choosing a freaking RGB printer profile, not a CMYK profile. Now why the hell do you think that is? It's because the driver is RGB. And you still consider the printer to be and treat it as if it's an RGB device no matter what colors you see in the ink cartridges. Y'all have to get your heads beyond what you think you're seeing and what you think you know about printing. Or just bury your heads if that's more comfortable.
the OEM drivers are not RGB. they are a piece of software that are in a sense proprietary data converters. they take RGB input data and automatically under the hood convert it to the printer's native language CMYK.
a better way to say this. the printer driver is integrating (interfacing) RGB to CMYK. then passing the CMYK data to the printer. the printer can not in and of itself read RGB. it can only read CMYK.
the printer has to have an interface to the outside world that interface is the printer driver. whether it is the OEM's printer driver or the RIP's printer driver. the printer has to have an interface.
Peter Figen wrote:
No it doesn't imply that at all.
It is implied, because they're stating that there's a legitimate reason for doing so: "...unless you are producing a hard proof to send to a client for colour matching..." That statement implies that converting to CMYK before printing has a legitimate use case. If the printer driver is incapable of accepting CMYK in the first place, why would they list any reason for doing so?
Before you respond, please understand that I'm not saying it actually works that way, or that their statement is proof of such. I only said it's implied. That implication may well have been unintended, or may be the result of bad translation between languages, or the result of a technical writer not fully grasping the way the technology works.
In a technical discussion I found on Adobe's site, one of their engineers explains why one shouldn't convert to CMYK in Photoshop prior to printing on modern inkjet printers. His explanation boils down this: Modern photo printers don't just use cyan, magenta, yellow and black inks. As we discussed previously on this thread, many modern printers also have light cyan and light magenta. Some have red, blue, orange and/or green inks, plus dedicated 'light black' (grey) inks. These additional colors greatly expand the gamut that the printer is capable of producing.
According to him, if you convert to CMYK, you are essentially instructing the printer not to use any of the 'extra' ink colors that the printer may have. The only way these extra colors can be used is because the print driver receives the RGB input, calculates which combination of available inks will come closest to producing output that will resemble the RGB input, and then print using those inks.
Note that this explanation also sort of implies that the print driver is capable of passing CMYK input straight through to the printer, but again that question is not addressed directly.
Okay, I did some more research, trying to find references that will confirm one way or another whether printer drivers will pass CMYK data unmodified to printers or not.
What I found is this. According to various references, most on Adobe's technical discussion forums:
1. Photoshop will pass CMYK directly to the print drivers if the document is in CMYK format, unless you have misconfigured your color matching settings.
2. Windows printer drivers DO NOT pass CMYK unmodified to a printer, UNLESS they are PostScript drivers using 1990s-era PostScript color management, or custom RIPs. This matches what Peter said in an earlier post.
3. Macintosh CUPS printer drivers WILL pass CMYK directly to printers. Some photo printer models have CUPS drivers available. Some don't. Canon's Pro-1000 printer driver download page lists a "full package" option, and a "CUPS" option. It is unclear to me whether the "full package" option includes the same CUPS driver as the other option.
Canon's SW allows one to directly print from the image RAW data set. the is no need to convert the RAW file to a JPEG or TIFF format to print them. RAW files are inherently 16 bits.
when working in Canon's DPP RAW converter/editing SW you are working in a 16 bit RAW environment. DPP has (when installed) printer driver plug-ins Print Studio Pro and or Professional Print & Layout plug-ins. the plug-ins are also designed to process and print 16 bit RAW files without the need to convert to JPEG or TIFF files.
having said all of that, "Canon 16 bit RAW workflow" is a phrase i coined to describe Canon's SW ability to convert, edit, and print 16 bit RAW files from input to output.
1. in camera shoot 14 bit RAW ~ EOS
2. convert/edit 16 bit RAW ~ DPP
3. print 16 BIT RAW ~ PSP/PPL
i think Canon is the only manufacturer that has this capability. working in the "Canon 16 bit RAW workflow" one has access to all of the hooks built into Canon's RAW converter and printer drivers that have not been made public to 3rd party SW vendors including Adobe.
eg. you can emulate but not duplicate the colour rendering of Digital Photo Professional RAW converter. you just can beat it. although the UI and advance editing features are a PITA. you can't beat it.
InnomnateViem wrote:
Canon's SW allows one to directly print from the image RAW data set. the is no need to convert the RAW file to a JPEG or TIFF format to print them. RAW file are inherently 16 bits.
when working in Canon's DPP RAW converter/editing SW you are working in a 16 bit RAW environment. DPP has (when installed) printer plug-ins Print Studio Pro and or Professional Print & Layout plug-ins. the plug-ins are also designed to process and print 16 bit RAW files without the need to convert to JPEG or TIFF files.
having said all of that, "Canon 16 bit RAW workflow" is a phrase i coined to describe Canon's SW ability to convert, edit, and print 16 bit RAW files.
That sounds very strange. You can't edit raw data. You edit the settings that are applied when the raw file is converted. These settings might be saved in the raw file along with the original unmodified raw data. You can't print raw files either. There is guaranteed conversion going on before the file is sent to the printer driver. You may not have to save the file, but there is guaranteed conversion going on before printing, to an internal intermediate TIFF file.
true, from a certain perspective. however, Canon does it. the editing info along with the print parameters are passed in their entirety to the printer driver. then it is put on paper with outstanding results.
back to the workflow. 16 bit RAW conversion editing printing. it works and it works quite efficiently.
here's were we can get in problems. the end user need not know what is happening under the hood. we know that you don't actually apply edits to a RAW file and the edit data is stored in a side car or embedded in the RAW file. but what does that matter to the end user?
answer: it doesn't matter from the end user's perspective. how would you test that hypothesis? and what would be the expected results?
what does matter to the end user: he/she can edit the RAW file and print the RAW file transparently.
to test the hypothesis: open RAW file edit RAW file print RAW file save RAW file. keep print for later comparison.
open edited RAW file remove previous edits to restore file to ASOOC state print restored RAW file save restored RAW file. compare restored print to edited print.
done with out ever having to go under the hood to examine the SW or internally recorded data files. VV would be a totally different test methodology as well as a SW verification.
we make things complicated for what ever reasons. in the real world keep it simple. in the lab that's different.
You don't need 16 bits raw data from the camera to get the best results. The 2 to 4 to 6 least significant bits either represents differences that are too small to see or are drowned in noise.
Comapring bit depth in the workflow or intermediate file out of the raw converter (like 8 or 16 bits workflow) is not the same as comparing bit depth in the raw data. In conversion, different gain is applied to the different channels, menaing that even with 10 bits raw data, you can get information in the least significant bit in the 16 bits workflow. I guess this has been covered already by moondigger, but anyway. The concerns about bit depth in the R5 raw files is an unnecessary concern.
InnomnateViem wrote:
true, from a certain perspective. however, Canon does it. the editing info along with the print parameters are passed in their entirety to the printer driver. then it is put on paper with outstanding results.
back to the workflow. 16 bit RAW conversion editing printing. it works and it works quite efficiently.
here's were we can get in problems. the end user need not know what is happening under the hood. we know that you don't actually apply edits to a RAW file and the edit data is stored in a side car or embedded in the RAW file. but what does that matter to the end user?
answer: it doesn't matter from the end user's perspective. how would you test that hypothesis? and what would be the expected results?
what does matter to the end user: he/she can edit the RAW file and print the RAW file transparently.
to test the hypothesis: open RAW file edit RAW file print RAW file save RAW file. keep print for later comparison.
open edited RAW file remove previous edits to restore file to ASOOC state print restored RAW file save restored RAW file. compare restored print to edited print.
done with out ever having to go under the hood to examine the SW or internally recorded data files. VV would be a totally different test methodology as well as a SW verification.
we make things complicated for what ever reasons. in the real world keep it simple. in the lab that's different. ...Show more →
There is only on thing in question, and that is the RBG color space.
Is the raw file converted to RGB before it is printed or not?
"The color space set will be applied as the color space when a RAW image is converted and saved or printed"
The answer is quite clear. When printing in DPP, the raw file is always converted to the working color space (that is only a chioce between different RGB spaces, not CMYK or the printer's native ink color space) before printed.
There is no such thing as printing a raw file directly to CMYK. There exists no demosaicing alorithm that works directly from raw to CMYK.
