file size resulting from # of pixels/colors?

[Guest]

Archived from groups: alt.comp.periphs.dcameras (More info?)

This one's bugging me. Shouldn't the # of pixels equal the resolution
(say 1024x768 = 786,432), yielding a file of 786K? Or is it divided by 8
for a bits/bytes conversion like with soundfiles, giving 98304? And then
what about the color depth? Wouldn't you multiply it by 16million if it's
24bit? Obviously not, since that gives a ridiculous #, but how DOES it
work? I'm annoyingly confused
--
_____________________________________________________
For email response, or CC, please mailto:see.my.sig.4.addr(at)bigfoot.com.
Yeah, it's really a real address

 

[Guest]

Archived from groups: alt.comp.periphs.dcameras (More info?)

On Mon, 10 Jan 2005 06:42:14 -0800,
see.my.sig.4.addr@nowhere.com.invalid wrote:

>This one's bugging me. Shouldn't the # of pixels equal the resolution
>(say 1024x768 = 786,432), yielding a file of 786K? Or is it divided by 8
>for a bits/bytes conversion like with soundfiles, giving 98304? And then
>what about the color depth? Wouldn't you multiply it by 16million if it's
>24bit? Obviously not, since that gives a ridiculous #, but how DOES it
>work? I'm annoyingly confused

No conversion and 24 bit doesn't factor in, the image size should be
close to the camera's actual resolution. Some manufactors uses 2
different sets of number: effective and one other I forgot atm.
--
To reply, replace digi.mon with phreaker.net

 

[Guest]

Archived from groups: alt.comp.periphs.dcameras (More info?)

On Mon, 10 Jan 2005 06:42:14 -0800,
see.my.sig.4.addr@nowhere.com.invalid wrote:

>This one's bugging me. Shouldn't the # of pixels equal the resolution
>(say 1024x768 = 786,432), yielding a file of 786K? Or is it divided by 8
>for a bits/bytes conversion like with soundfiles, giving 98304? And then
>what about the color depth? Wouldn't you multiply it by 16million if it's
>24bit? Obviously not, since that gives a ridiculous #, but how DOES it
>work? I'm annoyingly confused

roughly
24bit = 3 bytes so number of pixels times 3 bytes divided by the jpg
compression factor .. I said roughly .. make that very roughly

 

[Guest]

Archived from groups: alt.comp.periphs.dcameras (More info?)

I think it works like this: (filesize in bytes) = (pixels * BitsPerPixel)/8
thus, 1 megapixels, at 21 bit colour depth is almost 3Mb, of course, the
image is usually preprocessed on board the camera to roughly 1/5 of that if
it saving the images in jpg format, yielding a jpg picture around half a meg
in size.
However, i could be wrong, I'm not an expert on dgcams, yet, but I'm
learning. Is this right, you experts?


<see.my.sig.4.addr@nowhere.com.invalid> wrote in message
news:m745u0lssbisj1icdgfg18thcl0sdmhrg5@4ax.com...
> This one's bugging me. Shouldn't the # of pixels equal the resolution
> (say 1024x768 = 786,432), yielding a file of 786K? Or is it divided by 8
> for a bits/bytes conversion like with soundfiles, giving 98304? And then
> what about the color depth? Wouldn't you multiply it by 16million if it's
> 24bit? Obviously not, since that gives a ridiculous #, but how DOES it
> work? I'm annoyingly confused
> --
> _____________________________________________________
> For email response, or CC, please mailto:see.my.sig.4.addr(at)bigfoot.com.
> Yeah, it's really a real address

 

[Chuck]

Archived from groups: alt.comp.periphs.dcameras (More info?)

Oly C8080 8 Meg camera
Raw file 11,809KB
Tif file 20,823KB

"Impmon" <impmon@digi.mon> wrote in message
news:bpl5u05040mkgcvcemk0q8k7li6smt64m1@4ax.com...
> On Mon, 10 Jan 2005 06:42:14 -0800,
> see.my.sig.4.addr@nowhere.com.invalid wrote:
>
>>This one's bugging me. Shouldn't the # of pixels equal the resolution
>>(say 1024x768 = 786,432), yielding a file of 786K? Or is it divided by 8
>>for a bits/bytes conversion like with soundfiles, giving 98304? And then
>>what about the color depth? Wouldn't you multiply it by 16million if it's
>>24bit? Obviously not, since that gives a ridiculous #, but how DOES it
>>work? I'm annoyingly confused
>
> No conversion and 24 bit doesn't factor in, the image size should be
> close to the camera's actual resolution. Some manufactors uses 2
> different sets of number: effective and one other I forgot atm.
> --
> To reply, replace digi.mon with phreaker.net

 

[Guest]

Archived from groups: alt.comp.periphs.dcameras (More info?)

jpeg has at least ten compression levels, from no loss of detail to lossy
compression.

"Tom H" <th54@hotmail.com> wrote in message
news:ZYxEd.44191$Xk.34402@pd7tw3no...
> I think it works like this: (filesize in bytes) = (pixels *
BitsPerPixel)/8
> thus, 1 megapixels, at 21 bit colour depth is almost 3Mb, of course, the
> image is usually preprocessed on board the camera to roughly 1/5 of that
if
> it saving the images in jpg format, yielding a jpg picture around half a
meg
> in size.
> However, i could be wrong, I'm not an expert on dgcams, yet, but I'm
> learning. Is this right, you experts?
>
>
> <see.my.sig.4.addr@nowhere.com.invalid> wrote in message
> news:m745u0lssbisj1icdgfg18thcl0sdmhrg5@4ax.com...
> > This one's bugging me. Shouldn't the # of pixels equal the resolution
> > (say 1024x768 = 786,432), yielding a file of 786K? Or is it divided by
8
> > for a bits/bytes conversion like with soundfiles, giving 98304? And
then
> > what about the color depth? Wouldn't you multiply it by 16million if
it's
> > 24bit? Obviously not, since that gives a ridiculous #, but how DOES it
> > work? I'm annoyingly confused
> > --
> > _____________________________________________________
> > For email response, or CC, please
mailto:see.my.sig.4.addr(at)bigfoot.com.
> > Yeah, it's really a real address
>
>