digitaldog

<blockquote> <p>I did run idiagnostics and the device passed so the hardware seems to be okay.</p> </blockquote> <p>That's good news. I'd try tweaking the calibration options to get closer to a match. The issue is that depending on the software, you're given crippled 'tools' if I can be so kind, for setting the critical aimpoints; white point and backlight intensity. You don't need to force a low backlight onto the process as long as you can control print viewing conditions. </p> <blockquote> <p>I have paper profiles which I soft proof with. I don't have output profiles for conversion or is that the same thing?<br /></p> </blockquote> <p>It <strong>is</strong> the same thing unless a color management cluless lab provides the profiles only for soft proofing and not for producing the output values (they don't allow you to convert the data). If they force you to send them sRGB, the alarms should go off. </p>

<blockquote> <p>My question was "Which widely used photo editing programs cannot read PSD files?</p> </blockquote> <p>I guess we'd have to agree upon what is meant by <em>widely used</em> and <em>photo editing</em>. I can tell you I have a number of applications on this Mac that <strong>can</strong> open a layered TIFF (as flattened) and <strong>cannot</strong> open a PSD (layered or otherwise). That includes ColorThink Pro, PatchTool,Snapheal Pro, GamutWorks and i1Profiler. You can suggest they are not widely used. Or you can suggest they are not photo editors (one proposes to be as it's key role). But I'll argue that there's no advantage of PSD over TIFF and that <strong>there are far more</strong> applications that can open a TIFF then PSD so why would you save as PSD? If long term archival flexibility of raster data is on your radar, as other's have said, PSD is the wrong answer, TIFF is. </p>

<blockquote> <p>A related question: When saving as TIFF, Photoshop CC has various "TIFF Options," including "Byte Order," where one can choose IBM PC or Macintosh. What's the significance of the choice?</p> </blockquote> <p>Byte Order: Mac or PC? Well that’s a debate that will continue on, but in this case, pick PC since the Mac will have no issues with this Byte order but the ancient PC software may. <br> Pixel Order: Interleaved is supposed to be a more common way of saving a TIFF and the default, traditional method used by Photoshop from day one. The Per Channel option is supposed to be a little faster at reading and writing the data. The dialog does give some idea of what the differences are; the pixel order is the way color information is written in the document, so with interleaved, each pixel is written in the RGB sequence (RGB, RGB, etc) while Per Channel is written in that order (RR, GG, BB etc). <br> Save Image Pyramid: This is an option few need to worry about as few modern applications utilize this method of storing multiple resolution levels within a single document. If you’re old enough to recall Kodak PhotoCD, FlashPix or Live Picture’s IVUE format, you have experienced formats that used multiple resolution levels within a single document. TIFF also supports this mode and hence, its an option in the Save dialog. You probably have no reason use it however. </p> <p>Layer Compression: How should the layer data be compressed? Note that with layers, it’s the pixels themselves, not the transparency that accounts for the increase in document size. So if you have a 2nd layer that is all pixel data, it will take up far more space than a layer that has only a small part of image data, surrounded by transparency (the checker board). An Adjustment layer is tiny, its essentially metadata describing a correction. RLE (Run Length Encoding) uses a lossless compression much like LZW on your layers. Or you can use Zip for an even smaller document but at the expense of speed in saving and opening the document. Both greatly aid in keeping the resulting TIFF with backwards compatibility to a manageable size. Your call here, faster speed or smaller documents? </p>

<blockquote> <p>So, in short; a higher bit workflow will produce better results regardless of the bit depth of the printing process.</p> </blockquote> <p>No. As I said, the idea is to send the best 8-bits pre color image to the output device. Very few output devices can accept more anyway.</p> <blockquote> <p>Also using a higher bit display will indicate flaws in the data where using the lower bit display system will indicate a similar flaw which may be in the data or indicating the shortcomings of the 8 bit display system.<br /></p> </blockquote> <p>Less than the minimum of 8-bits of data per color, banding can result. Is it banding in the image data or banding due to how the image data is displayed? There are two paths. Ideally both are high bit. </p> <blockquote> <p>Am I better off starting to work in a 10 bit display, or continue along the 8 bit pathway and working with an Imac?<br /></p> </blockquote> <p>There is no full high bit display path on the Mac OS so in terms of the display, best you can do is get a display with high bit support internally. That has nothing to do with the image data you edit and output. Again, two paths. </p> <blockquote> <p>I like to know what I am working with the full depth of the 14 bit images I capture.<br /></p> </blockquote> <p>That you can do. Just keep the data in high bit (what Adobe calls <em>16-bit</em>). </p>

<blockquote> <p>That is very interesting, Andrew, but you have not answered my question.</p> </blockquote> <p>I think I did. What isn't clear? </p>

<blockquote> <p>Many of today's better quality LCD monitors can, and need to, be calibrated at a much lower luminance level than 120.</p> </blockquote> <p>A very few can <strong>natively</strong>, very few below 100cd/m2. There's <strong>no</strong> reason why one has to work with low backlight intensity when one can and should control print viewing conditions. The ONLY advantage to lower backlight is that backlight will last longer and use less electricity but with modern LED backlight, that's not an issue at all. The old farts from CRT days (myself included) do not have to work with low backlight intensity as we did years ago and for many LCDs, you'll never get a native backlight intensity (which you do want) anywhere near a CRT nor is it necessary. New, out of the box, a CRT might be able to output 100cd/m2 but not for very long. IF prints are appearing too dark (they are not really too dark), lower the backlight as much as you can <strong>natively</strong> for a match but don't ignore the print viewing conditions which by design should have the ability to increase output to match a print too. </p>

<blockquote> <p>However, the prints are too dark and there is a colour discrepancy between the monitor and the prints.</p> </blockquote> <p>Did you follow the outline for a match at:<br> http://www.luminous-landscape.com/tutorials/why_are_my_prints_too_dark.shtml</p> <blockquote> <p>The lab I am now using is supposedly colour managed.</p> </blockquote> <p>The key word here is <em>supposedly</em>! Do they provide the output profile of the printer for you to <strong>both</strong> soft proof and use for conversion? If not, they are not color managed! </p>

<blockquote> <p>Which widely used photo editing programs cannot read PSD files?</p> </blockquote> <p>Any less than TIFF, and that is the case, doesn't bode as well for PSD. To use PSD, these programs have to pay a license to Adobe. That's not the case with TIFF. What for pay, proprietary format has provided longer term archival support than an open and free one? </p> <blockquote> <p>Some programs may not be able to use some of the mask or layer data stored in the PSD, but they probably could not use the same data stored in a TIFF either.</p> </blockquote> <p>Inside Photoshop and the Adobe universes this is all proprietary. Outside, TIFF or PSD play the same way: they treat the data as a flattened version. The big difference is <strong>if</strong> the application you are using understands TIFF but not PSD, the PSD is simply unrecognizable. The TIFF is opened flattened. Or the PSD could be opened, again flattened if the application has licensed the usage of PSD. </p>

<p>You want high bit workflow from capture to output if you can. The idea is to send the very best 8-bit per color data to the output device (printer).<br> What the display does has no direct effect on that data unless you edit based on faulty visual feedback so that part of the process is important. It is why we try to use the best quality display gamut and technology and calibration. But the high bit display data and the high bit image data one edits and output's are on different paths. <br> If you are working with a high bit display path (and arguably that can be partially high bit), if you see banding on-screen, it's in the data, not the display path. </p>

<blockquote> <p>Will using a 30 bit display better represent the images which will be reproduced by printing,?</p> </blockquote> <p>Not really, no. More bits are better to reduce banding that may show up somewhere in the imaging or processing chain. In this case to the display. </p> <blockquote> <p>Commercial labs such as Bay Photo and Pro DPI only accept 8 bit JPG files to print from</p> </blockquote> <p>That's a completely different set of data for different use (output to a printer). See: http://www.digitalphotopro.com/gear/imaging-tech/the-bit-depth-decision.html</p>

<blockquote> <p>I don't understand all this advice to save the work-in-progress in anything other that the app's native format.</p> </blockquote> <p>What native format? Don't know about you, but in Photoshop (CC), if I make a new document, add a layer and such then select "<em>Save</em>" I'm promoted to save a TIFF, <strong>not</strong> a PSD. Why? Because that's how I saved the last new doc and thankfully PS is sticky in terms of the format selection. In my case, TIFF <strong>is</strong> the native format for data with layers and the like. Again, aside from Duotone support, PSD isn't necessary, useful or a well planned file format for archival purposes compared to TIFF.</p> <blockquote> <p>It's very unlikely, pretty much impossible, that PS can save data in TIFF that it can't store in PSD.</p> </blockquote> <p>So considering that TIFF is far more supported outside the Adobe universe, why would anyone select PSD? And if you ask the right Adobe engineers as I have, you'll likely hear from them their desire to ignore PSD as anything like the so called "native format". They'd like it to go away (but it will not). PSB, that's a totally different story.</p>

<blockquote> <p>How does a TIFF file handle things like Photoshop 'Smart Objects' or other items that might be unique within Photoshop's capabilities?</p> </blockquote> <p>Think of it as totally flattening the layer stack in a PSD or TIFF. All that layer and Smart Object editing is proprietary in Photoshop alone. Once you leave that proprietary app, PSD, JPEG, DNG, TIFF, you've got a baked and flat image. If it's color and tone appearance is good, that says a lot, it's not chopped liver <g>. But the editing flexibility and unique features of Photoshop are gone. </p>

<blockquote> <p>That should mean I can tell my company's designers to dump PSD?</p> </blockquote> <p>You could. </p> <blockquote> <p>That's a different matter, however, from having other program's correctly interpret what Ps puts in the TIFF<br /></p> </blockquote> <p>If those programs are correctly written to accept the standard TIFF, it will interpert it correctly. That doesn't mean these programs can access the data the same way (for example, the ability to edit the proprietary PS layers). You'll see the image like Photoshop, it will likely be treated as a '<em>flattened</em>' TIFF. IF the application also supported PSD, that would be the same in terms of limitation and if the application didn't support PSD, you couldn’t even open the document. </p> <blockquote> <p>Yes, the spec for TIFF is open, but is it high level enough?<br /></p> </blockquote> <p>It is, to the degree any other file format could be. IOW, if you had a TIFF and a PSD, the limitations would be the same and again, the only difference would be the support, or lack of, Duotone functionality. Otherwise the two behave the same to outside app's that support the file format(s). </p>

<blockquote> <p>1) Since the OP is working in Photoshop, for a <strong>working</strong> file she does not have to worry about interoperability nor long term (years) support, so why not PSD.</p> </blockquote> Because down the road, she <em>may</em> have to convert <strong>every</strong> PSD to TIFF. San's Duotone support, there is nothing else the PSD provinces the TIFF doesn't in Photoshop, in terms of operability. And TIFF with compression while opening and saving is slower, takes up less space than PSD not that drive space is anything to worry about these days.

<blockquote> <p>To answer your original question, for a working file in Photoshop, I would use PSD.</p> </blockquote> <p>Why?</p>

<p>LR has issues on Windows losing the display profile or something can happen to that display profile and LR barfs. Recalibrating the display is the fix.<br> Or some have reported issues where the same profile is saved in two locations on the machine. </p>

<p>As Jeff and Ellis says, use TIFF. It's an open, non proprietary format that far more software products can support (it cost nothing for them to use the format in their products it unlike PSD). There's nothing other than Duotone support PSD provides that TIFF doesn't. There's really no need to be using PSD these days. </p> <p>BTW, a so called "<em>raw</em> TIFF" is just like any other TIFF and nothing like a camera raw original which isn't rendered. The so called '<em>raw</em>' part is simply a TIFF that needs further editing to appear as so desired. </p>

<blockquote> <p>Now, I've never tried processing a newer RAW file in an older RAW converter</p> </blockquote> <p>Basically the newer converter doesn't recognize the file. You end up with nothing.</p> <blockquote> <p>I don't know about any other manufacturers, but Canon's own software gets updated each time they release a new body, too; it's not just third-party converters.</p> </blockquote> <p>It is easy for them, they know the few differences to code. Everyone else has to hack the released file to do so. It isn't difficult but it takes time and cost money, new installers have to be updated to web sites, release notes have to be written, beta testing has to be done etc. That all takes time. Eventually it happens so why do it in the first place? </p>