 |
 | 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 / Medium format / February 2004Best scan size for 8x10 prints?
Hello, Is there a general resolution/bit depth guideline to go by for highest quality 8x10 prints? I thought I would be real smart and test my new scanner (Nikon LS-8000) and choose the absolute maximum size & bit depth for my first roll of 6x7 film and save them as "tiff" files; well needless to say, they turned out pretty big (356 megs ea. :-), which got me to thinking, I'm never going to print anything larger than 8.5" x 11" (unless I replace my current printer) so what should I be scanning them at to ensure the best possible quality, without being totally absurd (356 meg files)? Any suggestions? Thanks! Ray >Hello, > [quoted text clipped - 9 lines] >what should I be scanning them at to ensure the best possible quality, >without being totally absurd (356 meg files)? Any suggestions? You certainly don't need the full resolution of the LS-8000 to print 8x10" prints. Heck, I made some pretty decent 8x10" prints with 18 Mbyte files from my first film scanner, way back when. On the other hand, are you absolutely, 100 percent sure you'll never print anything larger than that, ever? Scanning is a fairly laborious endeavor and I for one don't enjoy doing it for its own sake. A high res scan can be downsampled, but a low res scan can never be upsampled to yield the original detail from the film. By my calculations a scan of 6x7 cm can't be much larger than 300 Mbytes @ 4000 dpi, and that's assuming the full frame area with no cropping at all. rafe b. http://www.terrapinphoto.com Thanks again for your help! Actually, my files are even bigger than I said, I double checked and they're 565 megs each! I chose the highest bit-rate available too, which I think was 14 bits per channel, though when I look at the mode properties in Photoshop, "16 bits per channel" is checked, maybe that's why they're so much bigger than the "300 meg" you quoted, ya think? Ray ---------------------------------------------------------------------------- --------------- > >Hello, > > [quoted text clipped - 33 lines] > rafe b. > http://www.terrapinphoto.com > Thanks again for your help! Actually, my files are even bigger than I said, > I double checked and they're 565 megs each! I chose the highest bit-rate > available too, which I think was 14 bits per channel, though when I look at > the mode properties in Photoshop, "16 bits per channel" is checked, maybe > that's why they're so much bigger than the "300 meg" you quoted, ya think? That will exactly double the filesize. (14-bit occupies 16 bits, because bits are stored as bytes, and 1 byte = 8 bits) you can easily calculate the needed MB's: 8x10 inch @ 300 dpi = 2400x3000 pixels = 7.2 Mp, x3 (R, G, and B) = 21.6Mb Tiff. (8 bit) It's best to scan in 14 bit, adjust color and levels to perfection, and THEN convert to 8 bit. So, if you scan to a 14-bit 50Mb file and archive that, (or the finished 8-bit one at about 25Mb) you'll be fine for 8x10 prints. Lourens >Thanks again for your help! Actually, my files are even bigger than I said, >I double checked and they're 565 megs each! I chose the highest bit-rate >available too, which I think was 14 bits per channel, though when I look at >the mode properties in Photoshop, "16 bits per channel" is checked, maybe >that's why they're so much bigger than the "300 meg" you quoted, ya think? Yep, that's exactly what's happening. Scanning at 14 bits doubles the file size. Others have offered good advice on reducing your memory requirements. Eg., do your high bit scans, followed by the major color moves in Photoshop, followed finally by conversion of your images to 8 bit mode, which will halve their size. Also, low-compression JPG gives a lot of bang for the buck. Very minimal loss of image quality (I generally cannot see it) and a very sizeable reduction in image size, usually 50-70%. rafe b. http://www.terrapinphoto.com I understand (could be wrong, I'm not an expert) that Photoshop will show 16 bits in the mode window whenever the bits are more than 8 so the fact that 16 is checked doesn't necessarily mean it's really 16 bits, only that it's something more than 8. > >Thanks again for your help! Actually, my files are even bigger than I said, > >I double checked and they're 565 megs each! I chose the highest bit-rate [quoted text clipped - 18 lines] > rafe b. > http://www.terrapinphoto.com > I understand (could be wrong, I'm not an expert) that Photoshop will show 16 > bits in the mode window whenever the bits are more than 8 so the fact that > 16 is checked doesn't necessarily mean it's really 16 bits, only that it's > something more than 8. I rather doubt Photoshop is operating on 14-bit units. It seems more likely that use conventional word boundaries, so 16-bit it is. >I understand (could be wrong, I'm not an expert) that Photoshop will show 16 >bits in the mode window whenever the bits are more than 8 so the fact that >16 is checked doesn't necessarily mean it's really 16 bits, only that it's >something more than 8. Yep, anything above 8 bits requires a 16-bit field, since tradtional computer architectures support data sizes of either 8, 16, 32, or 64 bits. (Floating point is another story.) rafe b. http://www.terrapinphoto.com > Yep, anything above 8 bits requires a 16-bit field, > since tradtional computer architectures support > data sizes of either 8, 16, 32, or 64 bits. (Floating > point is another story.) What do you make of the 12-bit word that DEC used in their so-called DECMates? >> Yep, anything above 8 bits requires a 16-bit field, >> since tradtional computer architectures support >> data sizes of either 8, 16, 32, or 64 bits. (Floating >> point is another story.) > >What do you make of the 12-bit word that DEC used in their so-called DECMates? DEC's not in business any more, are they? <G> I've been coding micros since 1976 and every &^%$ one of them used registers & memory access that were either 8, 16, or 32 bits. I did say "traditional" architectures, didn't I? The only exception (in my experience) was the Motorola 56K DSP, which has 24/48/56 bit accumulators and internal data paths. rafe b. http://www.terrapinphoto.com > The only exception (in my experience) was the > Motorola 56K DSP, which has 24/48/56 bit accumulators > and internal data paths. Hmmm...this is going back aways (and *really* OT), but didn't Data General do something funky in their "Eagle" line? ...talk about being a geek, eh? CC >> The only exception (in my experience) was the >> Motorola 56K DSP, which has 24/48/56 bit accumulators [quoted text clipped - 4 lines] > >...talk about being a geek, eh? In the case of DSPs, very wide accumulators make some sense since the mathematical processing is often quite intense. The obvious alternative is to use floating point instead, which is in fact done natively on many DSPs. rafe b. http://www.terrapinphoto.com > > The only exception (in my experience) was the > > Motorola 56K DSP, which has 24/48/56 bit accumulators [quoted text clipped - 6 lines] > > CC From a programmer's point of view, the Eagle (officially MV8000) was an ordinary 32 bit machine. Technically it had some tricks. For example, it also supported the full 16 bit instruction set of the Eclipse, which itself had the 16 bit Nova instruction set as a subset. It was possible, because the Nova set had 2^11 instructions that either did nothing or always skipped the next instruction. The Eclipse redefined the first group, the Eagle the second. -- Lassi P.S. Tracy Kidders's book "The Soul of a New Machine" is still one of my favourites... > DEC's not in business any more, are they? <G> I still have two DECs running: one VAX and one Alpha. The VAX has been up so long that with any luck it will get loopy on the PIDs. > I've been coding micros since 1976 and every > &^%$ one of them used registers & memory > access that were either 8, 16, or 32 bits. I did > say "traditional" architectures, didn't I? I'm old enough to believe it is traditional. I think the DECMate was a PDP-8. After having coded on the PDP-11/70 the 'new' IBM PC was a travesty of errors. Just crap. >> DEC's not in business any more, are they? <G> > [quoted text clipped - 9 lines] >PDP-8. After having coded on the PDP-11/70 the 'new' IBM PC was a travesty >of errors. Just crap. Yep, a lot of the sophisticated visionaries in the industry thought the same way and yet the PC prevailed, and Vaxen are mostly dead and gone, and good riddance, IMO. It's all relative. As an undergrad, an edit- compile-execute cycle took no less than an hour and involved punch cards and card readers. If you did too many of these you got a stern lecture from the instructor about your use of CPU time. Against that background, even my very first PC (1982) seemed quite futuristic. rafe b. http://www.terrapinphoto.com [SNIP] > I've been coding micros since 1976 and every > &^%$ one of them used registers & memory [quoted text clipped - 4 lines] > Motorola 56K DSP, which has 24/48/56 bit accumulators > and internal data paths. Mmmm - Black Hardware... Peter > >I understand (could be wrong, I'm not an expert) that Photoshop will show 16 > >bits in the mode window whenever the bits are more than 8 so the fact that [quoted text clipped - 5 lines] > data sizes of either 8, 16, 32, or 64 bits. (Floating > point is another story.) Traditional computer architectures were usually multiples of 6 bits, most commonly 12 or 36, sometimes 24, or even 60 (CDC). 6 bits was good for most engineering purposes, because it was enough to represent the full alphabet, and 12 bits was the industry standard for process control. IBM was the first to use 8 bits in a major way. In business applications they needed both upper and lower case alphabets. Also telephone switches were getting digital and needed 8 bit 'octets' to represent voice amplitudes. So eventually everybody moved to 8 bit bytes. The main reason, in the end, wasn't IBM but Intel. There were still many 36 bit mainframes around, when almost all microprocessors used 8 bits. The only exceptional chip was Intersil IM6100, which used 12 bits, but it was really a PDP-8/E on CMOS. Anyway, what Photoshop shows is the storage format. It uses either one or two bytes per value. If the original source defined only 10 of the 16 bits, PS doesn't care. It processes all 16. -- Lassi > Also, low-compression JPG gives a lot of bang for the buck. > Very minimal loss of image quality (I generally cannot > see it) and a very sizeable reduction in image size, usually > 50-70%. JPG compression was designed especially to delete just the information you wouldn't see anyway. That's why it works so well. BUT (=big "but") you should only use jpg with the final product! Changing the color, sharpening, etc. of a JPG could all bring out bad jpg-effects quite quickly... certain manipulations can suddenly make the compression very visible. (=banding, artefacts, etc) Lourens > > Also, low-compression JPG gives a lot of bang for the buck. > > Very minimal loss of image quality (I generally cannot [quoted text clipped - 3 lines] > JPG compression was designed especially to delete just the information > you wouldn't see anyway. That's why it works so well. Actually, compression doesn't "delete" any information at all. It _transforms_ the representation from a position/amplitude representation to a frequence/amplitude representation. This works because photographic images are not random data: you have areas of smoothly changing color/brightness, and that sort of area can be recorded perfectly accurately in a very small number of bits. > BUT (=big "but") you should only use jpg with the final product! > Changing the color, sharpening, etc. of a JPG could all bring out bad > jpg-effects quite quickly... certain manipulations can suddenly make the > compression very visible. (=banding, artefacts, etc) If you use jpeg at settings such that the compression ratio is under 1:10, there aren't any artifacts. You may lose a tad of contrast in the highest contrast high-frequency detail, but scans don't have much of that, other than noise. David J. Littleboy Tokyo, Japan >> > Also, low-compression JPG gives a lot of bang for the buck. >> > Very minimal loss of image quality (I generally cannot [quoted text clipped - 7 lines] >_transforms_ the representation from a position/amplitude representation to >a frequence/amplitude representation. As I understand it, JPG involves transformation from RGB to YCbCr, and then decimation of the Cb and Cr data, typically 2:1 in each axis (4:1 in total data, for these two channels.) The remaining compression in JPG comes from the DCT transform, and the ability to control the bit depth of the resulting DCT output. Eg., low compression might use 8 bits, high compression might use just 4 bits -- etc. The DCT terms themselves are Huffman encoded, so that part is lossless. >This works because photographic images are not random data: you have areas >of smoothly changing color/brightness, and that sort of area can be recorded [quoted text clipped - 9 lines] >contrast high-frequency detail, but scans don't have much of that, other >than noise. There are still some artifacts due to the fact that the DCT operates on cells of 8x8 pixels. I've seen these cells even when using the very lowest-compression (highest-quality) JPG settings in Photoshop. rafe b. http://www.terrapinphoto.com > Actually, compression doesn't "delete" any information at all. compression doesn't delete information per se, but JPG compression actually *does* delete information. Lourens >>Actually, compression doesn't "delete" any information at all. > > compression doesn't delete information per se, but JPG compression > actually *does* delete information. I think that David ment to say that jpeg compression doesn't *explicitly* delete anything, but it's just a feature of it that some data will be lost when compared to the original. Meaning that the compression algorithm doesn't look at picture and go: "Hmm.. let's delete those pixels.. that part we can do without.." etc. :) You're probably arguing on semantics here.. or that's the impression I got, could be wrong, of course.. -JP >>>Actually, compression doesn't "delete" any information at all. >> [quoted text clipped - 11 lines] > >-JP JPEG transforms image data in several ways, and some of these transformations are inherently lossy and irreversible. See Sec. [75] of http://www.faqs.org/faqs/compression-faq/part2/ for a very quick summary of how JPEG works. 1. Conversion between RGB and YCbCr color spaces. Negligible loss here. 2. Optional downsampling of chroma information (the Cb and Cr channels.) IMO, this isn't a terribly serious loss. 3. DCT and inverse-DCT transform. Significant loss here, mostly affecting the image's high- frequency content. The DCT and iDCT act on 8x8 blocks of pixels, and this "blocking" of pixels is what often leads to visible artifacts. 4. Huffman encode/decode of DCT data -- lossless. The really good news about JPG is that the degree of compression is easy to control and "tune." When applied to a high resolution image with minimal compression, visible losses are really quite minimal. When applied to a 4000 dpi film scan, the losses are *almost* negligible. That said, I still keep my offline image archives in TIFF format, and leave the JPGs on my hard drive. rafe b. http://www.terrapinphoto.com > 3. DCT and inverse-DCT transform. Significant > loss here, mostly affecting the image's high- > frequency content. The DCT and iDCT act on > 8x8 blocks of pixels, and this "blocking" of pixels > is what often leads to visible artifacts. Actually, the Discrete Cosine Transform is lossless as well, since it is just a simple mathematical function that is inversible (DCT ^-1), it is the application of the quantification (not 100% sure if that is the right term) matrix on the result of the DCT that "compresses" the high frequencies and results in a loss of data and the forming of these compression artifacts. It is also the quantification matrix that determines the efficiency vs. visual quality of the compression. > That said, I still keep my offline image archives in > TIFF format, and leave the JPGs on my hard drive. As far as I am concerned, that's the only reasonable thing to do. Keeping your "originals" as jpegs or in some other lossy format would make about as much sense to me as xeroxing your negs and keeping those instead of the originals. (OK, I'm exaggerating here, but still..:) Do you compress your tiffs before archiving, and if you do, how much (approx.) space do you save by doing so? -JP > >>Actually, compression doesn't "delete" any information at all. > > [quoted text clipped - 9 lines] > You're probably arguing on semantics here.. or that's the impression I > got, could be wrong, of course.. you're probably right, and English isn't my native language so when discussions approach nit-picking level, It's getting more difficult for me. (and less interesting too...) ;-) Lourens Dear Rafe, You might be interested in knowing about a product I love, called JPEG Optimizer (at www.xat.com). This program has a function that sets the compression higher for certain parts of an image, and lower at others. If I set it at 95%, and run this function, fields of a solid color will compress more, and line areas, such as the edges of objects, will compress at the normal 95% I have set. I believe the term used before was "acutence." You might want to look into it. --- Scotty >>Thanks again for your help! Actually, my files are even bigger than I said, >>I double checked and they're 565 megs each! I chose the highest bit-rate [quoted text clipped - 18 lines] >rafe b. >http://www.terrapinphoto.com Presuming 8"x10" inkjet color print which has at best 360'dpi' and 6x7cm color negative - you want to scan at 16-bit with a sample of 1300-1400spi ('dpi') - that creates images of 3600x2880 pixels. You should get uncompressed files of about 60mb per frame. |
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.