 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| PhotoKB HomeDiscussion Groups Digital Photography Digital PhotoDSLR CamerasZLR CamerasPoint & Shoot CamerasFilm Photography 35 mmLarge FormatMedium formatDarkroomFilm and LabsOther EquipmentPhoto Technique Nature PhotographyPeople PhotographyTechnique GeneralGeneral Photo Topics General TopicsAustralian PhotographyUK PhotographyDirectoryPhoto Clubs |
Photo Forum / Film Photography / Large Format / May 2004Scanning 4x5 on epson 4870 at 16-bits/channel
Hi I bought an epson 4870 scanner today for the purpose of scanning 4x5 fuji velvia. I have done many tests and I am very satisfied with the results, scanning at 4800 ppi and 48-bits, then downsizing to 3200 ppi but keeping the 16 bits for processing. I can pull a lot of nice detail out of the shadows if I want with the 16-bit. Results are similar to drum scans I've done. So now I'm ready to scan a full size 4x5 sheet. 4.67 x 3.70 inches at 4800 ppi, 48-bit: I get the error "Selected area is too large for this resolution" Same at 3200, 48-bit. Only when I go down to 3200 ppi and 24-bit can I scan a full size 4x5. I'm running a 1.8 GHz win xp box with 1 GByte of ram. I get the same results if I run as a plugin to photoshop cs or as epson scan standalone. Has anyone had/solved this problem? If you successfully scan full size 4x5 at 4800 ppi and 48-bit, what kind of setup do you have? Thanks, Roger Clark >Has anyone had/solved this problem? If you successfully scan >full size 4x5 at 4800 ppi and 48-bit, what kind of setup do you have? Have you considered the memory and bandwidth limitations of what you're attempting? 4800 dpi is 23 million pixels per square inch. Times 20 square inches is 460 million pixels. That's 1.38 gigabytes at 24 bit color, 2.76 Gb at 48-bit. That 2.76 G image will take 5 minutes to move off the scanner and onto your PC or Mac at 9.2 Mbytes/s. FWIW, I'm scanning 4x5 at 2500 dpi and those 330 Mbyte files are killing me <G>. rafe b. http://www.terrapinphoto.com > >Has anyone had/solved this problem? If you successfully scan > >full size 4x5 at 4800 ppi and 48-bit, what kind of setup do you have? [quoted text clipped - 6 lines] > > .... 2.76 Gb at 48-bit. Which can't even be saved in most imaging programs. Photoshop can't handle over 2GB PSD or TIFF. The CS version can, but only in a proprietary file format, not PSD or TIFF. And no, saving as JPEG won't help at any compression rate either, as has to open at full pixel dimensions/filesize in Photoshop, ala TIFF. Mac > > >Has anyone had/solved this problem? If you successfully scan > > >full size 4x5 at 4800 ppi and 48-bit, what kind of setup do you have? [quoted text clipped - 17 lines] > > Mac Let me rephrase that slightly....what happens is, Photoshop will generally be able to SAVE the >2GB image. It just won't re-open it :) M >Which can't even be saved in most imaging programs. >Photoshop can't handle over 2GB PSD or TIFF. >The CS version can, but only in a proprietary file format, not PSD or >TIFF. Does VueScan handle >2gig files? > Does VueScan handle >2gig files? I don't think so, but I've never tested this. It depends on the inner workings of the TIFF library I'm using, and I haven't tested this. Regards, Ed Hamrick > > Does VueScan handle >2gig files? > > I don't think so, but I've never tested this. It depends > on the inner workings of the TIFF library I'm using, and > I haven't tested this. Don't most operating systems impose a 2GB ceiling for a single file? Bart > Don't most operating systems impose a 2GB ceiling for a single file? No, thank goodness. However, for most of us the practical limit for a single image is 4bg to 8gb. Photoshop CS, for example, has a feature to handle very large images. But a little arithmetic will show you that there are only rare circumstances in which a photographer (raster image work) will need an image that large, and even then it can be handled in mutiple file rather then one huge one. Just how large a raster image does one need for printing when printers don't 'resolve' better than 360spi with shallow bit depth? ["Followup-To:" header set to comp.periphs.scanners.] >> > Does VueScan handle >2gig files? >> I don't think so, but I've never tested this. It depends on the >> inner workings of the TIFF library I'm using, and I haven't tested >> this. > Don't most operating systems impose a 2GB ceiling for a single file? No. Win9x, Linux kernels on x86 machines before 2.2.14 or so (or any Linux distro using the ancient ReiserFS 3.5), and MacOS < X could have problems with files larger than 2G. There's a 2G limit on file size if you're using FAT32 with a normal (4K) block size, which may be an incentive for you to move to a Real OS that uses a Real Filesystem. I'd be surprised if the standard tifflib from SGI had problems with files larger than 2G, but architecture and OS-specific weirdness could throw monkey wrenches into the works. I've never seen a TIFF that large in the wild, but most of the TIFFs I work with are 1-bit.  SignatureMatt G|There is no Darkness in eternity/But only Light too dim for us to see Stupidity got us into this mess--why can't it get us out? Hire me! http://crow202.dyndns.org/~mhgraham/resume/ >> > Does VueScan handle >2gig files? >> [quoted text clipped - 3 lines] > >Don't most operating systems impose a 2GB ceiling for a single file? OS X seems to cope: Narcissus:~ cbrown$ ls -l foo -rw-r--r-- 1 cbrown staff 5000000000 May 19 17:26 foo >> Does VueScan handle >2gig files? > >I don't think so, but I've never tested this. It depends >on the inner workings of the TIFF library I'm using, and >I haven't tested this. I supoose a more pertinent question is, is there are file format in common use that can reliably support images which won't fit in the virtual addressing space of typical 32 bit processors, other than the new Photoshop format? After all, once you have all that data, it has to be stored somehow. To the OP - I guess you might get some joy from scanning in two halves, and then stitching back together in CS. Make sure you have stupid amounts of RAM before trying this, though... > >> Does VueScan handle >2gig files? > > [quoted text clipped - 6 lines] > addressing space of typical 32 bit processors, other than the new Photoshop > format? After all, once you have all that data, it has to be stored somehow. TIFF up to 8gb, but for all practical purposes 4gb. > To the OP - I guess you might get some joy from scanning in two halves, and > then stitching back together in CS. Make sure you have stupid amounts of RAM > before trying this, though... If the goal is a huge image, don't even worry about the RAM. RAM isn't the limiting factor. Start the job and go to lunch. However, there are better utilities than Photoshop for tiling. And for those of us on 32bit systems, that 4GB may be more theoretical than practical. I assume that Photoshop uses 32 bit word that then somehow maps to virtual memory. If it uses virtual memory directly, then 32bits = 4 GB minus virtual memory allocated to "other things." Performance is going to go down hill quickly as we x86ers are limit to 4GB of phycial memory for now. Todd > > >> Does VueScan handle >2gig files? > > > [quoted text clipped - 16 lines] > limiting factor. Start the job and go to lunch. However, there are better > utilities than Photoshop for tiling. > And for those of us on 32bit systems, that 4GB may be more theoretical than > practical. I assume that Photoshop uses 32 bit word that then somehow maps > to virtual memory. If it uses virtual memory directly, then 32bits = 4 GB > minus virtual memory allocated to "other things." Performance is going to go > down hill quickly as we x86ers are limit to 4GB of phycial memory for now. Photoshop won't use more than 2gb no matter how much RAM you have, regardless of the operating system, OS-X or Windoze. Set the preferences to use 100% of RAM when you have 4gb of RAM and see for yourself. > > And for those of us on 32bit systems, that 4GB may be more theoretical than > > practical. I assume that Photoshop uses 32 bit word that then somehow maps [quoted text clipped - 5 lines] > regardless of the operating system, OS-X or Windoze. Set the preferences > to use 100% of RAM when you have 4gb of RAM and see for yourself. Correct. And CS is buggy with RAM to boot. Most folks with 2GB are having to set PS CS to only use 45-50% of RAM. PS also uses scratch disk as main memory with RAM as cache. Of course, assuming you have 2GB of RAM or less, it's always been a good idea to set PS to use no more than 75% RAM anyway, as OS needs a good bit also. Mac > Hi > I bought an epson 4870 scanner today for the purpose [quoted text clipped - 23 lines] > Thanks, > Roger Clark This just came up in the photo.net digital darkroom forun. See www.photo.net/bboard/q-and-a-fetch-msg?msg_id=008ICU See Doug Fisher's response. It seems that it won't work at 4800 ppi if you have digital ICE turned on. But it should work if you turn it off. It seems to be a problem with the software. So it might work fine with Vuescan. By the way, I regularly scan 4 x 5 with and Epson 3200 at 16 bits per channel using Vuescan. This is a different issue and is a bug in the driver. There is a newer version of the driver that resolves this issue, Revision 2.0c Version 2.02. But this is not the issue that Roger has encountered. > > Hi > > I bought an epson 4870 scanner today for the purpose [quoted text clipped - 34 lines] > By the way, I regularly scan 4 x 5 with and Epson 3200 at 16 bits per > channel using Vuescan. "Roger N. Clark (change username to rnclark)" <username@qwest.net> wrote in <SNIP> > So now I'm ready to scan a full size 4x5 sheet. > 4.67 x 3.70 inches at 4800 ppi, 48-bit: > I get the error > "Selected area is too large for this resolution" I'm not too suprised at this a scan of 4.67" X 3.7" at 4800 ppi and 16bits per channel results in a scan size of about 2.39 Gbytes! You will need to scan at a lower resolution for this size of scan, especially at 16 bits. Steve. > "Roger N. Clark (change username to rnclark)" <username@qwest.net> > wrote in <SNIP> [quoted text clipped - 8 lines] > You will need to scan at a lower resolution for this size of scan, > especially at 16 bits. Or you can scan in sections that overlap, process each section identically, and then stitch together in Photoshop after you've downsampled to a more sensible resolution. You should be able to downsample to 3000 dpi with no loss of information (since someone here reported 30 lp/mm in one direction and 40 lp/mm in the other, and 40 lp/mm is (assume 3 pixels per line pair) 40x3x25.4 = 3048). IMHO, even 2700 dpi would be fine, but 3050 is safe. 4x5 at 3050 dpi = 180MP 4x5 at 2700 dpi = 146MP 3.7x4.7 at 2700 dpi = 127MP You'll want 2GB of RAM to handle those files, but at least it's possible. David J. Littleboy Tokyo, Japan >Or you can scan in sections that overlap, process each section identically, >and then stitch together in Photoshop after you've downsampled to a more >sensible resolution. If you have Photoshop CS, you won't need to downsample. Having a 64 bit machine with lots of RAM (e.g. a G5 with 6 gigs) may be useful here, a 32 bit system with 2 gigs will get there eventually, but it'll be painful. > >Or you can scan in sections that overlap, process each section identically, > >and then stitch together in Photoshop after you've downsampled to a more [quoted text clipped - 3 lines] > machine with lots of RAM (e.g. a G5 with 6 gigs) may be useful here, a 32 > bit system with 2 gigs will get there eventually, but it'll be painful. First, I don't believe it's truely 64-bit yet. But regardless, CS can't address more than 2gb of RAM, and in fact you will probably find it addressing only 1.8gb. A significant performance factor in CS will be found in using multiple spindles for work files. CS uses its own proprietary paging scheme and will page regardless of the amount of RAM but of course more is better because you can have other applications in the remaining space. We get along well enough with 4gb RAM and two spindles (G5, dual processor). Well, we did until the machine smoked last week, but it's under warantee. >> If you have Photoshop CS, you won't need to downsample. Having a 64 bit >> machine with lots of RAM (e.g. a G5 with 6 gigs) may be useful here, a 32 [quoted text clipped - 7 lines] >but of course more is better because you can have other applications in >the remaining space. Indeed. That's the point of having >2 gigs, even if one process can't exceed that. The OS will use some, and if you're loading large images into CS, you may well want to handle large images in another application simultaneously too. My lowly G4 can only handle 2 gigs of physical RAM, of course, but there's no prospect of me scanning anything larger than 6*6s in the near future. I'd be interested to see if Panotools could cope with multiple 6*6 scans on a 2 gig machine though - when I last used it to stitch "lowly" 6 megapixel images on a machine with 512 megs, the VM started thrashing pretty badly (looked like it had a working set in excess of 1 gigabyte at some points). > >Or you can scan in sections that overlap, process each section identically, > >and then stitch together in Photoshop after you've downsampled to a more [quoted text clipped - 3 lines] > machine with lots of RAM (e.g. a G5 with 6 gigs) may be useful here, a 32 > bit system with 2 gigs will get there eventually, but it'll be painful. But not downsampling is silly. The scanner simply isn't capturing 4800 dpi of real data; it's a 30 lp/mm x 40 lp/mm resolution device, and at the Nyquist frequency, that's 1500 dpi x 2000 dpi. While using enough pixels that the max signal in the data is at 2/3 Nyquist is more than adequate (3000 dpi), what I really think is that downsampling to 2400 dpi is the right thing with that scanner, just as the 2450 captured barely 1200 dpi worth of real information. I'm quite sure that if you scanned the same frame (35mm or MF) with a Nikon 4000 dpi scanner and the 4870, and downsampled both to 2400 dpi, the Nikon scan would look a lot better. And 6GB of memory is still quite serious money. Besides, 2400 dpi from 3.7x4.7 is a 30x38" print at 300 dpi, more than enough for most purposes. David J. Littleboy Tokyo, Japan > I'm quite sure that if you scanned the same frame (35mm or MF) with a Nikon > 4000 dpi scanner and the 4870, and downsampled both to 2400 dpi, the Nikon > scan would look a lot better. Downsampling is destructive. Why not scan to suit the output? >>>Or you can scan in sections that overlap, process each section > [quoted text clipped - 10 lines] > of real data; it's a 30 lp/mm x 40 lp/mm resolution device, and at the > Nyquist frequency, that's 1500 dpi x 2000 dpi. David, Nyquist is a commonly misunderstood theorem. The theorem is valid when the signal and sampling are in phase. In an image, image detail is not necessarily in phase with the sampling. Thus you need higher sampling to recover the information. For example, with 2 samples per cycle (Nyquist), you can set the phase to give zero response. Typically, you see good improvement with sampling at 2x Nyquist, or 4x the frequency, and there are still gains in going higher, although not as fast. See: http://www.clarkvision.com/imagedetail/sampling1.html Then, I've tested my particular epson 4870 and I see 50 to 60 lpm. I get better image detail if I scan at 3200 ppi versus 2400 ppi, but only small improvement at 4800 ppi. Roger > While using enough pixels that the max signal in the data is at 2/3 Nyquist > is more than adequate (3000 dpi), what I really think is that downsampling [quoted text clipped - 12 lines] > David J. Littleboy > Tokyo, Japan SNIP > Then, I've tested my particular epson 4870 and I see 50 to 60 lpm. > I get better image detail if I scan at 3200 ppi versus 2400 ppi, but > only small improvement at 4800 ppi. If you say 50-60 lpm, do you mean lines- or line-pairs/mm. I assume the latter, because my 2400ppi flatbed can resolve in excess of 30 lp/mm @ 10% modulation. What many, given some of the suggestions, apparently do not realise is that, scanning below the native scanner resolution will skip pixels in the sensor array and change the characteristic of the scanner to more of a point sampler rather than an area sampler. That will not only increase (grain) aliasing, but also make fine lines and edges at a slant, fade or even snap in-and-out of visiblility, which can look ugly. It is better to downsize (using a proper algorithm for downsizing if you don't want to make matters worse again ! ): <http://www.xs4all.nl/~bvdwolf/main/foto/down_sample/down_sample.htm> Bart > SNIP > [quoted text clipped - 5 lines] > latter, because my 2400ppi flatbed can resolve in excess of 30 lp/mm @ 10% > modulation. line-pairs/mm Roger This is a programming restriction because the EPSON Scan transfers RGB information in one go rather than individually (probably a Twain requirement). There is normally a limitation of 74Kb of data per line of scanned data that can be transferred (hardware limitation). For example: At 48bit colour 1 pixel = 6 bytes. At 4800 dpi and 48 bit colour the maximum width of scan will be 2.6 inches. Max scan width in bytes (74 x 1024) ----------------------------------- = Maximum width of scan Scan resolution in bytes (dpi x 6) 75766 (74 x 1024) ----------------- = 2.6 inches 28800 (4800 x 6) The 10,925 pixel limit is the same though this works out to a maximum scan line of 64Kb for both 48 and 24 bit colour: 10925 at 48 bit colour = 65.550 bytes (64Kb) 21845 at 24 bit colour = 65.535 bytes (64Kb) This is odd as I would have expected a maximum scan line of 12,627 pixels for 48 bit colour and 25,255 pixels in 24 bit colour. But it may be that there is a limitation of 64Kb per scan line for the Perfection 4870. > "Roger N. Clark (change username to rnclark)" <username@qwest.net> > wrote in <SNIP> [quoted text clipped - 10 lines] > > Steve. > This is a programming restriction because the EPSON Scan transfers RGB > information in one go rather than individually (probably a Twain > requirement). There is normally a limitation of 74Kb of data per line > of scanned data that can be transferred (hardware limitation). Tim, It seems you have the correct answer, but a buffer of only 65KB. I installed another 1 GB ram for a total of 2 gb, and there was no change in the error. I found that I could scan at 3200 ppi, 16 bits: 3.4 inches wide = 3.4*3200*48/8 = 65280 kbytes / line (WORKS) but not: 3.5 inches wide = 3.5*3200*48/8 = 67200 kbytes / line (DOES NOT WORK) Thus the line length can probably be no more than 65 kbytes. Roger > For example: > [quoted text clipped - 38 lines] >> >>Steve. SNIP > Tim, > It seems you have the correct answer, but a buffer of only 65KB. > I installed another 1 GB ram for a total of 2 gb, and there was no > change in the error. I don't recall, but have you tried VueScan? It supports my humble Epson 2450 (used mainly for document scanning) just fine, and the 4870 is also supported by VueScan. Knowing that you look for the ultimate that a given device can provide, VueScan seems to be a logical tool. Bart > SNIP > [quoted text clipped - 7 lines] > supported by VueScan. Knowing that you look for the ultimate that a given > device can provide, VueScan seems to be a logical tool. I endorse trying Vuescan. I use it with the Epson 3200 under Linux. It works fine. I haven't tried the Epson software recently. > Bart > > This is a programming restriction because the EPSON Scan transfers RGB > > information in one go rather than individually (probably a Twain > > requirement). This might be why some people using a 4870 + Vuescan (non TWAIN software) have reported they can scan larger files? Maybe my feeble mind is just not grasping the concepts presented in this thread correctly so late in the afternoon, but in theory, shouldn't you be able to scan a 4x5 at a slightly higher dpi if it is in vertical orientation instead of horizontal orientation since not as much data would be transferred through with each "step" (4 in inches wide instead of 5)? Comments from the scanner "rocket scientists" here to set me straight? :) Doug SignatureDoug's "MF Film Holder" for batch scanning "strips" of 120/220 medium format film: http://home.earthlink.net/~dougfisher/holder/mfholderintro.html >>>This is a programming restriction because the EPSON Scan transfers RGB >>>information in one go rather than individually (probably a Twain [quoted text clipped - 8 lines] > instead of horizontal orientation since not as much data would be > transferred through with each "step" (4 in inches wide instead of 5)? Yes, just that the epsong 4870 4x5 holder puts the long dimension across the scanner. But even so, it would not be enough, just frustratingly close at 3200 ppi (3.4 inches) with the epson software! Roger > Comments from the scanner "rocket scientists" here to set me straight? :) > > Doug > I found that I could scan at 3200 ppi, 16 bits: > 3.4 inches wide = 3.4*3200*48/8 = 65280 kbytes / line (WORKS) > but not: > 3.5 inches wide = 3.5*3200*48/8 = 67200 kbytes / line (DOES NOT WORK) > > Thus the line length can probably be no more than 65 kbytes. To be exact, it looks like the program has a variable limited to 2^16 (65536 or 65535 depending upon how the programmer handled it). "jjs" <nospam@please.xxx> wrote; > > I found that I could scan at 3200 ppi, 16 bits: > > 3.4 inches wide = 3.4*3200*48/8 = 65280 kbytes / line (WORKS) [quoted text clipped - 5 lines] > To be exact, it looks like the program has a variable limited to 2^16 > (65536 or 65535 depending upon how the programmer handled it). There are two different modes for reading pixels from the scanner, one reads all three colors per line, and another reads one color at a time. VueScan uses the former on the 3170 and the latter on the 4870. The limit in VueScan on the 4870 is pixel_width*bytes_per_sample <= 32752 The limit on the 3170 is bytes_per_line <= 65520 bytes. On the 4870, for 16 bits per sample, the maximum pixel width in VueScan is 16376, and at 4800 dpi this is 3.411 inches. At 8 bits per sample, this is 6.822 inches. On the 3170, for 16 bits per sample, the maximum pixel width in VueScan is 10920, and at 3200 dpi this is 3.413 inches. At 8 bits per sample, this is 6.826 inches. If the requested scan area is too wide, VueScan first tries to reduce the bits per sample to 8 bits. If this is still too wide, VueScan reduces the scan resolution one step. Regards, Ed Hamrick > There are two different modes for reading pixels from the scanner, > one reads all three colors per line, and another reads one color [quoted text clipped - 16 lines] > is still too wide, VueScan reduces the scan resolution one > step. Thanks so very much for clarifying exactly what your great program does, Ed. So there you go, folks - the authoritative source! More at http://www.hamrick.com/ > "jjs" <nospam@please.xxx> wrote; > [quoted text clipped - 19 lines] > VueScan is 16376, and at 4800 dpi this is 3.411 inches. > At 8 bits per sample, this is 6.822 inches. Ed, Suppose I choose a custom resolution on the 4870 of 3200 ppi (rather than 4800 or 2400)? How do you go about reading the pixels and storing the information? Can one scan wider than 3.411 inches at 16 bits per channel and 3200 ppi? Also, how hard would it be for you to modify the program so that 4 x 5 can be scanned completely at 4800 ppi and 16 bits per channel? At present, this would seem to be unnecessary, but hardware does tend to improve at a rapid pace, so it won't be too long before that is feasible. As usual, Roger Clark seems to be pushing the boundaries. Finally, does it make any difference whether one is operating under Windows or Linux in these matters? > On the 3170, for 16 bits per sample, the maximum pixel width > in VueScan is 10920, and at 3200 dpi this is 3.413 inches. [quoted text clipped - 7 lines] > Regards, > Ed Hamrick > Suppose I choose a custom resolution on the 4870 of 3200 ppi (rather > than 4800 or 2400)? The current implementation in VueScan is to scan at 4800 dpi and sample down once it's acquired from the scanner. This wouldn't help. > Also, how hard would it be for you to modify the program so that 4 x 5 > can be scanned completely at 4800 ppi and 16 bits per channel? It's a firmware limitation in the scanner. > Finally, does it make any difference whether one is operating under > Windows or Linux in these matters? No, this doesn't make any difference. Regards, Ed Hamrick >>Suppose I choose a custom resolution on the 4870 of 3200 ppi (rather >>than 4800 or 2400)? [quoted text clipped - 15 lines] > Regards, > Ed Hamrick All this seems to mean that you can't really use the Epson 4870 to scan 4 x 5 at 16 bits per channel and higher than 2400 ppi in one fell swoop. It would be interesting to know if it still produces better results than the Epson 3200 at 3200 ppi, which may be the case. > All this seems to mean that you can't really use the Epson 4870 to scan > 4 x 5 at 16 bits per channel and higher than 2400 ppi in one fell swoop. > It would be interesting to know if it still produces better results > than the Epson 3200 at 3200 ppi, which may be the case. If the 4870 can't do better than 2400, I wonder if the 3200 can either? Doug SignatureDoug's "MF Film Holder" for batch scanning "strips" of 120/220 medium format film: http://home.earthlink.net/~dougfisher/holder/mfholderintro.html > > All this seems to mean that you can't really use the Epson 4870 to scan > > 4 x 5 at 16 bits per channel and higher than 2400 ppi in one fell swoop. > > It would be interesting to know if it still produces better results > > than the Epson 3200 at 3200 ppi, which may be the case. > > If the 4870 can't do better than 2400, I wonder if the 3200 can either? The Epson 3200 can scan full frame 4x5 at 3200 dpi. I don't do it often any more, since I can't print a 10x enlargement to use it. The novelty quickly wore off; Photoshop is not at all responsive when manipulating half-gig plus files. SilverFast required an update to work with a scan that size. It was a quick download from their website. >>All this seems to mean that you can't really use the Epson 4870 to scan >>4 x 5 at 16 bits per channel and higher than 2400 ppi in one fell swoop. >> It would be interesting to know if it still produces better results >>than the Epson 3200 at 3200 ppi, which may be the case. > > If the 4870 can't do better than 2400, I wonder if the 3200 can either? My Epson 3200 has no trouble scanning 4 x 5 at 3200 ppi and 48 bit color depth (in portrait orientation). I guess Epson designed the firmware so that the buffer can't hold a full line about 95 mm wide. The problem with the 4870, as explained by Ed Hamrick, is that the firmware doesn't allow for a line large enough to accomodate the full width of the frame. Also, apparently you can't tell the scanner to scan at anything but 4800, 2400, ... ppi. To scan at 3200 ppi, you have to tell it to scan at 4800 ppi and then scale down to 3200 ppi. Of course, the Epson 3200 doesn't deliver 63 lp/mm, which is the theoretical maximum obtainable by scanning at 3200 ppi. It delivers about half that. So one could argue that it makes sense to scale down after scanning because that reduces file size and you don't lose much detail since it wasn't there anyway. So it is still possible that if you set the 4870 to scan at 2400 ppi, it will produce better results than the 3200 scanning at 3200 ppi and rescaled to 2400 ppi. Of course, for most purposes, 2400 ppi should be more than enough for use with 4 x 5. And also for many purposes, scanning at 24 bit color depth is adequate. Roger Clark, of course, is always pushing the envelope of what can be done, so it is not surprising he discovered these limaitations. Still it seems bizarre for Epson to design a scanner capable of scanning at 4800 ppi at 48 bit color depth and also scanning 4 x 5 but not of doing both. It couldn't cost all that much to double the size of the buffer. > Doug > So now I'm ready to scan a full size 4x5 sheet. > 4.67 x 3.70 inches at 4800 ppi, 48-bit: > I get the error > "Selected area is too large for this resolution" Since I can't see the program code, I have to guess that the image size will be larger than addressable memory (plus program size.) Do you really need 4800spi/48-bit? You can't use it with any conventional imaging software. You can't print it, either. I'd suggest you lower the bit sample to something manageable. You will always have the transparency in the future when/if digital catches up. >>So now I'm ready to scan a full size 4x5 sheet. >>4.67 x 3.70 inches at 4800 ppi, 48-bit: [quoted text clipped - 8 lines] > bit sample to something manageable. You will always have the transparency > in the future when/if digital catches up. No, I don't need 4800 ppi, but I need at least 3200 ppi, and I want 48-bit. Of course for printing the bits come down, but not the size. I've printed 4x5 at 4 x 5 FEET at 305 ppi on lightjet 500. That works out to 4*12*305 x 5*12*305 = 14,640 x 18,300 pixels = 804 mbytes. But processing at 16 bits/channel is a file size of 1.6 gbytes. Regarding the epson 4870, in tests I did yesterday, I was seeing about 50 to 60 line pairs per mm, so either I have a good unit, previous reports were with bad units, or newer units are better. My testing showed only a little difference between 3200 and 4800 dpi, but a big difference at 2400 dpi. So I need to get at least 3200 dpi at 48-bits, which gives an 800 mbyte file. I turned off ICE, but there was no difference in my error message. Shortly I'll test with 2 gbytes ram. Roger > No, I don't need 4800 ppi, but I need at least 3200 ppi, and I want > 48-bit. Of course for printing the bits come down, but not the [quoted text clipped - 10 lines] > but a big difference at 2400 dpi. So I need to get at least 3200 dpi > at 48-bits, which gives an 800 mbyte file. As I noted previously, I routinely scan 4 x 5 at 16 bits per channel and 3200 ppi, using my Epson 3200. Of course, it is not clear what the 4870 will actually do if you tell it to scan at 3200. Perhaps it scans and 4870 and downsamples somehow in software. In that case, it is quite disappointing in that it can't be used at more than 2400 ppi for 16 bits per channel. I have 1.5 Gb of ram. Let us know what you finally figure out. > I turned off ICE, but there was no difference in my error message. > Shortly I'll test with 2 gbytes ram. > > Roger The maximum scan width of the Perfection 3200 at 3200 dpi and 48 bit colour would be 4 inches assuming a 74Kb limit per scan line with the EPSON Scan driver. As the holders are the other way around in this scanner it is possible to scan 4 x 5 inch material at 3200 dpi and 48 bit colour. > > No, I don't need 4800 ppi, but I need at least 3200 ppi, and I want > > 48-bit. Of course for printing the bits come down, but not the [quoted text clipped - 26 lines] > > > > Roger >My testing showed only a little difference between 3200 and 4800 dpi, >but a big difference at 2400 dpi. So I need to get at least 3200 dpi >at 48-bits, which gives an 800 mbyte file. The alleged need for 48 bit scans has been debated often on this and many other forums, and by luminaries such as Jeff Schewe and Dan Margulis. I side with Dan. If you do the coarsest of your tonal manipulations in the scanner driver - and do them well - the resulting 24-bit file will be robust enough to withstand (or thrive on) fine tweaks later on in Photoshop. 48 bit capture simply allows you to carry noise and trash data further up the signal stream. Sooner or later you have to make tonal manipulations that pare away the useless codes and noise. IMO, the need for 48 bit capture is hugely overrated. Using 24-bit capture simply means doing the paring earlier rather than later. rafe b. http://www.terrapinphoto.com SNIP > The alleged need for 48 bit scans has been debated > often on this and many other forums, and by luminaries > such as Jeff Schewe and Dan Margulis. I side with Dan. Good for Dan ;-), but although he's a knowledgeable person, many of his views are too (CMYK) printing press oriented for my taste. If anything restricts continuous tone imaging, printing most definitely will. > If you do the coarsest of your tonal manipulations in > the scanner driver - and do them well - the resulting > 24-bit file will be robust enough to withstand (or thrive > on) fine tweaks later on in Photoshop. Possible, especially since Photoshop only uses 15-bit channels. But the issue at hand is getting the 48-bit in the first place, even before the coarsest of tonal manipulations. After that, the OP seems experienced enough to choose a workflow suiting his needs. Bart > The alleged need for 48 bit scans has been debated often > on this and many other forums, and by luminaries such as [quoted text clipped - 4 lines] > will be robust enough to withstand (or thrive on) fine tweaks > later on in Photoshop. I do scientific imaging for a living, even working with data at a signal to noise of 30,000 at times. In the astronomy world, multiple (e.g. hundreds) of 16-bit images are added together to increase signal to noise to the 10,000+ range. There is no doubt that with higher signal to noise than 8-bit you can bring out subtle detail in images not possible with 8 or even 16-bit capture. (Most capture is not 16-bit signal to noise, but when added together can exceed 16-bit; I soften work in 32-bit.) In practice, for large format work, the information one can get from any scanner software I've used leads a lot to be desired compared to working with the full resolution data in something like photoshop. Even chrome images like velvia contain more information than covered by an 8-bit range, even with appropriate gamma. For example, I reduced my need for split density filters, because I know I can keep the range I want with a good scan, and detail in the high end that one could not print with normal enlarger methods. Here is an example: http://www.clarkvision.com/galleries/gallery.landscape-1/web/c072099_L4_01a2-600 b.html The clouds would have come out white in a normal enlargement, and even with traditional dodging would have no detail. But a good scan got the information. There are no saturated pixels in the full image. While some, even many, images may be able to work well in 8-bit, I have seen and made many that I can do much better with 16-bit because one can dodge and burn select areas of the image, just like used to be done in the darkroom. E.g. read Ansel Adams "The Print." I bet Ansel would cringe at being limited to only 256 levels. I have had images that needed two 8-bit scans: one for the high to middle and one for the low to middle. Merging such scans is very difficult. With 16-bit, it becomes easier to do a better job, and I've never succeeded with large format because the task is too great. > 48 bit capture simply allows you to carry noise and trash > data further up the signal stream. Sooner or later you [quoted text clipped - 4 lines] > Using 24-bit capture simply means doing the paring > earlier rather than later. This only works if the image is flat enough that you don't need to dodge and burn much. Just my opinions... Roger Clark > rafe b. > http://www.terrapinphoto.com >While some, even many, images may be able to work well in 8-bit, >I have seen and made many that I can do much better with 16-bit [quoted text clipped - 6 lines] >With 16-bit, it becomes easier to do a better job, and I've never >succeeded with large format because the task is too great. I understand. In part, it's a matter of being "frugal" with data, in light of requirements, of course. I mostly do without selective tonal manipulations, or if I do, they're moderate. The only real "penalty" for working with 48 bit files is... well the sort of thing that's being discussed here in this thread, namely the memory, bandwidth, storage, and throughput issues that you're currently up against. rafe b. http://www.terrapinphoto.com > ... So I need to get at least 3200 dpi > at 48-bits, which gives an 800 mbyte file. 4x5 @ 3200ppi 48 bit is 1.14GB, but who's counting? Mac > > ... So I need to get at least 3200 dpi > > at 48-bits, which gives an 800 mbyte file. > > 4x5 @ 3200ppi 48 bit is 1.14GB, but who's counting? Curious - what would you do with a file that large? I regularly print 40x50 from 4-500 meg files and do not believe I am losing anything. Cheers - > > > ... So I need to get at least 3200 dpi > > > at 48-bits, which gives an 800 mbyte file. [quoted text clipped - 5 lines] > > Cheers - Well, if this were knocked down to 24 bit (which is all printers can use anyway) it would be about 550MB at same pixel dimensions. Mac Roger, Your system memory is not going to make a difference here. The restriction is: a) In the scanner itself there is a phisical limit to the information that can be captured at a specific moment, eg. 1 scan line. b) There is a software limitation on how the driver transfers this information, either one colour at a time or all at once. So the limit on the Perfection 4870 with the EPSON Twain Compliant driver is 64Kb per scan line. This equates to approximatly a 2.25 inch scan width at 4800 dpi and 48 bit colour. Ed Hamrick's VueScan can deliver a 3.411 inches inch scan width at 4800 dpi and 48 bit colour. This is because of the difference in the way each driver collects the information. EPSON will only ship Twain compliant drivers with its products, perhaps this is what dictates the way the driver is written. However we are now near the territory of drum scanners (5 inch scan widths at 4800 dpi and 48 bit colour) and this level of performance cannot really be expected from a home scanner at the price it is offered. This does not help if you need the resolution as demonstrated by your explanation. You could try scanning as two parts and stitching, but you would have to lock the exposure and be very careful not to jog the scanner between scanning the two Marquees (you can program the two jobs in one scan). Best of luck... > >>So now I'm ready to scan a full size 4x5 sheet. > >>4.67 x 3.70 inches at 4800 ppi, 48-bit: [quoted text clipped - 28 lines] > > Roger HiYa so roger ... does this mean we can expect to see an update of http://www.clarkvision.com/imagedetail/hp7400-drum_compare.html with this scanner? I've been thinking of getting a scanner for my own 4x5's and have been considering the same scanner..... See Ya (when bandwidth gets better ;-) Chris Eastwood Photographer, Programmer Motorcyclist and dingbat please remove undies for reply > HiYa > [quoted text clipped - 6 lines] > I've been thinking of getting a scanner for my own 4x5's and have been > considering the same scanner..... Yes, and the results I've gotten on the same test spot are very close to the drum scan. However, the drum was only 8-bits/channel, and I'm able to bring out more detail in the shadows with 16-bit, so in that sense, it is better than the drum scan. An update. I've scanned several 4x5s in two pieces each, at 3200 ppi and 16-bits/channel. When I laid the second half on the first it was essentially perfect in tonality and range (I used the same settings on each scan). Spatially there are 1-pixel offsets in blocks, meaning one section will be right on, and then the next section of a couple hundred lines will be offset one pixel. By carefully erasing the edge of the overlay so it is feathered and not a straight line, one can't see the 1-pixel offsets. I have vuescan, but an older copy. I'll update it and try it out. I have 9 large prints to deliver soon, so I need to get a good procedure down. The scans on the 4870 are slow. With ICE turned on, 3200 ppi, 48-bit, it takes about an hour per section, so two hours per 4x5. With ice off, it is only a few minutes. Roger > See Ya > (when bandwidth gets better ;-) [quoted text clipped - 4 lines] > > please remove undies for reply |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.