unprocessed scanning

[q.g._de_bakker]

It would indeed be a big difference. The question is whether such a difference exists. The thing to avoid is confusing different forms (of representation, data format) for that thing that would put some sense into 'raw' vs 'cooked'.<br>If we can and do agree on that (which i suspect we do), i think we can and do agree on that. ;-)

[digitaldog]

<blockquote>

<p>The question is whether such a difference exists.</p>

</blockquote>

<p>Between the '<em>raw</em>' data from a trilinear CCD scanner and a single capture camera using a bayer array? Pretty sure it's quite different. But I'm open to see otherwise if anyone has a way to illustrate the differences. I started with: <a href="http://www.digitaldog.net/files/raw.jpg" rel="nofollow" target="_blank">http://www.digitaldog.net/files/raw.jpg</a></p>

[digitaldog]

<blockquote>

<p>What's a good resolution to scan at?</p>

</blockquote>

<p>Ask yourself how many pixels do you want over each axis.<br>

http://www.digitaldog.net/files/Resolution.pdf</p>

[lenny_eiger]

<blockquote>

<p>Because, in the words of another recent poster who I believe captured the spirit of the problem, I think you are a “nasty bully”. I am sorry, but such behavior does not deserve “deference”.</p>

 

</blockquote>

<p>My apologies, I did not mean to take sides. Every time I read threads with this much vitriol I just zone right out. I don't want to figure out who's right, I just want the forum to be a nicer place where everyone gets respected (that means the both of you...). I want everyone to get some deference. We all have different experiences.... etc.</p>

[q.g._de_bakker]

<i>"Between the 'raw' data from a trilinear CCD scanner and a single capture camera using a bayer array? Pretty sure it's quite different. "</i><br><br>That was not in question, Andrew. The question was whether that is a difference between 'raw' and 'cooked' (which it is not) or between two 'raw' files containing data sets in a different configuration (which it is).<br>Your opinion appears to be that unless there is a bayer (or similar) pattern still present, it is not a 'raw' file. It should be clear by now that such a view is taking two quite separate things (as yet unprocessed by the user and not yet fit for consumption) as being one and the same. They are not.

[digitaldog]

<blockquote>

<p>The question was whether that is a difference between 'raw' and 'cooked' (which it is not) or between two 'raw' files containing data sets in a different configuration (which it is).</p>

</blockquote>

<p>Some are calling a trilinear scan, resulting in baked RGB pixels in an undefined color space, and more importantly undefined image state (rendering) a '<em>raw</em> scan'. The other data from a camera has no such ambiguity if we're referring to data that needs to be demosaiced. I've provided an example of what that partially processed but agreed upon raw data looks like (it doesn't look anything like a '<em>raw</em>' scan). So we're down to semantics. My take is, a <em>raw scan</em> is a big pile of undefined terminology. It's raw because of this or that setting, it's ugly (why?), it's got a linear tone curve (I'd not call that raw), it's in this or that color space? <em>Raw scan</em> is primarily a made up term with lots of ambiguity. Could one man's '<em>raw</em>' scan be another's idea of the preferred global rendering? <br /> <br /> You could call the last image printed on National Geographic <em>raw</em>. Doesn't make it so. And I don't think anyone here would agree that the file used for the CMYK conversions for the mag is ANYTHING like the raw data from the camera that was saved on a PC card! It's raw, it's unbaked, <strong>it's not yet rendered</strong>.</p>

<blockquote>

<p>Your opinion appears to be that unless there is a bayer (or similar) pattern still present, it is not a 'raw' file.</p>

</blockquote>

<p>To a large degree yes. And I believe by and large, the industry san's the marketing hype makers agree. Based on the severe differences in a raw bayer or similar pattern and what it becomes after raw processing (and you could say, zero all the settings, you now have a raw '<em>scan</em>' which is ridiculous). Scan (raw whatever that's supposed to mean) or otherwise and data from these cameras is factually vastly different. Why call them the same name? <em>Raw scan</em> is a marketing created term in that it's used to give the idea the <em>raw scan</em> and the raw camera data are somehow similar or on par, they are not. <br /> <br /> A DNG can contain DNG converted raw data. But a DNG can contain a Lossy converted data which is NOT raw data. It's partly baked (there's no WB applied which is useful but it's not raw data). People who strive to use clear language would (should) not call a Lossy DNG a raw file, it isn't. Nor is embeding a JPEG in a DNG make it raw (as some marketing folks would like the unsuspecting to believe). I see no reason <strong>not</strong> to differentiate the language describing a scan and a Lossy DNG as well as a true raw camera file. The data, the processing and the degree of control over that processing is vastly different. Would you agree? If so, why call all three kinds of data the same thing? They are not the same. <br /> <br /> Lastly, I agree that the raw file from the camera you find on your PC card is partially baked (there absolutely is processing happening before it's written) but it's a far cry from the baked data one gets from a trilinear CCD capture device. That's true, not interpolated (but baked) RGB data and numbers. The camera file isn't the same at all.</p>

[q.g._de_bakker]

<i>"Some are calling a trilinear scan, resulting in baked RGB pixels in an undefined color space, and more importantly undefined image state (rendering) a 'raw scan'."</i><br><br>Hmm... The issue here is that one person (who <i>can</i> be named, Andrew ;-) ) calls such a scan 'baked', without there being a reason to do so.<br>You're calling it a matter of semantics now. It isn't. A banana (remember those) isn't baked just because you can eat it without further ado. What is ridiculous is insisting that it has to be something that needs cooking to make it fit for consumption. A 'raw' file isn't 'baked' because there is no bayer pattern in it that needs to be removed, just as little as a raw banana is baked because you do not have to bake it.<br>I agree though that the term 'raw' is problematic. I said what i thought about that before. So it doesn't help that you bring your own problems (insisting that it looks like your patterned camera 'raw') to the matter. We need less hype. Not more.<br>'Raw' is no more, no less, than what you get out of a machine without you having had a chance yet to mess with it.

[digitaldog]

<blockquote>

<p>'Raw' is no more, no less, than what you get out of a machine without you having had a chance yet to mess with it</p>

</blockquote>

<p>Like a camera JPEG. </p>

[q.g._de_bakker]

Indeed.

[ant_nio_marques]

<p>'Raw' is an adjective. It's unfortunate that it consists of 3 letters and as such was made into a file extension, hence came to be thought of as a type of file. For all I care, you could call them .BAY(er), .F(oveon)X3 and .T(rilinear)CC(d). I don't see what these discussions gain us. It's not like the sloppiness of terminology in this case can have any problematic effects.</p>

<p>Now, can anyone PLEASE provide references as to the resolving power of photographic paper? I don't want to doubt Joe, but it's the first time I've heard it was comparable to that of film (actually, higher). Everyone here seems to be working under a similar assumption, so I can only assume it's common knowledge. Is it discussed somewhere?</p>

[ian_dunross]

<p>That for all your responses! I've neglected this thread for the past 2 days, but have been catching up on all the posts this morning. Not sure if I fully understand what everyone has said though...</p>

<p>I remember someone asking what the <strong>purpose</strong> of these scans are. These are old family photos, and I am scanning those for the purpose of preserving them in digital format (to archive them, view them later, prevent further degradation, etc)</p>

<p>One of the reasons I wanted to do these scans in an unprocessed way is because I've always regretted the destructive edits I have to photos I took on digital camera. I am a novice at best in Photoshop and making adjustments to white balance, curves, saturation, etc</p>

<p>So I want to avoid making these edits in the scanning software when I scan. What I want to know is whether I am missing out on anything that cannot be done later in Photoshop or Lightroom?</p>

<p>If it's just a matter of "processing" them now or processing them "later", I'd rather leave it to later. </p>

<p>Thanks again for all your responses!</p>

[digitaldog]

<blockquote>

<p>One of the reasons I wanted to do these scans in an unprocessed way is because I've always regretted the destructive edits I have to photos I took on digital camera.</p>

</blockquote>

<p>Altering the RGB numbers is destructive, do it high bit, it's nothing to worry about:<br>

http://www.digitalphotopro.com/gear/imaging-tech/the-bit-depth-decision.html<br>

IF the scanner has this high bit capability, doesn't really matter if you do it at the scan stage or later in terms of the data. It will be much faster to correct and produce an idealized tone and color appearance at the scan stage. Doesn't take the scanner any longer to create the data with proper settings. Opeing, editing, saving in Photoshop will likely take longer, but the toolset is hard to beat. </p>

[q.g._de_bakker]

There is, of course, a simple way to be able to do destructive edits of digital files and still retain the original (dare i say it: 'raw') file. Edit a copy of the file.<br>We can edit and store any intermediate result to fall back to when further edits go wrong. As often as we like.<br><br>There is not much scanning software can do that can't be done later (and better) in editing software. You can (depending on what scanner and software you are using) adjust some hardware specific things such as the gain setting, select a multiscan mode to reduce noise, switch to a fine scan mode in which only one ccd line is used, and set the output format parameters (like bit depth). The rest (including tweaking contrast and colour) can be done later. So scan 'clean' ('raw') and work on a copy of the resulting file.

[lenny_eiger]

<blockquote>

<p>The rest (including tweaking contrast and colour) can be done later. So scan 'clean' ('raw') and work on a copy of the resulting file.</p>

</blockquote>

<p>There is one exception to this. Drum scanners driven by Digital PhotoLab Pro (Howtek's, Aztek Premier) can create a set of settings, collectively called a CMS file. This file is sent over to some firmware location in the scanner, and it adjusts the A/D converter so that the scan is done within the range of the CMS "profile". The resulting scan has a perfect, uncombed histogram, complete with adjustments intact.</p>

<p>I know the OP is using a flatbed... but the scan raw isn't a hard and fast rule. If it works in your setup, great.</p>

[cabbiinc]

<blockquote>

<p>I am using an Epson V700 to scan 20-30 year old photos.</p>

 

</blockquote>

<blockquote>

<p>In this context, is there anything I am missed out by using Epson Scan instead of SilverFast AI or VueScan? In other words, do they offer anything other than just post processing? Do they so anything "special" that I won't be able to do later in Photoshop?</p>

</blockquote>

<p>I have the Epson 4990, the predecessor to the V700. About the only thing I can see that VueScan does that Epson Scan won't is multi-sampling. As the name implies it takes multiple samples of each pixel, averaging the results, before moving on. But please don't think that this is a cure-all for a number of ills. The only thing it's supposed to help with is digital noise in the scans themselves. If you don't see any noticeable digital noise then there's no real reason to need it.</p>

<p>And as has been said when you asked a very similar question a year and a half ago you should try the trials of VueScan and Silverfast to see if there's anything that jumps out at you.</p>

[digitaldog]

<blockquote>

<p>As the name implies it takes multiple samples of each pixel, averaging the results, before moving on.</p>

</blockquote>

<p>And one could attempt similar on multiple saved scans within Photoshop (what a drag). Also, scanning at a higher resolution then sampling down using Bicubic and similar does help with noise too. You end up 'averaging' out a lot of it depending on the size from big to small(er).</p>

[cabbiinc]

<blockquote>

<p>And one could attempt similar on multiple saved scans within Photoshop (what a drag).</p>

</blockquote>

<p>True, but VueScan's multi-sample does it in one pass with no alignment problems that can happen with multiple passes, and it will do it in a fraction of the time compared to multiple passes to try to achieve the same thing. But hey, if you just want to argue for the sake of arguing go ahead and knock yourself out.</p>

<p> </p>

[digitaldog]

<blockquote>

<p> But hey, if you just want to argue for the sake of arguing go ahead and knock yourself out.</p>

</blockquote>

<p>I wasn't arguing, I <strong>agree</strong> it's better to do at the scan stage (most work too). I'm pointing out that one <strong>can</strong> do something similar <em>after</em> the scan as the OP asked!</p>

[q.g._de_bakker]

<i>"[...] it's better to do at the scan stage (most work too). "</i><br><br>I'm not quite sure whether you mean to say it is less work when doing it in post than at the scan stage, or whether you are saying that most work is best done at the scan stage.<br>But if (as i suspect) the first it should perhaps be pointed out that it is <b>least</b> work, not most, when doing it at the scan stage (just tick a box and it happens automagically. As mentioned: in one pass, without alignment issues and though a lengthier process than doing a simple scan, taking much less time than doing multiple simple scans that are to combined in post).<br>(If you meant the second, it has already been said that only things that make use of whatever the scanner hardware offers is best done at the scan stage.)