--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Martin Wesley" < mwesley250@e...> wrote: ... > In theory you are absolutely correct but I think practically data > destruction remains an issue. and bla bla bla <G>... big snip... I don't think you have to justify your complicated adjustment layers. As you say it relates very closely to darkroom work and many fine workers do extensive dodging and burning routines. Under these circumstances staying high bit can be a pain, and I realize many people work in 8 bit. > Anyways my point is that 8-bit image adjustment is widespread and that makes > data loss from poor or over adjustment an issue. So if something like > OPM/IJC increases the margin of error I have working in 8-bit and allows me > to push the data a bit farther before print quality breaks down, I would be > very interested. Well, now I'm really blowing smoke because of my lack of knowledge. How that linearization is applied is really the question, and if it's primarily the same as a final adjustment curve out, then potential destruction is a non-issue in terms of one method over another. > If it doesn't, then as you say, it is then a matter of ease > or use and convenience which can be a significant factor. Absolutely, there are many impressive characteristics of OPM/IJC, and if it supported my printers, I'd be all over it. But here's another major issue we are ignoring. Antonis tells us that resizing the file to a friendly dpi is ideal with OPM/IJC, as is high bit. If changing to 16 bit then resampling, you will be filling in levels and certainly be sending a file with no gaps. Purists would say it's non image info, or noise, but I would say it would result in a significantly better print than a file with major dropouts in the histo. So any internal tonal adjustment done by linearization will no doubt be non-destructive, you're working with a lot of levels now. Of course you could do the same thing before a final adjustment curve out... > Would tweaking the separation curves take things a step further and > genuinely improve output rather than just manipulating the input data as you > explain above? That's really hard to say. How linearization is applied vrs how seps are applied internally would have something to do with it. It's all theoretically potentially destructive. I tend to like to make the seps as linear as possible so multiple serial adjustment is kept to a minimum, but that's based on some bizarre religion instead of science. ...You have certain input data from the scan or > digital capture and the order or manner in which you alter that data from > its initial to final form would seem to be immaterial to the final result. > (Which goes back to the importance of scanning to printing.) > Can we be > certain that all paths treat the data in the same manner? No, some adjustments MAY be being applied in these drivers by defining how they ramp, rather than simply applying a curve to an existing file. Also, I've found that adjustments applied via a profile conversion result in more loss than the exact same adjustments applied manually, though the difference may never show in a print. > Some workflows > such as the RGB separation curves may put much more stress on the integrity > of the file data than some others. Applying the curves to an 8-bit image > file really hashes the histogram which may or may not effect image quality. > Very image dependent. Quad ink separation is very severe, no matter where or how it's applied. So how all these genius' are addressing that is interesting, it all seems to work to varying degrees. You can detect stepped output sometimes with some systems. I think that just further stresses that our files need to be pretty tough to begin with. I want to add a note about Roy's work with Gimp. My apologies to him for not working with it more yet. His final builds are very easy to install and use, no terminal work is necessary. The whole thing is very ingenious, and he seems to be coming up with some very easy tools to create curves. Time for this dottering quad cadet to go down for a nap. Tyler
Message
[Digital BW] Re: OPM in theory (to Martin's q.)
2003-06-07 by Tyler Boley
Attachments
- No local attachments were found for this message.