digitaldog

<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>

<p>How does the camera manufacturer gain monetarily from producing a (temporary) unreadable file in any application but their own free software? </p>

<blockquote> <p>Just out of curiosity, while reading a post on another forum about RAW converters, I got to wondering exactly what the differences were between the various RAW formats--even within brands.</p> </blockquote> <p>Not much, at least in terms of the raw data itself. Most raw files are very similar, based on a TIFF-EP. There is proprietary metadata that only the camera manufacture understands and can 'use' in their own raw converters. </p> <blockquote> <p>What is it exactly that Adobe (or anyone else for that matter) does that requires them to constantly update their software every time a new camera is introduced?</p> </blockquote> <p>This is political, not technical in nature. Among the same company, the raw files from differing camera systems is even less, it's a disservice to customers for each new version to be different from the last since <strong>all</strong> 3rd party converter vendors have to '<em>hack</em>' the newer format to support them. So eventually, a new camera raw file from say Nikon which isn't much different from the last <strong>does</strong> get decoded so what's the point of making them all different? Not the case with the JPEG. <br> <br> This has nothing to do with Adobe or the cloud. If that were true, Adobe would not offer a free DNG converter, they would force everyone to upgrade when they get a new camera. The bad-guy here is Canon, Nikon and the other's who produce a new, proprietary raw file only to have that cease once Adobe and everyone else spends time and money to decode the data. It's simply pointless. </p> <blockquote> <p> Is there that much difference say between a Nikon D7000 and D7100 or Nikon D600 and D610 that causes the process to stop until the software update is put in place?<br /></p> </blockquote> <p>No. IF the manufacturers desired it, the D7000 and D7100 raw files could be virtually identical in terms of a 3rd party raw converter understanding any difference that keep it from rendering that raw data. And yes, it's a very ood way to do things. As long as the masses of photographers stay silent and keep from complaining to the companies who create our camera systems, this simply will not change. </p>

<p>LED's use far less electricity, last longer, produce less heat than CCFL (Fluorescent backlight). The newer generation of GBr LED backlight displays like those from NEC contains green and blue LED units, that are covered with red phosphor, it provides more control over white point calibration too. </p>

<blockquote> <p>like in a few of the above threads - people mention the 8 vs 14 bit difference, more or less suggesting that JPGs offer about half the quality of the RAW image.</p> </blockquote> <p>It doesn't work that way but yes, more bits can mean more data to edit such that at some point, you reduce or eliminate banding in the image due to insufficient bits. That's true of high bit non raw files too. This might be a good start in terms of what high bit data, raw or otherwise bring to the party:<br> http://www.digitalphotopro.com/gear/imaging-tech/the-bit-depth-decision.html</p> <blockquote> <p>One of the replies in the thread I'm looking for mentioned something about the distribution of the information in the JPG, it should be more intelligent that RAW in that respect. That's the info I'm looking for, mainly out of curiosity.</p> </blockquote> <p>That doesn't make much sense however. The JPEG is processed by the camera and how the camera maker thinks you'd like the image to appear. Just like we saw with transparency film. Some loved Velvia, some loved Ektachrome film. They rendered the scene differently. Is that more intelligent than raw data which expects the photographer to do the rendering? The URL above I posted addresses that topic. <br> Raw is raw, unrendered and it doesn't look as you wish it to appear, just like a color negative. Is a transparency more intelligent than a color neg? It depends on how you look at it and what your final goal is. Then there's the difference in the amount of data and gamut potential. </p> <blockquote> <p>In the old threat someone was enthousiastically defending the JPG format, seemingly well motivated.</p> </blockquote> <p>The first question is, do you want the camera to render the scene or do you want to render the scene? That URL covers that topic. Once you make the decision, you'll pick one or the other (or both I guess). If you prefer to have the camera render the scene, then it's quite easy to defend the JPEG. I have no problem with that but like you, I'm always going to capture raw data. </p>

<blockquote> <p>The thread I'm looking for is not mentioned so I guess I'll have to keep looking out and reading :-)</p> </blockquote> <p>What specific information are you looking for? What is the question? </p>

<blockquote> <p>JPGs are 8 bit but their bits are distributed smarter than the 12/14 bits of a RAW image where the bits are distributed linearly</p> </blockquote> <p>JPEG is gamma corrected (for example, a gamma or TRC of 2.2) and <strong>only</strong> 8-bits per color. Raw data is at least 10-bits per color and linearly encoded (1.0 gamma). There's nothing smarter about the JPEG, it's just different data. Baked, less bit depth and smaller potential color gamut. </p>

<p>Digital camera raw files are pixels, just not fully baked to represent RGB data we expect to see. Here's an example:<br /> http://www.digitaldog.net/files/raw.jpg<br /> <img src="http://www.digitaldog.net/files/raw.jpg" alt="" /><br /> Each sesnor site has either a red, green or blue filter and full color is interpolated by using data from adjacent sites. A scanner on the other hand creates a full color image, it has three sensors for each primary color. In terms of '<em>raw</em>', it is possible the scanner didn't introduce any '<em>corrections</em>' <strong>and</strong> it could be linear in data format, although that alone doesn't make it look dark and ugly (most linear captured data has no ICC profile to describe that data capture and so as assumed to be gamma corrected, it appears dark and rather ugly).</p> <p>IF you have good scanning software, there's little reason not to use it and skip the 'raw' data mode. If you prefer to render the image in say Photoshop or Lightroom, because the scanning software isnt' as effective, then asking for 'raw' scans makes sense. But it takes more time so generally it's best to get good scanning software what produces global tone and color appearance you desire.</p> <p>Bottom line, a raw scan and a raw camera file are not the same. Not at all sure what RAW has to do with either . Isn't that all about wrestling? ;-)</p>

<blockquote> <p>JPGs are 8 bit but their bits are distributed smarter than the 12/14 bits of a RAW image where the bits are distributed linearly.</p> </blockquote> <p>JPEG's are 8-bit per color, gamma corrected (not linear) and have been '<em>baked</em>' by the camera to produce a color appearance. Raw data is high bit (more than 8-bits per color, 10-12 and maybe in rare cases real 16-bits per color), it's linear encoded (gamma 1.0) and not processed to appear anything like an image you'd use. Unbaked (see: http://www.digitaldog.net/files/raw.jpg).<br> Not sure exactly what article you're referring to but this one covers the concepts quite well:<br> http://www.lumita.com/site_media/work/whitepapers/files/pscs3_rendering_image.pdf</p>

<blockquote> <p>Is it for real, the suggestion to drop yet more money on a book on how to use a program that should need no book in order to be used?</p> </blockquote> <p>No, throw the baby out with the bathwater. </p>

<p>Alex, before you shell out more money, this may help:<br> http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml<br> SilverFast is a seriously <strong>powerful</strong> app. With that power comes complexity you may want to master. </p>

<p>To understand resolution: http://www.digitaldog.net/files/Resolution.pdf<br> Yes it's really old! Nothing has changed however. I really DO need to update it as a modern video and cover Lightroom. In the meantime, you'll see that the resolution '<em>tag</em>' is rather meaningless and the way to work is by understanding the number of total pixels you have over hight and width. </p>

<p>How about an Epson Picture Mate? I had one years ago, made awesome prints:<br> http://www.epson.com/cgi-bin/Store/jsp/Product.do?sku=C11CA56203&ref=sem_us-cse-google-shopping&wm_ctID=475&wm_kwID=58407985&wm_mtID=234&wm_kw=Google+Shopping&utm_source=googleshopping&utm_medium=shopping+portal&utm_term=google+shopping&utm_campaign=us+-+cse+-+google+shopping&zmam=71433176&zmas=1&zmac=1&zmap=C11CA56203&gclid=CjkKEQjwwbCcBRCxvJn9-N6dorwBEiQAVriOiuDDfu8z7rKfUOQ9_za3h28_Ian89siY5C4dTAFVbHLw_wcB&gclsrc=aw.ds</p>

<p>I doubt Nikon is altering the raw data itself, just as a DNG doesn't. It's updating some proprietary metadata I suspect. Adobe treats NEF's as '<em>read only</em>' and produces sidecar's but not for DNG. The opposite is true for NEF's with Nikon's software.</p>