|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
The Mac heads are hatching a plot to get all us windows users to just throw away our computers!! <GG> But what an interesting (and important) question C D Tobie poses. Could it be true? Hope someone on windows with the wherewithall runs this test and lets us in on the result. We may need to rise up in arms.... I've read many times how horrible sRGB is, but I'm not sure the difference between it and say AdobeRGB98 would be all that noticeable on most images to the casual observer. But then maybe I've been looking at sRGB all along and didn't know it!! My old Epson 600 prints through sRGB have considerably better color accuracy and saturation (not to mention resolution) than commercially printed offset from the same chromes, for example, but I haven't made that comparison on the current system where I *think* I'm using AdobeRGB98. Wouldn't be definative, but might be interesting. Dave >In a message dated 12/30/99 9:54:24 PM, iay@3L.co.uk writes: > >>Now, back to C D Tobie for a final worrying note: >> >> >> >>>Things won't necessaily be getting much better in the >> >>>upcoming paint-the-world-sRGB scheme that MicroSoft and >> >>>HP are instituting. Then everything will be assumed to be >> >>>sRGB instead of your monitor space. >> >> >> >>Worrying? Well, if my Win98SE combination is NOT assuming the monitor >>space >> >>as a default for RGB data destined for the printer, maybe that upsetting >> >>sRGB world is here already for me. This would be a Bad Thing. It would >> >>certainly account for certain problems I've been seeing elsewhere, as it >> >>would mean that --- unless one figures out a way to use the "Printer Color >> >>Management" facility reliably --- there would be no way to print anything >> >>outside the pitiful sRGB gamut even on a printer which was capable. >> >> >First let me complement you on an excellent piece of technical >experimentation. This kind of thing is what I do much of the time, but not on >Win98, so I will take a bit of consolation in the fact that two esteemed >members of the Photoshop team similarly let theory come between them and how >Epson/Adobe/MicroSoft actually functioned in certain situations (long time >list members may well remember how I handed that ticking package on to them >and ducked <G>). Recently on the Mac platform, I have had more than one >software developer insisting that the monitorspace was being used as the >source for untagged transforms. Since this is a situation that typically >occurs in low quality workflows I haven't taken the time to chase it down. > >On to Windows: Yes, I have recently speculated on that same issue. If >MicroSoft and HP want to ensure the success of their untagged, asssume >everything is sRGB method of color management for the masses, then all it >will take is a single keyhole of sRGB somewhere in the process to assure that >other methods do not show superior results. I theorized that the best place >to hide such a keyhole would be in the Windows core color management >transforms (very much the type of black box referred to in the previous >post). This would bring all other processes down to their level (or gamut). >So the next experiment for some intrepid Windows user to perform (Ian comes >immediately to mind <G>) would be to see if they can process a wide gamut >image all the way to print with a wider gamut space (ideally with the same >gamma as sRGB, such as AdobeRGB) and print to a wide gamut printer (Epson on >glossy stock would do). Then print again with a conversion through sRGB >inserted, to see if it reduces the gamut edge colors. Do this both using ICM >and entirely from Photoshop (in a method that would work even with Win95 or >NT) so that ICM doesn't make the transforms. This might require comparing to >a non-Windows driver, probably a PostScript CMYK RIP... So this would not >be a simple set of experiments but it would be part of learning how to use >managed color on the OS in question, and would generate some info on whether >Windows uses sRGB as a conversion space. Checking with untagged files would >see if it is the assumed source. I would bet it is, and that an sRGB space >file with the tag stripped (or not attached in the first place) would print >identically to an sRGB tagged file, but an AdobeRGB file with the tag >stripped would look under-saturated, because it was assumed to be sRGB. >Testing tagged files would be even more informative, as it would tell us if >Windows will somehow sRGB limit files even when they *are* appropriately >tagged, an issue with far greater ramifications. Since sRGB has a very >limited capacity to hold cyans (clipping them at something under 80%) it >shouldn't be too difficult to generate a test file with a cyan gradiant in it >that would check for this kind of gamut limiting. > >C. David Tobie >Design Cooperative >CDTobie@designcoop.com - Turn off HTML mail features. Keep quoted material short. Use accurate subject lines. http://www.leben.com/lists for list instructions.
[Photo] [Yosemite News] [Yosemite Photos] [Scanner] [Gimp] [Gimp] Users