Ad
Ad
Ad
Pages: « 1 [2] 3 »   Bottom of Page
Print
Author Topic: Consensus needed on benefit of 16-bit editing  (Read 10973 times)
digitaldog
Sr. Member
****
Offline Offline

Posts: 9222



WWW
« Reply #20 on: September 23, 2005, 02:39:18 PM »
ReplyReply

Quote
Andrew,

Thanks for citing the entire post. I appreciate it. I shall read it attentively. Yes I did join Dan's list quite a while ago, and didn't need aspirin, but then again I haven't been there very often. Maybe the dosage of the medicine correlates with the dosage of the exposure - but I doubt that - it's just me - I can't get too emotional about any of this. I depend on what I see in my prints and I refuse to get fussed over it. I think there are probably a great many out there like me who haven't seen any readily obvious differences between printed images processed from 8 or 16 bit files but do the latter anyhow for insurance. Storage is cheap, computers are fast, so why not.

And yes - thanks for reminding me - the wider the colour space the longer the distance between levels and logically the greater the risk of posterization. BUT the authority I can't quote (because the information is copyrighted and the permissions insufficiently clear), mentioned that you can shed down TO something like 38 levels per channel before you'd see a difference in the prints (I must say I found this hard to swallow - but the source has considerable professional credibility and would seem to have hard evidence up his sleeve). I expect he made that comment in the context of RGB98 working space, but that wasn't specified in his material. Now if THAT's true, it has some pretty clear inferences for the 8 versus 16 bit editing issue, which was the context of his discourse.
Print to what and after what edits? Again, even agreeing on the 38 levels to all and future output devices, what happens if for some reason, you need to apply other edits or other conversions?

High bit editing is about flexibility and insurance. There are those who do not believe in insurance. I can’t knock them for that. Look how few in New Orleans had flood insurance. Look at those who feel that extended warranties are either good or bad. However, in the case of Dan, I don’t see any debate about the merits of high bit editing on wide gamut color spaces. That wasn’t originally mentioned when years ago, he proposed that no one has been able to illustrate that using the same edits on the same file in high bit would produce superior quality. It’s clear on just this one snapshot that there is less noise in the high bit file. Now that I’ve shown this, the rules have changed whereby we need to now bring the gamut of the working space into the test. I submit that using LAB, his new favorite color space produces the same issues. Considering we’re talking digital capture and not scanned images, and considering in this case I’m working in ACR, I have four options before I even go into LAB (assuming I would even do this). I can either toss a good chunk of color I can user or keep it. If the later, then I either have to work in high bit or I have to accept quality loss. The only downside is a larger file. Given the choice between colors I have and can use with a larger file or tossing away colors and working with a file half the size, I prefer the high bit approach.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #21 on: September 23, 2005, 03:42:48 PM »
ReplyReply

Andrew, I'm with you on the insurance angle - as I mentioned that is the main reason why I, like many others, also do my editing in 16 bit, and I work in ProPhoto. On this latter point though, just yesterday, I came accross a situation (a couple of scanned negatives) where ProPhoto produced mangled skin tones that were difficult to correct in PSCS2, so I re-scanned in RGB98 and they came back to looking very natural - again a case where not one-size-fits-all. Alot of what one does really depends on the characteristics of the image and what one intends to do with it. This discussion has been useful to elucidate some of the finer points about the 8 versus 16 debate - which is likely to carry on, and carry on. Meanwhile, for me it is back to editing my images - in 16 bit  Cheesy Cheers
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
digitaldog
Sr. Member
****
Offline Offline

Posts: 9222



WWW
« Reply #22 on: September 23, 2005, 03:47:43 PM »
ReplyReply

Quote
On this latter point though, just yesterday, I came accross a situation (a couple of scanned negatives) where ProPhoto produced mangled skin tones that were difficult to correct in PSCS2, so I re-scanned in RGB98 and they came back to looking very natural - again a case where not one-size-fits-all.
I can’t understand why the skin would be mangled in one working space versus the other all things being equal. In what way?
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #23 on: September 23, 2005, 04:08:57 PM »
ReplyReply

Over-saturated redness. I've made some inquiries and it has been suggested to me that skin tones can be more pleasing in a narrower colour space because of lower gamma resulting in less saturation. Much of my work doesn't involve skin tones, so this was a bit of a shocker; the other stuff - city scapes, archeological sites, monuments, landscapes, etc. do very well in the wider space. That too I use mainly for insurance as it appears that our Epson printers using Ultrachrome and K3 inks can reproduce some colours that are beyond the RGB98 gamut.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
61Dynamic
Sr. Member
****
Offline Offline

Posts: 1442


WWW
« Reply #24 on: September 23, 2005, 07:02:09 PM »
ReplyReply

Quote
BUT the authority I can't quote (because the information is copyrighted and the permissions insufficiently clear)
Copyright law does not prevent the ability to quote a passage from a book or other copyrighted writing. Feel free to quote a paragraph or two without fear of legal repercussions; you have a legal right to do so.

Or, at the very least tell us who is this "authority" person is so we can look them up ourselves.

_,,


Well my mind has been made about buying his new book. I never made the connection that the person involved in this particular discussion on 16-bit editing was Dan. Perhaps it's because I didn't care to remember the name of that anti-16-bit goober that Mr. Lindbloom mentioned on his site...

Now that I know these are the same people I can't take any of his advice seriously and I will not be buying his book. It's one thing to do or believe in something that I disagree with but it's something else to be so bull-headed about a subject and out-right refuse anything other than one's own ideas.

Forced ignorance is the greatest form of stupidity. Dan is chalk-full of forced ignorance on this subject which throws into question his ability to think rationally about anything else related and provide sound advice.

Quote
I've made some inquiries and it has been suggested to me that skin tones can be more pleasing in a narrower colour space because of lower gamma resulting in less saturation.

Those suggestions are malarky. I can't see how converting from one space to another can effect skin-tones like you describe unless the color-space conversion was done improperly.
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #25 on: September 23, 2005, 08:43:54 PM »
ReplyReply

Daniel, if you have access, go to the archive of Tim Grey's DDQ and you will find a very interesting couple of paragraphs on this issue in the September 1, 2005 email. I am being very cautious about the legal aspects of what I quote because copyrights are usually accompanied by an exception clause, which is missing from this source. The USA is a very litigious society and it's not worth taking any risks, whatever the rights may or may not be.

Re buying Dan's book, it appears to be sold-out, so even if you changed your mind you'll be waiting for it. As I mentioned somewhere, this 8/16 business occupies one page out of 358. I've reached page 150, and I've attended one of Dan's workshops where he presented a small amount of the subject matter covered in the book. Although I also edit my images in 16 bit regardless of what he says, I am very happy that I purchased the book as soon as it was published. It is technically very nuanced and quite deep. There is a considerable amount of meaningful material here on the whys and wherefores of image editing (in paticular colour and luminosity) that I haven't found in any other book on Photoshop and I have a fair number or excellent ones. I believe it's irrational to assume that disagreement with an author on one issue makes the rest of the book somehow suspect. But, each to his own.

Now turning to the colour space question, just to give you the complete picture before you come down too hard on what is malarky, there was NO CONVERSION from one colour space to another. Although I am now 100% digital using a Canon 1Ds, before that I did my colour work using ASA 100 colour negative film. I am now scanning a selection of those legacy negatives so I can make better enlargements than what I get from labs over which I have no control. I have been doing most of my scanning (Minolta DiMage Scan Elite 5400) in ProPhoto RGB colour space because it is said to capture some colours that my Epson 4000 can print, but exceed Adobe RGB98 colour space. On the whole this process has been working very well indeed. However, on a couple of portrait shots, I noticed that the skin tones were flush red while the grey balance was fine both by the numbers and my monitor. I knew the skin tones were wrong because one of the subjects was me and I know what my face looks like; the other was a couple from India and they don't have shocking-red skin. I suspected that perhaps the colour space could be a factor. So I RESCANNED the same negatives in ARGB98, and sure enough the skin tones came back to normal. In a private email I submitted these observations to a highly regarded, well-published authority on digital imaging (not Dan - someone else) and the reply I got is what you are calling malarky. The name of the person doesn't matter, and in fairness I'm not revealing the source, because it was a private exchange and that person did not respond to me with any forethought or intention of being embroiled in controversy. Now that you have more information about the background, more useful would be your take on the reasons why the explanation I got is malarky.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Jonathan Wienke
Sr. Member
****
Offline Offline

Posts: 5759



WWW
« Reply #26 on: September 24, 2005, 12:14:22 AM »
ReplyReply

Quote
Now turning to the colour space question, just to give you the complete picture before you come down too hard on what is malarky, there was NO CONVERSION from one colour space to another. Although I am now 100% digital using a Canon 1Ds, before that I did my colour work using ASA 100 colour negative film. I am now scanning a selection of those legacy negatives so I can make better enlargements than what I get from labs over which I have no control. I have been doing most of my scanning (Minolta DiMage Scan Elite 5400) in ProPhoto RGB colour space because it is said to capture some colours that my Epson 4000 can print, but exceed Adobe RGB98 colour space.
This is not correct. Regardless of output space selection, you are always doing a color space conversion unless you're merely scanning and assigning a color space to the results. Good scanner software will have a color profile for the film stock you're scanning, and will assign the film profile to the raw scan data, then convert the RGB data from the film profile's color space to the selected destination color space. As long as the scanned colors are in-gamut, the selection of destination space is irrelevant; the output will appear identical in a color-managed appregardless of output space as long as no colors are clipped. But if the choice of output space materially alters the appearance of the image (other than gamut clipping) in a color-managed app like Photoshop, then you've probably got crappy scanner software that is merely taking the raw scan data, applying some sort of cluster-fudging to it, and then applying whatever output profile you select to the resulting RGB data.

There's a simple way to verify what's going on. Scan a frame twice with all settings identical except for the selected output color space. Create an Adobe RGB scan and a ProPhoto scan. Open both images in Photoshop, and apply the ProPhoto profile to the Adobe RGB scan. Compare the Adobe RGB scan (that now has ProPhoto assigned) to the native ProPhoto scan. If they look identical, you have crappy scanner software that doesn't have a freaking clue what color management actually is. If they look noticeably different, something else is screwed up.
Logged

Ray
Sr. Member
****
Offline Offline

Posts: 8939


« Reply #27 on: September 24, 2005, 01:46:27 AM »
ReplyReply

Quote
So I RESCANNED the same negatives in ARGB98, and sure enough the skin tones came back to normal.
Mark,
I'm confused. Was this before or after you fixed the color management problems you had with SilverFast?

Skin tones are very critical because we are all familiar with them. It's part of the reason I'm scanning some slides twice, once with SilverFast and once with Vuescan, both into the ProPhoto color space. Vuescan sometimes gives me a credible skin tone with one of the two options ticked, restore fading, but an excessivley red skin tone with both options ticked. Silverfast can sometimes have me messing around for ages to get the same affect.

It's quite possible that use of one colour space in preference to another will produce different (global) results if there's something not quite right in the color management chain.
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #28 on: September 24, 2005, 08:46:56 AM »
ReplyReply

Jonathan - I much appreciate your responding to this issue in the tightly reasoned manner you have; it is an intriguing problem and you have raised additional considerations about it that deserve to be probed. Notwithstanding the advice that I reported here - which under the circumstances I still think is plausible, in the back of my mind I haven't dismissed earlier suspicions that perhaps there may be some colour management issues relating either to the scanner software, the scanner itself or the combination. So let us now drill down a bit more.

It gets a bit difficult to analyse this without knowing more about how the scanner software ACTUALLY works, internally. But the software on the disection table here is Silverfast Ai 6 Studio Edition. This is supposed to be the cat's meow of scanning software (unless you own an Imacon), but sticking with the animal analogy, it is also a dog's breakfast for understanding what it really does, because the documentation is crummy and the interface, to put it politely, is "arcane".

Let us recall that I am scanning colour negative material, and that has limitations for colour management different from positive films. It has an obtuse colour management options page that lets you make the following selections:

(A) Colour Management: (A-1) Internal>Monitor: either None or ICM (Image Colour Matching); (A-2) Internal>Output: RGB, or ICM, or CIE Lab, or CMYK. For A-2 I use RGB. For A-1, I can use None or ICM. ICM yields a much more saturated image on screen. But interestingly, this choice does not affect the RGB colour values. (By the way, I haven't seen, or perhaps missed, where they define what "Internal" means.)

( Profiles for ICM:  (B-1) Internal: The choices are a hodge-podge of colour working spaces, such as RGB98, ProPhoto, Colour Match RGB, etc. I have used either RGB98 or ProPhoto as we discussed earlier, and this is the choice that critically affects values once the image is opened in Photoshop. (B-2) Rendering Intent: it provides the usual suspects; I use Relative Colorimetric.

© Embedded ICC Profiles: Once you select a colour space under B-1 above, this section automatically repeats that selection, but there is a check box to "Embed the ICC profile", which I leave checked because that is what codes the colour space data going into Photoshop.

Now, for dealing with the special case of colour negative film, Silverfast has a module called "Negafix". Negafix allows you to select from a very large number of colour negative films according to what is exactly the film you are using, or comes closest in terms of hue/brightness/saturation on the monitor (mine is very well-calibrated and profiled). Then it allows you to tweak the generic exposure and hue associated with that selection, just in case - like me for example - you are using a brand that doesn't come out bang-on correct for any of their presets. Not explained is how this Negafix module integrates into the scanning workflow - i.e. does it act like a film profile at the outset of the scanning process, or is it converting numbers at the end of the process of generating the image file from scanned data (I guess what you mean by "cluster-fudging").

This is as best a description of the Silverfast colour management system for negatives that I can give you, after having read the Silverfast manual and Taz Tally's SIlverfast book, and Ian Lyon's Silverfast tutorials and watched Lasersoft's crummy Quicktime movies that are supposed to "explain" things. I frankly think there is confusion of concepts in the layout of their whole colour management set-up, and I have told them as much but there has been no reply to that generic complaint. (Be all that as it may, I must say that save for this issue - and one other immediately below - once you mess around enough with the settings and get a combo that works, it works pretty darn well.)

Now Jonathan, the issue of "red" was stuck in my mind for the other matter that I sent you the image snippets about - and I asked myself the very question you are now posing - what if the colours are indeed out of gamut, or put otherwise what if the ProPhoto selection is allowing-in out of gamut colours. So after seeing how much better the skin tones emerged due to a simple switch from ProPhoto to RGB98, I went back to that red/purple issue and rescanned one of those Chinatown red images in RGB98; lo and behold, the red came out tamer and when soft-proofed, there was still alot of toning down with some apparent hue shift toward purplish, but not nearly as bad, and not to the extent of wiping out image detail that happened when switching on soft-proofing with the ProPhoto version. So I think this indicates that there may be a gamut issue at play here affecting both problems. In fact, it may be one and the same problem. It seems that selecting a narrower colour space when dealing with some troublesome colours squeezes the latter into gamut more successfully than can happen once the image is opened in Photoshop with the wider colour space. I'm aware that I'm treading in a bit of an alligator swamp because I don't know all these alligators and their habits as well as would be desirable; so now that you've read in much more glowing detail what I can tell you about the matters you raised, I am very interested in your assessment.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #29 on: September 24, 2005, 09:02:58 AM »
ReplyReply

Post-scriptum - those alligators I'm referring to are the ones resident within Silverfast - nothing else!
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Jonathan Wienke
Sr. Member
****
Offline Offline

Posts: 5759



WWW
« Reply #30 on: September 24, 2005, 10:40:57 AM »
ReplyReply

I have a wedding today; I won't really be able to get into this until tomorrow evening. But it is on my to-do list. If you could conduct the experiment I suggested and email me 800 pixelish JPEGs of the Adobe RGB and ProPhoto versions of the scans or post liks to them in this thread (so others could follow along) that would be helpful.
Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #31 on: September 24, 2005, 10:53:21 AM »
ReplyReply

Thanks Jonathan - I'll have to email the images to you, because my ISP won't let me hyperlink posted images to a discussion forum. I apologize to the others, but it is a technical limitation I haven't made time to work around yet. It is becoming more important that I do so.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Ray
Sr. Member
****
Offline Offline

Posts: 8939


« Reply #32 on: September 24, 2005, 10:57:33 PM »
ReplyReply

This is getting a bit off topic, but when you two have sorted out the problems of scanning negatives with SilverFast, you'll let me know won't you  Smiley .

My first attempts scanning negatives using my Scan Elite 5400ll, put Dimage Scan first, Vuescan second and SilverFast last with regard to ease of use and color accuracy, within a reasonable time frame, of course.

I've since downloaded a more recent version of Vuescan which seems to have addressed a number of issues relating specifically to the 5400ll, and the order has now changed. Vuescan is by far the best, Dimage Scan second for an automatic scan with minimal adjustments and SilverFast last again.

SilverFast's behaviour with negatives is a real puzzle. The prescans are not even in the ball park, not even near the ball park; in a completely different city in fact. There is clearly something seriously wrong here. The film type selections in Negafix seem to have no bearing on reality. They are completely inaccurate.

Reading Ian Lyons tutorial on Negafix, he mentions that the prescans can initially look way off because the crop lines might include the black edges surrounding the frame. Move the crop lines inwards and the color changes. Not so with my setup. Makes no difference to the over all color wherever the crop lines are. I've got no idea if this is another symptom of something seriously wrong, or if it's an improvement in the software to remove yet another pitfall that can confuse the amateur.

Of course, the big features of SilverFast are the numerous ways you can change color and color casts, and Negafix has added yet another range of color and hue adjustments. Given enough time, however bad the prescan may look, one can eventually knock it into shape. However, there's a major problem here, even if you do have the time. How do you really know when the colors are accurate? We can't tell by eyeballing a negative on a light-table.

On the issue of a scan into the ProPhoto color space looking redder than the same scan (with same adjustments) scanned into a smaller gamut color space such as Adobe RGB, this is indeed true with Silverfast and negatives, on my system.

Perhaps this is another clue as to incorrect settings somewhere. It's not just a case of the ARGB scan being less red. The entire color range is less saturated, including the appearance of the prescan, indicating that the 'numbers' have not changed with change of 'profile to embed' in the SilverFast CMS section. I'm getting an ARGB image with ProPhoto numbers. To get it looking right, as I initially edited it, I have to assign the ProPhoto color space in PS.

Nevertheless, whether I'm scanning slides or negatives, the prescan always matches the scanned result very closely, when opened in PS with whatever embedded profile I've specified in CMS.

I'll copy this post to a new thread because it's now way off topic.
Logged
hdomke
Full Member
***
Offline Offline

Posts: 153


WWW
« Reply #33 on: September 26, 2005, 05:46:07 AM »
ReplyReply

Tim Grey responded to my question today so I thought I would add it to the mix. Interestingly he says "yes and no" to high bit editing. Tim puplishes the DDQ Newsletter http://www.timgrey.com/ddq/index.htm

Here are his exact words:
There are two key points I'd like to make here. The first is to agree with Dan that the 16-bit advantage is indeed a benefit in theory for color photographs, and with today's technology there is no visible benefit in the final results. Having said that, I still prefer to optimize images in 16-bit. This is simply because I prefer to maintain as much information in the image as possible, even if that additional information doesn't provide a benefit today. Part of this is philosophical (meaning you could very easily discard the notion), but part of it is practical. The practical side of it is the assumption that at some point in the future, we'll have displays and printers that are actually able to take advantage of high-bit data to produce a difference that improves upon what we see with 8-bit data. For example, I expect that at some point there will be printers available that produce a visually better result from 16-bit data than they do with 8-bit data, and at that point you'll wish that all your images had been optimized and saved in 16-bit. Of course, I could be totally wrong on this assumption about future output capabilities.

So, you're looking for a definitive answer. That answer is that, today, there is no real benefit to saving your color photographic images in 16-bit per channel mode. The only benefit would occur with images that require very significant adjustment, but those images would be the exception, as the adjustments really need to be quite significant for there to be any advantage to 16-bit. I'd still prefer to keep those files in 16-bit mode with all layers intact, especially considering how cheap storage is these days.

Keep in mind that for grayscale images, as discussed in the prior question, there is indeed a benefit to 16-bit. So, while you can get excellent results with most color photographs in 8-bit, for grayscale images it really is important to work in 16-bit if that data is available in the original.

The second point I want to make will actually further erode the notion that you need to work in 16-bit, but I'll mention it anyway. That is, even if you strip out a significant amount of information in an 8-bit image by the adjustments you make, resulting in gaps in the histogram, you may not produce any posterization that is visible in the monitor display or final print. I sometimes do a demonstration with an 8-bit color photograph in some of my workshops, creating a Posterize adjustment layer to demonstrate the results of extreme posterization. I start with the value very high (the maximum is 255) and then gradually work it down, asking the students to tell me when they see evidence of posterization in the projected image. I generally get down to somewhere around 40 or 50 before the first student is able to see any signs at all of posterization, and even then it is only minor. The histogram at that point looks quite ridiculous, but the image still looks like a photo. This demonstrates that you can indeed push an image very far before any image quality problems become evident.

So, it is probably quite clear at this point that for color photographs there's not a strong argument in favor of working in 16-bit mode. I still prefer it, and still recommend it, but this is largely for two reasons. One, it virtually guarantees you can't strip out enough detail to cause posterization problems in the final output, even with significant adjustments, and two, it ensures you are retaining the maximum amount of information in your images that you will hopefully be able to take full advantage of in the future as display and output devices advance. I for one find it hard to believe, especially considering how far we've come over the last five years, that we won't have printers in the future that can achieve a benefit from 16-bit data.
--
Henry Domke

http://www.henrydomke.com/
Logged

Henry

Henry Domke Fine Art
www.henrydomke.com
jani
Sr. Member
****
Offline Offline

Posts: 1604



WWW
« Reply #34 on: September 26, 2005, 07:03:42 AM »
ReplyReply

Just because he can't afford an EDR display, doesn't mean they don't exist.

Okay, okay, this is cheating, but interestingly, it addresses two major problem with today's LCD monitors:

 - Really adjustable brightness
 - How black is black?
Logged

Jan
digitaldog
Sr. Member
****
Offline Offline

Posts: 9222



WWW
« Reply #35 on: September 26, 2005, 08:05:35 AM »
ReplyReply

What a wishy-washy answer of Tims. Tell him I said so and he should download my RAW file or at the very least, try working with RAW to wide gamut conversions and see if he still feels the same way. As yet, no one on Dan’s list, Dan included has admitted that the random noise seen in 8-bit and not high bit isn’t the result of the bit depth of the edit. They argue that we are fools to use “ultra-wide” gamut working spaces like ProPhoto or that this or that edit isn’t perfection (we don’t live in a prefect world with prefect Photoshop users). Yet the facts remain that using even minor edits on such a wide gamut file shows quite clearly the benefit of high bit editing.

Andrew Rodney
Author “Color Management for Photographers”
http://www.digitaldog.net/
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #36 on: September 26, 2005, 09:15:08 AM »
ReplyReply

You tell him you said so, and in the process start reading and representing comprehensively, carefully and objectively what some of your professional peers are saying. Just because you disagree with them isn't a reason to selectively distort arguments.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
digitaldog
Sr. Member
****
Offline Offline

Posts: 9222



WWW
« Reply #37 on: September 26, 2005, 09:17:42 AM »
ReplyReply

Quote
You tell him you said so, and in the process start reading and representing comprehensively, carefully and objectively what some of your professional peers are saying. Just because you disagree with them isn't a reason to selectively distort arguments.
I’m not about to spend $35 to join his list to disagree with him...
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #38 on: September 26, 2005, 09:58:59 AM »
ReplyReply

That's a cop-out - you don't need to spend 35 bucks to disagree with him. Someone of your standing in the digital imaging community can send him an email, because lesser (but equally parsimonious) mortals have also done it. Based on my experience, for a matter of signficant importance like this he is approachable regardless of whether or not you have paid the entry fee.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7044


WWW
« Reply #39 on: September 26, 2005, 10:07:27 AM »
ReplyReply

Henry, very good that you approached Tim Grey on this. I read the same DDQ and noticed there was also another question on the same subject - that one dealing with greyscale images, and in that case he said there is a tangible benefit using 16 bit mode, for the reasons given.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Pages: « 1 [2] 3 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad