What Is The File Size Of A Jpg From A 24 Megapixel Camera?

A few scanning tips

www.scantips.com

Menu of the other Photo and Flash pages here

Agreement File Types, Fleck Depth, & Memory Cost of Images

The RGB Colour topic was moved to its own page.

Calculators below:

Large photo images consume much retentiveness and can make our computers struggle. Uploads can be very slow. Retention cost for an epitome is computed from the prototype size. Our common 24-chip RGB image size is three bytes per pixel when uncompressed in retentivity (then 24 megapixels is x3 or 72,000,000 bytes, which is 68.7 MB uncompressed in memory, only can be smaller in a compressed file. Digital camera images today are typically much larger than most viewing or printing purposes can use (but the plentiful pixels offer advantages for largest prints or more than extreme cropping, etc).

One needed basic that shows the image size necessary to have sufficient pixels to properly print a photo is this very simple calculation:

This volition evidence the required paradigm size (pixels) to print this newspaper size at the desired dpi resolution.
Scanning Size is the same adding, more than item at end below.
File size is shown at The Four Sizes of a Digital Image below

Printing photos at 250 or 300 dpi is considered very desirable and optimum. But this dpi number does NOT need to exist exact, 10% or 15% variation won't have swell event. Just planning epitome size to have sufficient pixels to exist somewhere effectually 240 to 300 pixels per inch is a very good thing for press, called "photo quality". More than 300 dpi actually tin't help photo prints, but less than 200 dpi can suffer less image quality. It's generally near what our centre is capable of seeing, merely varies with the media. Meet a printing guideline for the resolution needed for several common purposes.

That'southward a pretty uncomplicated calculation. More pixels will work also (but slow to upload, substantially wasted try). The printer or the impress lab will simply discard the excess, but too many fewer pixels tin seriously limit the resolution and sharpness of the printed re-create.

Cropping Aspect Ratio to fit the paper size is an important concern too.

And there is a larger dpi calculator that knows about scanning, printing, and enlargement.

The memory cost for the initial default 8x10 inch color image is:

3000 x 2400 pixels x iii = 21.vi million bytes = 20.six megabytes.

The terminal "× 3" is for iii bytes of RGB color data per pixel for 24-bit color (three RGB values per pixel, which is one viii-bit byte for each RGB value, which totals 24-flake color).

Merely the compressed file will exist smaller (maybe 10% of that size for JPG), selected by our choice for JPG Quality. But the smaller it is, the worse the paradigm quality. The larger information technology is, the better the epitome quality. If uncompressed, the data is three bytes per pixel.

Data Compression and File Sizes

Image size is always dimensioned in pixels, for instance 6000x4000 pixels, or 24 megapixels.
Data and File size is dimensioned in bytes, for example, 12 megabytes (ofttimes compressed for storage).
24-chip RGB photograph data is always 3 bytes per pixel (when uncompressed for use).

Information is often compressed to smaller size for storage in the file (very radically smaller for JPG). It must be uncompressed for employ.

Lossy pinch can make minor changes in the data values. Lossy compression cannot exist used in similar Quicken, Excel or Discussion or backup software, because we insist that every byte compressed come back out exactly as information technology went into the file. Anything else is abuse. However, epitome tonal values tin be more forgiving in casual use, until it becomes excessive.

Image Data Pinch is of two types, lossless or lossy.

• Lossless compression ways we get exactly the same data back out of the file as we put into the file, as expected, no change whatsoever. TIF LZW pinch and 24-bit PNG compression are both lossless. Lossless ways the compression cannot be as constructive, the file size does not become equally tiny, only the information quality remains nonetheless pristine, totally unaffected, unchanged, no quality losses. We surely prefer that our bank account software uses lossless compression. <grin> A loftier quality image has the same concerns.
• Lossy pinch always gets dorsum the aforementioned unchanged count of pixels, but some of which might take modified or distorted color values. JPG files use lossy compression, which lets information technology be extremely efficient about reducing file size. To exist more than constructive (creating the smallest information size), lossy compression takes liberties, without greatest business organisation about not changing the data, in order to become drastically smaller. JPG is the common lossy type, simply its paradigm quality tin can be adversely affected past JPG artifacts, which the JPG Quality cistron can choose to be very balmy or drastic, but never over again to exist exactly the same original data. Mild JPG pinch is our classic standard for viewing and printing, generally no trouble as long equally it is understood and treated correctly, but but don't overdo it. For any ane epitome, Larger JPG file choices are amend quality than smaller JPG file choices. Please realize that the larger JPG is still a small file compared to lossless types. Attempts at extreme compression is not a expert programme regarding paradigm quality.

Data pinch while in the file varies data size too much for bytes to have specific significant about image size. Saying, the size of our 24 megapixel paradigm is 6000x4000 pixels. This "dimension in pixels" is the important parameter that tells usa how we tin can employ that prototype. The data size may exist 72 MB (uncompressed, or maybe 12 MB or other numbers if compressed in a JPG file), but that file size doesn't tell us anything about the image size, only nearly storage infinite or cyberspace speed. For instance, normally we have a 24-scrap colour photo image which is three bytes of data per pixel when uncompressed (one byte each of RGB data). That ways whatsoever 24 megapixel camera takes RGB images of data size 72 million bytes (the figurer below converts this to 68.7 MB, the data size earlier compression). Still, data pinch techniques tin can make this data smaller while stored in the file. In some cases drastically smaller, and maybe the 68.7 MB goes into perchance a 4 to 16 MB file if JPG compression. We can't state any verbal size numbers, because when creating the JPG file (in camera or in editor), we can select different JPG Quality settings. For this example 24 megapixel image, the JPG results might range from:

• Higher JPG Quality setting creates larger files of college image quality
  (16 MB would exist 68.7 MB / 16 MB which is iv.3:1 size ratio, very High Quality).
• Lower JPG Quality setting creates smaller files of lower paradigm quality
  (4 MB would be 68.7 MB / 4 MB which is 17:1 size ratio, much Lower Quality).
• Paradigm size (dimensions in pixels) too greatly affects information size (the 68.vii MB).
• And to some extent, the degree of image scene detail also affects compression degree.

Of course, nosotros do prefer college quality. We do our photos no favor by choosing lower JPG quality. However, emailing grandma a picture of the kids doesn't demand to be 24 megapixels. Maximum dimension of maybe 1000 pixels is reasonable for email, still big on the screen. Or even less if to a cell telephone. Even printing 5x7 inches only needs 1500x2100 pixels. But this resample should be a Copy. Never overwrite your original image.

JPG files fabricated as well small are certainly not a plus, larger is better prototype quality. Surely we desire our photographic camera images to be the all-time they can exist. Also this compressed file size naturally varies some with image content likewise. Images containing much fine detail everywhere (a tree total of pocket-size leaves) will be a trivial larger, and images with much bare featureless content (walls or bluish heaven, etc.) will exist noticeably smaller (better compressed). File sizes might vary over a 2:1 range due to extreme scene particular differences. But JPG files are typically ane/v to 1/12 of the image data size (but other extremes do exist). Both larger and smaller are possible (an optional choice fix past JPG Quality setting).

Then when the file is opened and the prototype information is uncompressed and shown, the epitome data comes back out of the file uncompressed, and original size, with the original number of bytes and pixels when open in computer retentivity. Still the aforementioned pixel counts, but JPG Quality differences affect the color accuracy of some of the pixels (prototype detail is shown by the pixel colors). Bad compression effects tin can add visible added JPG artifacts, which nosotros can learn to see.

Best Rubber Programme to Utilize JPG Images

The wise choice is to ALWAYS first annal and preserve the original pristine JPG image from the camera. When edit or resize is needed, edit the paradigm as desired, merely and so only brand some other high quality JPG file COPY to utilise (with a different file name). Never overwrite your original archived file, information technology may exist important to take later. The more important the epitome, the more than of import it is to retain a copy of the pristine original paradigm intact. There is no other way to become back.

And a second reason: Don't re-edit any JPG copy additional times, meaning if subsequent plans require yet another edit or resized image, NEVER start from that previously edited JPG file (JPG lossy compression means it already has two sets of JPG artifacts in it, from the camera and and so the first edit), so a third or fourth fourth dimension won't help that. Treat a JPG copy every bit expendable, discard information technology when done with it). START OVER from the archived unmodified original file. Because, each SAVE operation to a JPG file does the JPG compression again, on top of whatever previous Saves every bit JPG. Or, if the offset edit was extensive work (more than than just uncomplicated), you could think alee and so to as well save that work into a lossless file (TIF LZW or 24-flake PNG, which are lossless and will non add additional JPG artifacts), and also save that file equally an archive, and and then use it as a master version, and make any subsequent JPG copy from information technology. This TIF save will non remove any existing JPG artifacts in the image information, but it will not add more than.

Among the advantages of RAW images is that they don't have this antiquity concern. The original RAW epitome is always automatically preserved (and no style is provided to alter information technology). Likewise the list of by edit operations are saved, and any new edit starts with the original RAW image and merely edits the saved list of edit operations, which is then followed by only the 1 save as the JPG for use. This RAW process is called lossless editing (e'er starting from the preserved original total image).

JPG artifacts are something we all need to know about, only it takes more to bear witness this, then it was placed on its own folio.

You might reason that these first edits are of import, and any use would want them, so overwriting the original file might seem an adequate plan. Which might even sometimes be truthful, but I've been in that location and done that, but won't do it again (certainly not on whatsoever image even a scrap of import), because each relieve (as JPG) adds boosted JPG artifacts. Too my time to come plans could change, which does happen. Any important image certainly should kickoff relieve the original (certainly without cropping or resampling, since even just printing a different size print needs different dimensions). A Loftier Quality JPG save does not seem to injure much, but eventually (after repeated SAVES as JPG) you may detect that your most of import prototype has suffered damage, and then it is too late. Each Save as JPG would be i more cumulative Salvage Equally JPG, which adds additional JPG losses each time saved, and the merely mode to prevent that is to not do it, and to instead go back to the unmodified original file, if you nonetheless have information technology. Plan to keep it safe. The best insurance is to preserve your original prototype (and go on a backup likewise, on a different disk drive).

An alternative plan for of import images is to e'er save your archived edits as TIF LZW or as 24-bit PNG for photos (Non 8-bit PNG, which is for graphics), which are larger files but are lossless compression, and so no business organization about image quality due to compression. Practice realize that even press, or printing a different size, surely volition require a different crop to fit paper shape and some other JPG save. Edit and save TIF LZW or 24-flake PNG at will, all you please (but still preserving your original file of course). Yet, realize that saving an existing JPG equally TIF or PNG merely retains all of the original JPG artifacts also. And so at the end, annal it, just make 1 final high quality JPG copy of it to be used out in the world. When and if you need additional modify, discard that JPG as expendable, and start from your archived lossless file, and finally make a replacement JPG. The idea is that the image but suffers ii JPG compressions, the original 1 in the camera, and this last i subsequently the edits. Both should of course use HIGH JPG QUALITY.

So do plan ahead, there is no going back. The more important the image, the more than you need to think this out. Don't brainstorm by messing up your only original image. After you have "been there, and done that", this idea volition get very of import to you. One advantage of using Raw files is that information technology makes this stride mandatory and easy (lossless edits, but Raw also has other bigger advantages).

Photo programs differ in how they describe JPG Quality. The software has options most how it is done, and Quality 100 is arbitrary (Not a percentage of annihilation), and it NEVER means 100% Quality. It is e'er JPG. Only Maximum JPG Quality at 100, and even Quality of xc (or ix on a ten scale) should be pretty decent. I ordinarily utilize Adobe Quality 9 for JPG pictures to be printed, as "practiced enough". Spider web pictures usually are less quality, because file size is so important on the web, and they are only glanced at 1 fourth dimension.

xiii MB JPG from 68.7 MB data would be 19% original size (~1/v), and we'd expect fine quality (not exactly perfect, but extremely adequate, hard to fault).

6 MB JPG from 68.7 MB would be compression to eight% size (~i/12), and nosotros would Not expect best quality. Perchance adequate for some casual uses, similar for the internet, but anything smaller would likely exist bad news.

Compromising small, down towards one/10 size (10%) might be a typical and reasonable file size for JPG, except when we might prefer meliorate results. We should realize also, that images with much blank characterless areas like sky or blank polish walls tin shrink exceptionally well, less than 10%, which that is Non an upshot itself, but a number similar 10% is just a very vague specification. File size is non the final criteria, nosotros have to judge how the picture looks. Nosotros can learn to meet and gauge JPG artifacts. We would prefer non to see any of them in our images.

Simply there are downsides with JPG, because information technology is lossy compression, and prototype quality can be lost (not recoverable). The simply way to recover is to discard the bad JPG copy and starting time over again from the pristine original camera image. Selecting college JPG Quality is better prototype quality but a larger file size. Lower JPG Quality is a smaller file, only lower image quality. Don't cut off your nose to spite your face up. Large is Good regarding JPG, the big i is still small-scale. File size may affair when the file is stored, but image quality is important when nosotros wait at the image. Lower JPG quality causes JPG artifacts (lossy compression) which means the pixels may not all withal exist the same original color (prototype quality suffers from visible artifacts). There are the same original number of bytes and pixels when opened, but the original image quality may not be retained if JPG compression was likewise great. Most other types of file compression (including PNG and GIF and TIF LZW) are lossless, never whatever issue, but while impressive, they are not as dramatically effective (both vary profoundly, peradventure 70% size instead of 10% size).

How many bytes? There are four sizes of a digital image.

Prototype Size is dimensioned in pixels, which is what determines how the image might exist suitably used. The Commencement numbers you need to know about using a digital image is its dimensions in pixels (and the image size viewed on the monitor screen is still dimensioned in pixels).

Data Size is its uncompressed size in bytes when the file is opened into computer retention.

File Size is its size in bytes in a disk file (which is Not a meaningful number regarding how the image might be used. Image size is in pixels). Data compression (such as JPG) can reduce the file size drastically, simply image size and data size remain the original same.

Print Size is its size when printed on newspaper (inches or mm). The size of moving picture is also inches or mm. Sensor size or film size must be enlarged to the print or viewing size.

Once again, image size on a monitor screen is still dimensioned in pixels (print paper is dimensioned in inches or mm, but screens are dimensioned in pixels). If the image size is larger than the screen size, we normally are shown a temporary resampled smaller copy of more suitable smaller size.

The usual and nigh common type of color image (such every bit any JPG file) is the 24-bit RGB choice.

Calculate the Four Sizes of an Image
Specify prototype size with one of these ii options:
Image Size	x pixels
Megapixels   and Aspect Ratio
Data Type
Add estimated Exif size (optional)		Bytes KB
If Printed at	pixels per inch
Epitome Size
Information Size
File Size
Print Size

Disclaimer: Image Size is the actual size of binary image, in pixels. Data Size is the uncompressed information bytes for the image pixels when the file is opened into computer memory. These parts are known and simple, but there are also other factors.

• File Size varies with degree of data pinch. The computed file sizes hither tin can't exist precise, but just are crude i-size-fits-all guesses, since compression varies with mode, type, bit depth, and scene detail. It is ballpark, and no guarantees are offered. The limited purpose here is just to offering some relative values. Whatever pocket-size variation does not spoil the concept intended.
• File size also very slightly depends on Exif size, which varies, I take seen from zero to 23 KB (which is tiny compared to megabytes). Exif size depends on the source of the file, which varies. Also Adobe "Save For Web" option removes Exif that may have existed. Indexed files include the palette size but GIF files don't take Exif. PNG does not formally have Exif, simply such information can be unremarkably added past several apps. Many Raw files are internally TIF files with the raw data in the Exif section. And so it gets complicated, but Exif is relatively small. Y'all tin can add together an expected Exif size if known, but it won't make much divergence. The Exif default here is 6 KB, which is only 0.0059 megabytes (a MB conversion calculator below). You can enter 0 if desired.

  As examples, the JPG file from my Nikon D800 DSLR is 23300 bytes of Exif (as reported by ExifTool). But then a Photoshop edit Salve Equally JPG removes much, reducing it to about half size, or "Save For Web" reduces it to nil. Raw does non report Exif size, but bold information technology is likely about same data as in a JPG in aforementioned camera. A small Canon compact (ELPH) JPG Exif is 12300 bytes. An iPhone 4S JPG Exif is 14050 bytes and a iPhone 5S is 12278 bytes. I've seen Exif in TIFs and PNG created in Photoshop vary from two KB to 9 KB which values seemed affected past indexed bit depth for no credible reason (information appeared the same, with dissimilar numbers). Peradventure adding 12 KB or more for Exif is reasonable for cameras, but maybe 6 KB for editor files? Exif might add from 0 to 25 KB or so... but which is still inappreciably noticeable in megabytes.

• The size of the embedded JPG in Raw files is added, based on my Nikon DSLR, which adds a full size only low quality JPG (computed every bit xx:i size, which agrees) to raw files, but some cameras add a JPG prototype smaller than total size into their Raw files. This embedded JPG has the photographic camera settings candy into it (White Balance, contrast, etc), simply the Raw data does Not. The embedded JPG is used to show the RGB preview on the camera rear LCD, and as well to compute and show the RGB histogram shown in the camera, but information technology does non otherwise touch the raw file.

Note that uncompressed 24-bit RGB information is ever three bytes per pixel, regardless of image size. Color data in JPG files is 24-scrap RGB. For example, an uncompressed 24 megapixel 6000x4000 pixel image is 6000x4000 x three = 72 million bytes, also 24 10 iii, every time. That is its actual size in estimator memory bytes when the file is opened. Fill in your own numbers, merely converting to MB units is bytes divided by 1048576 (or only split by 1024 twice) which converts units to 68.66 megabytes. The JPG files will vary in size, because JPG compression degree varies with scene item level, and with the proper JPG Quality factor specified when writing the JPG.

Speaking of scene size variations, if you take several dozen JPG images from widely assorted random scenes, in one binder (but specifically, all written from ane source at the same image size with same JPG settings), and then sorted by size, the largest and smallest file might oft vary by two:1 file size (perhaps much more for extremes). Smoothen areas of featureless detail (cloudless sky, smoothen walls, etc) compress significantly smaller than a scene full of highly detailed areas (similar many trees or many tree leaves for example). If a JPG in this 24 megapixel example is say 12.vii MB size, then (ignoring small Exif) it is 12.7 MB / 68.66 MB = 18.5% size of uncompressed, which is ane/0.185 = 5.4 : 1 size reduction. That would be a high quality JPG. But JPG file size does besides vary with the degree of scene item, then file size is not a hard answer of quality. Meet a sample of this JPG size variation. Encounter more than detail nigh pixels.

Compatible File Types

Unlike colour modes have different size information values, every bit shown.

Image Type	Bytes per pixel	Possible color combinations	Compatible File Types
1-bit Line art	1/eight byte per pixel	2 colors, 1 bit per pixel. One ink on white paper	TIF, PNG, GIF
8-bit Indexed Colour	Up to 1 byte per pixel if 256 colors	256 colors maximum. For graphics use today	TIF, PNG, GIF
viii-bit Grayscale	i byte per pixel	256 shades of gray	Lossy: JPG Lossless:   TIF, PNG
xvi-bit Grayscale	2 bytes per pixel	65636 shades of gray	TIF, PNG
24-bit RGB (8-flake manner)	3 bytes per pixel (one byte each for R, G, B)	Computes 16.77 meg colors max. 24-bits is the "Norm" for photo images, e.thousand., JPG	Lossy: JPG Lossless:   TIF, PNG
32-flake CMYK	4 bytes per pixel, for Prepress	Cyan, Magneta, Yellow and Black ink, typically in halftones	TIF
48-flake RGB (16-bit mode)	vi bytes per pixel	two.81 trillion colors max. Except nosotros don't have sixteen-chip display devices	TIF, PNG

The number of colour combinations are the "maximum possible" computed. The human centre is express, and might be able to distinguish one to 3 million of the 16.77 million possible in 24-bit color. A typical real photo image might have virtually 100K to 400K unique colors used.

A few notes:

• JPG files are limited to only 24-scrap RGB color or viii-bit grayscale. JPG is radically different than most, using a lossy pinch which at extremes can be very modest but too detrimental to image quality if we overdo it. A larger file with a better JPG Quality setting is the best photo prototype. Surely the almost popular image file, most digital photographic camera images and web page images are JPG. Many one hour photo printing shops merely accept JPG files. Just practise not overdo the size reduction. The largest loftier quality JPG paradigm is still a rather pocket-sized file, compared to others.
• GIF files were designed past CompuServe for early 8-bit video monitors when small-scale file size was important for speed of punch up modems, all earlier 24-chip colour or JPG was pop (and now 24-bit colour is very superior for photo images). Since the image resolution number (dpi) is Not used by video monitors, information technology is not stored in GIF files, therefore making GIF less suitable for printing purposes. GIF is at most one byte per pixel, and is intended for indexed color, such as graphics, simply 8-scrap grayscale will too fit. GIF uses lossless compression.
• PNG files are versatile (multi-purpose), and could be considered a GIF replacement. Two main modes: 8-bit PNG manner (PNG8) is intended for indexed color, comparable uses every bit GIF files (simply with additions). Otherwise PNG can be 24-bit or 48-bit RGB color, or 8 or 16-bit grayscale, comparable to TIF for those. PNG uses lossless compression, often a chip smaller file than GIF or TIF LZW, but tin exist slightly slower to open up and decompress.
• TIF files are the nearly versatile in a few ways (different image types RGB, CMYK prepress, YCbCr, Halftones, CIE L*a*b*), and surely we could say popular with the more than serious users (but not uniform in web browsers). Generally used for lossless data, both photo and for scanned text certificate archival. LZW compression is used for photos, and documents unremarkably use ITU G3 or G4 compression (including fax is line art in TIFF format). Technically TIF allows designers to invent whatever new format in TIF format, but then it is just compatible for their intended use with their software. Some Raw files are in that category. Technically, TIF can besides back up JPG compression, offered by Photoshop, but those files would exist incompatible with most users.
• Raw files are 12 or 14 bits per pixel (less than ii bytes per pixel), and are oft besides compressed. Raw images are not directly viewable (our monitors prove RGB). Nosotros see a RGB conversion while processing raw (typically correcting white balance and perhaps exposure), and then a RGB file is output, often a JPG file. If additional edit is needed afterwards, we discard that JPG file as expendable, and use the raw process to add together any boosted edit, and output a good replacement JPG file.

A few features of common file types
File Property	JPG	TIF	PNG	GIF
Web pages can prove it	Yes		Yeah	Yes
Uncompressed option		Yes
Lossy compression	Yes
Lossless compression		Yes	Yes	Yep
Grayscale	Yep	Yep	Yes	Yes
RGB color	Yes	Aye	Yep
8-bit color (24-bit data)	Yes	Aye	Yes
xvi-chip color (48-bits)		Yep	Yes
CMYK or LAB color		Yes
Indexed colour option		Yes	Yes	Yes
Transparency selection			Aye	Yes
Animation option				Yeah

eight-bits: Every bit is common practise, there are often multiple definitions used for the same words, with dissimilar meanings: 8-bits is one of those.

In RGB images - 8-bit "mode" means 3 viii-chip channels of RGB data, as well chosen 24-bit "color depth" information. This is three 8-bit channels, 1 byte for each of the R or Grand or B components, which is three bytes per pixel, 24-flake color, and up to 16.7 million possible color combinations (256 x 256 ten 256). Our monitors or printers are viii-bit devices, significant 24-bit color. 24-bits is very expert for photos.

In Grayscale images (B&West photos), the pixel values are 1 aqueduct of viii-chip data, of single numbers representing a shade of grey from black (0) to white (255).

Indexed colour: Typically used for graphics containing relatively few colors (similar simply 4 or viii colors). All GIF and PNG8 files are indexed color, and indexed is an choice in TIF. These indexed files include a colour palette (is just a listing of the actual RGB colors). An 8-scrap index is 2⁸ = 256 values of 0..255, which indexes into a 256 color palette. Or a iii-bit alphabetize is 2³ = 8 values of 0..7, which indexes into an 8 color palette. The actual pixel data is this index number into that limited palette of colors. For case, the pixels data might say "apply color number 3", and then the pixel color comes from the palette colour number iii, which could be any 24-bit RGB colour stored there. The editor creating the indexed file rounds all paradigm colors into the closest values of but this limited number of possible palette values. The indexed pixel data is nearly commonly still one byte per pixel before compression, but if the bytes only incorporate these pocket-sized index numbers for say 4-bit 16 colors, compression (lossless) tin can do crawly size reductions in the file. Existence limited to merely 256 colors is not good for photo images, which normally incorporate 100K to 400K colors, but 8 or sixteen colors is a very small file and very suitable for a graphics of just a few colors. More on Indexed color.

8-bit colour was in common apply before our current 24-chip color hardware became available. A note from history, we might still meet one-time mentions of "web safe colors". This wasn't nigh security, this standard was back in the day when our 8-scrap monitors could but bear witness the few indexed colors. The "web rubber" palette was six shades of each R,G,B (216), plus 40 system colors the OS might use. These colors would be rendered correctly, any others were just nearest friction match. "Spider web-prophylactic" is obsolete now, every RGB color is "prophylactic" for 24-bit color systems today.

Line Art (too chosen Bilevel) is two colors, unremarkably black ink dots on white paper (the printing printing could utilise a dissimilar colour of ink or paper, simply your home printer will only utilise blackness ink). Line art is packed bits and is not indexed (and is non the aforementioned as two colour Indexed, which can be any two colors from a palette, and indexed uncompressed is still 1 byte per pixel, but pinch is very efficient on the smaller values). Scanners accept three standard scan modes, Line art, Grayscale, or Colour mode (they may phone call it these names, or some (HP) may call them B&W way and B&W Photo mode and Color, aforementioned matter. Line fine art is the smallest, simplest, oldest paradigm type, 1 bit per pixel, which each pixel is just either a 0 or 1 information. Examples are that fax is line art, sheet music would be all-time equally line art, and printed text pages are ordinarily all-time scanned as line art mode (except for whatsoever photograph images on the same page). The name comes from line drawings such as newspaper cartoons which are commonly line art (possibly color is added today inside the black lines, similar a kids coloring book). We routinely scan color work at 300 dpi, only line art is sharper lines if created at 600 dpi, or possibly even 1200 dpi if you lot accept some way to print that (that works because it's only one ink, there are no color dots that have to exist dithered). Nonetheless, line art makes very pocket-size files (especially if compressed). Line art is great stuff when applicable, the obvious offset choice for these special cases. Line fine art mode in Photoshop is cleverly reached at Image - Fashion - BitMap, where it won't say line art, but line art is created past selecting 50% Threshold in that location in BitMap (which has to already exist a grayscale epitome to reach BitMap). BitMap at that place is actually for halftones, except selecting 50% Threshold there ways all tones darker than center will simply be black, and all tones lighter than eye will be white, which is line art. Two colors, blackness and white (fifty% threshold) means all tones darker than centre will simply be black, and all tones lighter than middle will be white, which is line art. Two colors, black and white.

1 MB is a little more Than I Million Bytes

The retentiveness size of images is often shown in megabytes. You lot may notice a trivial discrepancy from the number you summate from pixels with WxHx3 bytes. This is because (every bit regarding memory sizes) "megabytes" and "millions of bytes" are not quite the same units.

Memory sizes in terms like KB, MB, GB, and TB count in units of 1024 bytes for i One thousand, whereas humans count thousands in units of 1000.

A million is 1000x1000 = 1,000,000, powers of 10, or 10⁶. Only binary units are used for memory sizes, powers of 2, where one kilobyte is 1024 bytes, and a one megabyte is 1024x1024 = 1,048,576 bytes, or 2²⁰. So a number like 10 meg bytes is x,000,000 / (1024x1024) = 9.54 megabytes. One binary megabyte holds iv.86% (1024×1024/1000000) more bytes than one one thousand thousand, and then there are 4.86% fewer megabytes than millions.

Understanding KB, MB, GB, TB Size Units of Memory Chips

Blazon a value somewhere hither, and click its Units push button, to catechumen the other Unit of measurement equivalences.

If changing mode between 1024 (2²⁰) and thou (10ⁱⁱⁱ) units, information technology volition retain and apply the previous K, KB, MB, GB or TB pick.

If yous might see a format similar an "east-vii" in a consequence, it but means to move the decimal signal 7 places to the left (or eastward+7, move to right). Example: nine.53e-vii is 0.000000953

Whatsoever computed fractional bytes are rounded to whole bytes. In binary fashion, each line in the calculator is 1024 times the line below it (powers of 2). Which is binary, and is how memory computes byte addresses. Yet humans ordinarily use g units for their stuff (powers of ten). To exist very articulate:

Binary powers of 2 are 1, 2, four, 8, 16, 32, 64, 128, 256, 512, 1024 ... which is two to the ability of 0, ane, 2, 3, iv, 5, etc.

Digital powers of x are i, 10, 100, g, 10000, 100000 ... which is 10 to the power of 0, 1, two, iii, iv, 5, etc.

Specifically, megapixels and the GB or TB difficult disk drive we purchase are correctly dimensioned in yard units, and a 500 GB drive is correctly 500,000,000,000 bytes. However when we format the drive, when Windows then shows 1024 units, calling it 465.7 GB - but which is exactly the same bytes either manner. Memory fries (including SSD and camera cards and USB sticks) necessarily use 1024 units. File sizes do not need 1024 units, withal it has been mutual practice anyway. Windows may testify file size either mode, depending on location (Windows File Explorer normally shows binary KB, but Cmd DIR shows actual decimal bytes).

Convert with direct math
From\To	B	KB	MB	GB	TB
B	-	/1024	/1024 2 times	/1024 3 times	/1024 4 times
KB	x1024	-	/1024	/1024 two times	/1024 3 times
MB	x1024 2 times	x1024	-	/1024	/1024 ii times
GB	x1024 3 times	x1024 ii times	x1024	-	/1024
TB	x1024 iv times	x1024 3 times	x1024 2 times	x1024	-

The math is easy to do directly. Conversion goes from left to right in the table. If you want to convert bytes to MB, Bytes to MB is two steps correct in the list (B, KB, MB, GB, TB), so just divide bytes by 1024 twice to get MB. Or divide three times for GB.

Example:
3 GB = 3×1024×1024 = 3,145,728 KB
( x 1024 ii times for GB to KB)

We as well see units of Mb as a rate of bandwidth. Small b is bits, as in Mb/second of bandwidth. Capital B is bytes of data, equally in MB size. Bandwidth uses digital units, powers of 10. There are Eight bits per byte, then Mb = MB ten viii.

Well-nigh Megabyte and Megapixel numbers

Humans count in decimal units of x or g (which is 10³), but binary units are of ii or 1024 (which is two¹⁰). Binary units are necessarily used for retentiveness chips, including SSD and flash drives. These are unlike numbers.

Because every memory scrap address line to select a byte tin have two values, 0 and i, therefore scrap hardware retention Total byte count must be a power of two, for example ii, iv, viii xvi, 32, 64, 128, 512, 1024, etc, etc.) Merely and then reckoner operating systems arbitrarily got the notion to also use 1024 units for file sizes, but it is not necessary for file sizes, and information technology just confuses virtually humans. :)   But all other human counting uses normal decimal chiliad units (powers of 10 instead of binary 2).

Specifically, specifications for megapixels in digital images, and hard disk drive size in gigabytes are both correctly advertised equally multiples of decimal thousands... millions are 1000x1000. Or giga is 1000x1000x1000. Same way as humans count. The calculator offers a mode for units of m to make the point about the divergence. That thousand is a smaller unit of measurement than 1024, therefore in that location are fewer memory units of KB, MB and GB, each of which holds a more bytes. The aforementioned amount of bytes just have unlike counting units. Thousands is only how humans count (in powers of 10) — and meg IS THE DEFINITION of Mega.

Nevertheless, after formatting the disk, the computer operating system has notions to count information technology in binary GB units. There's no good reason for doing that on difficult drives, it is merely a complication. The deejay manufacturer did annunciate the size correctly every bit decimal (like humans count), and formatting does NOT brand the disk smaller, the computer but changes the units (in figurer lingo, 1K became counted as 1024 bytes instead of 1000 bytes). So the size is a smaller number when said in the larger binary GB unit than in the decimal GB unit of measurement. This is why we buy a 500 GB hd drive (sold as 1000's, the actual existent count, the decimal style humans count), and it does hateful exactly 500,000,000,000 bytes (500 billion), and we do get them all. Merely then we format information technology, so we meet information technology said to exist 465 gigabytes of binary file space (using units of 1024). Both numbering systems are precisely numerically correct in their ain style.

An actual 2 TB disk is sold equally 2,000,000,000,000 decimal bytes (two trillion), but the exact same number of bytes becomes shown as 1.819 TB binary when formatted in the reckoner operating system. Still same exact number of bytes either manner. But users who don't empathise this numbering system switch might assume the disk manufacturer cheated them somehow. Instead, no, not at all, you got the honest count. The disk merely counted in 2,000,000,000,000 decimal, same fashion equally we humans count. No law-breaking in that, tetra does in fact mean trillion (x¹²), and nosotros do count in decimal (powers of 10 instead of 2). It is the operating system that confuses united states of america, calling tetra units something different, as powers of ii (two^twoscore is approximately 1.1 trillion).

So over again, note that a ii TB deejay drive does really accept 2,000,000,000,000 bytes (digital count). Simply instead, the operating system converts it to specify it as 1.819 TB (binary, only information technology really does take 2 TB of bytes, two,000,000,000,000, in the style humans count in powers of 10). Powers of x is likewise true of camera megapixels, which as well have no demand to use the binary counting system (megapixels are NOT binary powers of 2). So xx megapixels is really the truthful xx,000,000 pixels. Megapixels are NOT in binary units.

So kilo, mega, giga and tera terms were defined every bit powers of 10, but were corrupted to have ii meanings. Computers used those existing terms with different meanings for retentivity sizes. Retention chips necessarily must utilize the binary counting organisation, but it is non necessary for hard disks or disk files (even if the operating organization insists on information technology anyway). The meaning of the Mega, Kilo, Giga and Tera prefixes does and e'er has meant decimal units of 1000. And with the goal to preserve their bodily decimal meanings, new international SI units Ki and Mi and Gi were divers in 1998 for the binary ability units, simply they have not caught on, and seem very unused. So, this is nevertheless a complication today. Memory chips are binary, but there is admittedly no reason why our computer operating system notwithstanding does this regarding file sizes. Humans count in decimal powers of 10, including megapixels, and besides the difficult disk manufacturers counting bytes.

Still, Memory chips (besides including SSD and camera memory cards and USB flash sticks, which are all memory chips) are dissimilar, and their construction requires using binary kilobytes (counting in 1024 units) or megabytes (1024x1024) or gigabytes (1024x1024x1024). This is because each added address line exactly doubles size (powers of two). Instance, iv address lines is a four-bit number counting upwardly to 1111 binary, which is 15 decimal, which therefore can accost sixteen bytes of retentiveness (0 to 15). Or viii-bits counts 256 values, or 16-bits addresses 65536 bytes. And then if the memory fleck has Northward address lines, it necessarily provides 2^N bytes of memory. That's why memory size is dimensioned in units of 1024 bytes for what we telephone call a 1K step. When two of these 1K chips are connected together, the program is that they count up to 2x or 2048 bytes. But if each implemented only m bytes, that leaves a missing 24 byte gap between them, when memory addressing would neglect.

And then there are adept necessary technical reasons for memory fries to use binary numbers, because each address bit is a ability of 2 — the sequence 1, ii, 4, eight, sixteen, 32, 64, 128, 256, 512, 1024, makes it exist extremely impractical (simply unthinkable) to build a thousand byte memory chip in a chip that counts to 1024 multiples. Information technology only would not come out even. The binary address lines count 0 to 1023, so it is necessary to add together the other 24 bytes to fill it up. Past totally filling the retention chip address lines, we tin can connect a few chips in serial and have continuous larger memory. However, leaving whatsoever gaps in the addressing would totally ruin information technology (only unusable bad byte values there), so it is never done (unthinkable).

In the early on days, memory chips were very small, and it was a concern if they could concord a the size of one specific file. Describing these files in binary terms to friction match the memory flake was useful so to know if information technology would fit. However there is no expert reason for file sizes in binary today. Files are just a sequential string of bytes, which can be whatever full number. But retention chip size must be a binary ability of ii, to lucifer the address lines. The memory chip arrays today probable hold gigabytes and thousands of any files. So it is at present unimportant to know an verbal binary count in a file whatsoever more than, and counting them in binary is an useless complexity now. Even so, the operating system counting in binary 1024 units is still commonly notwithstanding done on files too. If we did have a file of actual size exactly 200,000 bytes (base 10), the calculator operating system volition phone call information technology 195.3 KB (base ii).

In base ten, we know the largest numeric value we can represent in 3 digits is 999. That's nine + 90 + 900 = 999. When we count by tens, g requires 4 digits, ten³ = 1000, which is one more than three digits can agree. Binary base of operations 2 works the aforementioned way, the largest number possible in 8-bits is 255, because two⁸ = 256 (which is 9 $.25). So one + 2 + 4 + viii + 16 + 32 + 64 + 128 = 255. And 16-bits tin incorporate addresses 0..65535. 2¹⁶ = 65536 is one more than 16-$.25 tin can address.

Units of ten or yard are extremely handy for humans, we tin can catechumen KB and MB and GB in our head, by only moving the decimal point. Units of 1024 are not so like shooting fish in a barrel, but information technology came about in the calculator early days dorsum when 1024 bytes was a pretty large scrap. Historically, we had to count bytes precisely to ensure the data would fit into the chip, and the 1024 number was quite important for programmers. Non still true today, fries are huge, and exact counts are unimportant now. Hard drives dimension size in units of 1000, but our operating systems still like to convert file sizes to 1024 units. In that location is no valid reason why today...

Only every bit a computer developer, back in the day decades ago, I had the job of modifying a computer'southward boot loader in a 256 byte PROM (one/4 of 1K binary). It was used with 8080 fries in mill test stations that booted from a console cassette tape, and I had to add an option for booting from a cardinal computer disk if it was present. I added the code, only then it was too large. After my best tries, the two methods were yet 257 bytes, just one byte too large to fit in the 256 byte PROM fleck. It took some dirty tricks to make it fit and work. Then memory size was very of import in the earliest days (of tiny memory chips), simply today, our computers take several GB of retentiveness and maybe terabytes of disk storage, and the exact precise file sizes really matter trivial. Interesting color, at least for me. :)

The definition of the unit prefix "Mega" absolutely has always meant millions (decimal factors of 1000x1000) — and it still does mean units of chiliad, it does Non mean 1024 units (except information technology is of grade used that mode likewise). Considering memory chips are necessarily dimensioned in binary units (factors of 1024), and they simply incorrectly appropriated the terms kilo and mega, years ago... so that'due south special, but nosotros do use information technology that way. In the early days, when memory fries were tiny, it was useful to think of file sizes in binary, when they had to fit. Since then though, chips have become huge, and files can be relatively huge besides, and we don't sweat a few bytes now.

Note that you lot may see different numbers in different units for the aforementioned file size dimension:

• Photo editors usually testify prototype information size in binary units, either KB (uncompressed bytes divided by 1024) or MB (bytes divided by 1024 twice, for KB and for MB). Some editors (Irfanview) bear witness both size numbers, the binary representation and bodily decimal byte count.

  

  Photoshop Image Size shows it this way: the 68.vii Grand at the top is 68.vii MB information size (uncompressed, when open in retention). Shown is 6000 x 4000 x 3 (iii bytes per pixel for normal 24-bit RGB color) = 72 million bytes, simply 72,000,000 / (1024 x 1024) = 68.7 MB uncompressed data size in memory. You lot might think of it equally becoming a compressed 12 MB JPG file, every bit image files are normally compressed in some fashion (lossless or lossy), so the file on disk is likely smaller than the image data size.

  The numbers nosotros need to know is the epitome size in pixels. Then epitome size in bytes is (width in pixels) x (elevation in pixels) and and so x 3 (for iii bytes per pixel, if normal 24-bit color). That is the existent decimal data size in bytes. And then for binary numbers for bytes, then divided by 1024 bytes for KB, or divided by 1024 bytes twice for MB. After that, you lot tin can go back to real decimal byte count by multiplying by 1.024 (once for KB, or twice for MB, or three times for GB).

• The Windows Explorer shows the file size in units of KB (bytes divided by 1024 once).
• The Windows command line DIR command shows exact decimal file size in bytes. The operating system records file size in decimal bytes, but it tends to evidence humans the value in binary KB or MB. I cannot imagine any reason why that convention is continued today.
• Right clicking the file in the Windows Explorer (file explorer) and selecting Properties volition show size in KB or MB, and too in bodily bytes. Two sizes are shown, the actual file size, and the binary size. Space on the disk is allocated in clusters (probably 4096 byte units for NTFS today). Binary math can simply shift powers of 2 instead of much slower divide and multiply, merely it could exist hidden from humans inquiring file size.

---

Scanning Size calculator

In that location is a larger dpi figurer that knows about scanning, printing, and enlargement.

Scanning whatsoever 6x4 inch photograph volition occupy the amounts of retentiveness shown in the table below. I hope you realize that extreme resolution apace becomes incommunicable.

You may enter some other resolution and scan size here, and it volition as well exist calculated on the last line of the nautical chart beneath. Seeing a upshot of NaN ways that some input was Not a Number.

When people enquire how to fix memory errors when scanning photos or documents at 9600 dpi, the reply is "don't do that" if you don't have 8 gigabytes of memory, and a 9600 dpi scanner, and take a special reason. It is normally correct to browse at 300 dpi to reprint at original size (600 dpi can assistance line fine art scans, only usually not if colour or grayscale photos).

Saying that once again: (is about a common first time fault)

Scanning a 35 mm slide to print at 8x10 inches is very roughly 9x enlargement (judge, allowing for very slight cropping).
The goal is that to print 8x10 inches at 300 dpi needs 2400x3000 pixels.
Two scanning methods piece of work. Both examples here volition scan at 2700 dpi:

The scan Input size is the 35 mm motion picture size. The Output size is the print 8x10 inches.
You marker the Input size on the scanner preview with the mouse.

• Y'all can gear up scanner Input picture show size and at 100% scale at 9x 300 = 2700 dpi. However, the 35mm motion picture is attribute ratio 3:2 and the 8x10 print newspaper is aspect ratio 4:5, so the prototype will accept to exist cropped to lucifer the newspaper shape. Either ingather it hither in the scanner Input size, or you can crop it subsequently. See an easy procedure to crop an prototype to match the paper shape. Cropping later usually offers more choices.

  Scanning 35 mm film at 2700 dpi at scale factor 100% comes out fix to print picture show size at 2700 dpi, simply this is trivially scaled at impress time to print 300 dpi 8x10 size (assuming the aspect ratio has been fix to match the paper).

• Browse the 35 mm film by either setting the scanner to desired 8x10 inch Output impress size at 300 dpi (which the Input will and then show scale gene of about 900%). If you specify Output size every bit 8x10 inches, the scanner will ingather to match the 8x10 paper shape.

  Scanning 8x10 inch Output at 300 dpi comes out already scaled to 300 dpi, to print 8x10 directly at dwelling house.

The pixels are the same either fashion (A or B), nigh 2400 ten 3000 pixels. If sending it out with instruction to print 8x10, it will be 8x10 either way. You lot do demand sufficient pixels (reasonably shut), but it need non be precisely 300 dpi, most shops will probably print at 250 dpi anyway.

There are two points hither:

• Think of the scanner resolution field dpi equally applying to the Output printing resolution. If the calibration factor is 100%, and then it is also equal to the scanning resolution, which is the common practice of planning to print an original size re-create. If not 100%, then scanning resolution is the dpi entered ten scaling factor ... 300 dpi at 900% scale is 9x or 2700 dpi scanning resolution, creating enough pixels that the Output will print 9x size at 300 dpi.
• You admittedly DO Not desire to set BOTH 8x10 inches and 2700 dpi, which would give 21600 ten 27000 pixels (nigh 17 gigabytes). You take no employ for 8x10 at 2700 dpi. This goal would be 8x10 inches Output at 300 dpi.

Find that when y'all increase resolution, the size formula above multiplies the retention toll by that resolution number twice, in both width and peak. The memory cost for an image increases as the square of the resolution. The square of say 300 dpi is a pretty large number (more than double the square of 200).

Scan resolution and impress resolution are ii very different things. The idea is that we might scan about 1x1 inch of picture show at say 2400 dpi, and so print information technology 8x size at 300 dpi at 8x8 inches. We always want to print photos at about 300 dpi, greater browse resolution is only for enlargement purposes.
The enlargement factor is Scanning resolution / printing resolution. A scan at 600 dpi will print 2x size at 300 dpi.
Emphasizing, unless it is minor film to exist enlarged, you do not want a high resolution scan of letter size paper. You may want a 300 dpi scan to reprint it at original size.

When we double the scan resolution, memory price goes up 4 times. Multiply resolution past three and the memory cost increases 9 times, etc. So this seems a very articulate argument to employ only the amount of resolution we actually need to meliorate the image results for the task purpose. More than that is waste material. It's oftentimes even painful. Well, virtual pain.  <grin>

---

Copyright © 1997-2022 by Wayne Fulton - All rights are reserved.

Source: https://www.scantips.com/basics1d.html

Posted by: maciassonififf.blogspot.com

Share this post