rec.photo.digital
http://groups.google.com/group/rec.photo.digital?hl=en
rec.photo.digital@googlegroups.com
Today's topics:
* Quick question ??? - 2 messages, 2 authors
http://groups.google.com/group/rec.photo.digital/t/69dda4b17aed3a75?hl=en
* JPG compression - yet another question ! - 16 messages, 6 authors
http://groups.google.com/group/rec.photo.digital/t/6b76feb1a85f18f5?hl=en
* Using 8MP camera at 5MP resolution - 3 messages, 3 authors
http://groups.google.com/group/rec.photo.digital/t/94b2fa0434ed74d7?hl=en
* What, 2 stop dynamic range? - 2 messages, 2 authors
http://groups.google.com/group/rec.photo.digital/t/608479883d22d5a3?hl=en
* Which free software could acquire 48 bits color depth pictures from a
scanner ? - 1 messages, 1 author
http://groups.google.com/group/rec.photo.digital/t/4a04fec022c17778?hl=en
* Nikon D700x may see the light of day as D900 (D800??) - 1 messages, 1 author
http://groups.google.com/group/rec.photo.digital/t/36ac775d20500e85?hl=en
* sigma buys foveon - 1 messages, 1 author
http://groups.google.com/group/rec.photo.digital/t/b45194b6b402b71a?hl=en
==============================================================================
TOPIC: Quick question ???
http://groups.google.com/group/rec.photo.digital/t/69dda4b17aed3a75?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Nov 17 2008 7:20 am
From: DaleDomminick
On Mon, 17 Nov 2008 08:30:50 -0600, Don Stauffer <stauffer@usfamily.net> wrote:
>Brian wrote:
>> What are the advantages shooting in raw vs jpg files ????
>>
>> Do raw pix look better, easier to edit ???
>>
>> Thanks
>> Brian
>
>The advantage is in the shades of color and their accuracy. The
>resolution is usually unaffected. One of the mechanisms of the jpeg
>compression is that it sort of "compresses" the number of colors. It
>alters the colors of some pixels, so you lose color fidelity.
>
>The only time resolution is affected is low contrast resolution where
>the detail is due to color differences rather than luminence
>differences, but the eye is not very sensitive to that kind of detail
>anyway.
On the contrary. I have found that I can always tweak out a slight bit more
resolution across the board when using RAW. It depends on your editor and the
type of interpolation method that you use on the RAW data. If you have never
seen a full-spectrum increase in resolution then you need to find a better RAW
editor. The question is whether that very minor increase is worth it. It will
depend on the subject you shoot. Some subjects, like scenes in nature, research
photography, etc., can require every last bit of resolution. Other subjects,
like portraits, do not.
>
>But many photographers are sticklers for color fidelity, and have
>calibrated the color of their system. For those folks RAW is essential.
>Also, for images with subtle color shading, like sunset pictures, the
>JPEG can lose some of the subtlety. These shots can benefit from RAW
>also, even if you warm the colors in processing.
The only reason that JPEG images of sunsets lose their fidelity is that most all
DSLR owners are just pretentious snap-shooters. They leave their camera set on
auto-white-balance (auto-focus, auto-everything). Doing that on a rich sunset
will cause the camera to compensate for all the reds and yellows, trying to wash
them out to grays. If they go back to the RAW file they can correct what they
did wrong in the first place. What a waste of time, when al it really needed
was knowing some basic photography knowledge in the first place.
RAW is not "essential". It's only essential to someone who isn't a very good
photographer or they bought a less than adequate camera. Both revealing someone
who doesn't know what they are doing.
== 2 of 2 ==
Date: Mon, Nov 17 2008 8:44 am
From: ray
On Sun, 16 Nov 2008 23:42:40 -0500, Brian wrote:
> What are the advantages shooting in raw vs jpg files ????
>
> Do raw pix look better, easier to edit ???
>
> Thanks
> Brian
Generally - no, they don't look any better and are more difficult to edit.
If you process a raw file, you can probably make it look better -
depending on what 'better' means. You will need some sort of program or
plug-in to your photo editing software to read the raw files to begin with
- since there is no "standard" raw format (Adobe's DNG being the closest
there is, but every manufacturer uses their own proprietary format). Some
software like ufraw (which is free) will allow you to read the raw file,
edit it in various ways and save it as a jpeg - which is then, more or
less, universally usable. The raw file basically save all the raw
information in the camera, so on some shots which might have been over or
underexposed a bit, you might be able to 'rescue' the picture. You'll also
have more latitude for adjusting compensations.
Bottom line - you can get better results from raw files, but it will most
likely take more work than you've been used to in the past.
==============================================================================
TOPIC: JPG compression - yet another question !
http://groups.google.com/group/rec.photo.digital/t/6b76feb1a85f18f5?hl=en
==============================================================================
== 1 of 16 ==
Date: Mon, Nov 17 2008 7:43 am
From: Bert Hyman
In news:cf13i4hgtl525qmb9mskbvinmqncjfs0o0@4ax.com KentTR
<kenttr@somedomain.com> wrote:
> On 17 Nov 2008 13:59:44 GMT, Bert Hyman <bert@iphouse.com> wrote:
>
>>In
>>news:5c576072-bab3-4921-b357-12e82513124a@i18g2000prf.googlegroups.com
>>Topaz <rsimpson505@gmail.com> wrote:
>>
>>> Is there information in a JPG file that I upload from my digital
>>> camera that says what degree of compression has been used to write
>>> it ?
>>> Perhaps in the EXIF data, but I cannot identify it.
>>
>>
>>Using IrfanView to look at the EXIF data in images from my Canon A60
>>and S3, I see a field called "CompressedBitsPerPixel", with a value of
>>3 for the A60 images and 5 for the S3 images.
>>
>>I always run the camera at its highest resolution, so I don't know how
>>those numbers change with different settings.
>
> Does IrfanView report the chroma sub-sampling? (I have it here, just
> too lazy load it up and check right now.)
>
I don't see any tag with a name like that; maybe my camera doesn't
generate it?
I'd think that IrfanView would simply dump out anything that was in the
record.
--
Bert Hyman St. Paul, MN bert@iphouse.com
== 2 of 16 ==
Date: Mon, Nov 17 2008 7:55 am
From: me@mine.net
On Mon, 17 Nov 2008 05:50:17 -0800 (PST), in rec.photo.digital Topaz
<rsimpson505@gmail.com> wrote:
>Is there information in a JPG file that I upload from my digital
>camera that says what degree of compression has been used to write
>it ?
>Perhaps in the EXIF data, but I cannot identify it.
You should be able to find some entry which documents your camera's
JPG quality setting. However, I don't believe you will find info that
is universal.
== 3 of 16 ==
Date: Mon, Nov 17 2008 7:59 am
From: KentTR
On 17 Nov 2008 15:43:18 GMT, Bert Hyman <bert@iphouse.com> wrote:
>In news:cf13i4hgtl525qmb9mskbvinmqncjfs0o0@4ax.com KentTR
><kenttr@somedomain.com> wrote:
>
>> On 17 Nov 2008 13:59:44 GMT, Bert Hyman <bert@iphouse.com> wrote:
>>
>>>In
>>>news:5c576072-bab3-4921-b357-12e82513124a@i18g2000prf.googlegroups.com
>>>Topaz <rsimpson505@gmail.com> wrote:
>>>
>>>> Is there information in a JPG file that I upload from my digital
>>>> camera that says what degree of compression has been used to write
>>>> it ?
>>>> Perhaps in the EXIF data, but I cannot identify it.
>>>
>>>
>>>Using IrfanView to look at the EXIF data in images from my Canon A60
>>>and S3, I see a field called "CompressedBitsPerPixel", with a value of
>>>3 for the A60 images and 5 for the S3 images.
>>>
>>>I always run the camera at its highest resolution, so I don't know how
>>>those numbers change with different settings.
>>
>> Does IrfanView report the chroma sub-sampling? (I have it here, just
>> too lazy load it up and check right now.)
>>
>
>I don't see any tag with a name like that; maybe my camera doesn't
>generate it?
>
>I'd think that IrfanView would simply dump out anything that was in the
>record.
No, this isn't something in an EXIF tag anywhere. I thought that maybe IrfanView
was doing its own analysis and reporting that info. In order to determine the
chroma sub-sampling used, the old DOS program I mentioned had to go through and
analyze the image itself. Trying to determine sampling area boundaries in the
YCbCr colorspace. The author even claimed it couldn't do it with 100% accuracy,
but it gave you a pretty good idea of what the original programming did to the
image.
Trying to reconstruct the original JPG compression that was used would be a bit
like trying to reconstruct RAW image data from the interpolated view of it. You
can guess, and guess real good, but it can't be done with any high-degree of
accuracy. :-)
That's why that little program was kind of interesting. It did something that
most all others couldn't do. Dedicated just to that task. I used it a few times
in the distant past, more as a curiosity to see what compression levels my
earlier cameras were using for their JPG output. (Which were pretty harsh
compression levels in early cameras.)
Now, if I could just remember the name of it ....
== 4 of 16 ==
Date: Mon, Nov 17 2008 8:33 am
From: "HEMI-Powered"
Topaz added these comments in the current discussion du jour ...
> Is there information in a JPG file that I upload from my
> digital camera that says what degree of compression has been
> used to write it ?
> Perhaps in the EXIF data, but I cannot identify it.
>
No, sorry. The nature of the compression algorithn is such that it
looks at blocks of pixels as it is compressing the image and
irreparably alters it. I'm not totally sure about EXIF but in
quickly looking at it in PSP 9, I don't see anything there about
chroma subsampling, although there is a variety of other useful
information about the unprocessed image. Not that much is user
editible, so if it isn't there, I don't think it can be added for
future reference.
I like to use a chroma subsampling setting of 1x2 1x1 1x1 as a
general very good compromise between compressed file size and least
visible image damage, but if I see ANY artifacts or other visible
defects, I will revert to 1x1 1x1 1x1 which is known as "none".
However, on the relatively rare occasions where I need to reprocess
an image, to minimize any damage from the save-open-edit-
recompress-resave cycle, I will note the startining file size in KB
and set the compression factor to something that creates a slightly
LARGER new file size, the idea being that this should reasonably
guarantee an equivalent or even less compression the second time
around.
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 5 of 16 ==
Date: Mon, Nov 17 2008 8:40 am
From: "HEMI-Powered"
Bert Hyman added these comments in the current discussion du
jour ...
>> Does IrfanView report the chroma sub-sampling? (I have it
>> here, just too lazy load it up and check right now.)
>
> I don't see any tag with a name like that; maybe my camera
> doesn't generate it?
>
> I'd think that IrfanView would simply dump out anything that
> was in the record.
>
I only use Irfanview for creating thumbnail index sheets but a
quick check didn't show EXIF to me, maybe it is there beyond
"information" and I just didn't see it. Nor did I see anything
about compression or chroma subsampling.
I took another look at EXIF in PSP 9 and saw nothing of interest to
the OP so I then look at Exifer which doesn't show anything at all
except, I think, that which can be user edited.
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 6 of 16 ==
Date: Mon, Nov 17 2008 8:41 am
From: Mike Mills
Topaz <rsimpson505@gmail.com> wrote in news:5c576072-bab3-4921-b357-
12e82513124a@i18g2000prf.googlegroups.com:
> Is there information in a JPG file that I upload from my digital
> camera that says what degree of compression has been used to write
> it ?
> Perhaps in the EXIF data, but I cannot identify it.
>
Check your camera settings.
check the filesize, then resave as a lossless format.
resave the lossless format as jpg.
check the difference in size.
Finally.. did it make any *visible* difference?
open 2 windows and compare or swap windows with 2 versions.
== 7 of 16 ==
Date: Mon, Nov 17 2008 8:42 am
From: "HEMI-Powered"
KentTR added these comments in the current discussion du jour
...
>>I'd think that IrfanView would simply dump out anything that
>>was in the record.
>
> No, this isn't something in an EXIF tag anywhere. I thought
> that maybe IrfanView was doing its own analysis and reporting
> that info. In order to determine the chroma sub-sampling used,
> the old DOS program I mentioned had to go through and analyze
> the image itself. Trying to determine sampling area boundaries
> in the YCbCr colorspace. The author even claimed it couldn't
> do it with 100% accuracy, but it gave you a pretty good idea
> of what the original programming did to the image.
I can't imagine any utility being able to reconstruct the before-
compression data in order to report either the amount of
compression or chroma subsampling. I'm certainly no mathematician
but I think that's all lost after the algorithm completes it's
magic.
> Trying to reconstruct the original JPG compression that was
> used would be a bit like trying to reconstruct RAW image data
> from the interpolated view of it. You can guess, and guess
> real good, but it can't be done with any high-degree of
> accuracy. :-)
>
> That's why that little program was kind of interesting. It did
> something that most all others couldn't do. Dedicated just to
> that task. I used it a few times in the distant past, more as
> a curiosity to see what compression levels my earlier cameras
> were using for their JPG output. (Which were pretty harsh
> compression levels in early cameras.)
>
> Now, if I could just remember the name of it ....
>
Yeah, I sure wish you could also! I'd always believed this was
impossible and just made a judgment by noting the file size on a
re-edit/re-save to try and minimize artifacts. Beyond that, I guess
knowing this data would only be useful in the academic sense or for
future reference to avoid a blunder.
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 8 of 16 ==
Date: Mon, Nov 17 2008 8:46 am
From: "HEMI-Powered"
David J Taylor added these comments in the current discussion du
jour ...
> Topaz wrote:
>> Is there information in a JPG file that I upload from my
>> digital camera that says what degree of compression has been
>> used to write it ?
>> Perhaps in the EXIF data, but I cannot identify it.
>>
> No, as there can be many different algorithms used to compress
> the data, and hence no single value to the "compression". You
> will find that different programs express it differently, with
> Paint Shop Pro (for example) using a percentage scale where
> low values like 5-15% imply good quality, large file size,
> images. However, Photoshop uses something like (I understand)
> a simple 1..12 scale, where 12 is best (least compression,
> largest file size).
>
David, did PSP change after 9? In 9, compression is shown as the
original JPEG spec defined it, as a simple 1 to 100 number and
definitely NOT a percentage. Lots of apps use percent because
people are used to anything in the 0-100 range being that, but JPEG
compression is so decidely non-linear that talking in terms of
percentage compression makes no sense - UNLESS it is quoted by the
app as a percentage of UNcompressed.
PSP 9's JPEG Optimizer DOES show uncompressed file size as well as
a very accurate real time estimate of the compressed size as the
user varies either the compression setting or the chroma
subsampling or both.
I never use Irfanview to process pictures, but doesn't it use a
percentage scale with estimates like you used above to indicate
relative quality?
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 9 of 16 ==
Date: Mon, Nov 17 2008 8:47 am
From: "HEMI-Powered"
added these comments in the current discussion du jour ...
>>Is there information in a JPG file that I upload from my
>>digital camera that says what degree of compression has been
>>used to write it ?
>>Perhaps in the EXIF data, but I cannot identify it.
>
> You should be able to find some entry which documents your
> camera's JPG quality setting. However, I don't believe you
> will find info that is universal.
>
I've not seen a numeric setting for JPEG compression on any of my 4
digitals, just the vague kind like "small", "normal", or "fine/very
fine". Of course, I always choose the least compression possible
for obvious reasons.
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 10 of 16 ==
Date: Mon, Nov 17 2008 8:50 am
From: ben-taklin
On Mon, 17 Nov 2008 10:33:06 -0600, "HEMI-Powered" <none@none.sn> wrote:
>
>However, on the relatively rare occasions where I need to reprocess
>an image, to minimize any damage from the save-open-edit-
>recompress-resave cycle, I will note the startining file size in KB
>and set the compression factor to something that creates a slightly
>LARGER new file size, the idea being that this should reasonably
>guarantee an equivalent or even less compression the second time
>around.
Or, you could use Photoline as your editor. It has a built-in system found in no
other editing program. It retains the original image in memory, compares that
against your edits, and then resaves the new one with zero change in compression
level, the only data changed in the saved image is that which you purposely
changed. If you change the whole image then the same compression level as the
original is used.
It's the only truly lossless JPG editor I've ever found. It even handles
lossless rotations better. All other editors must crop the image to JPG
sub-sampling pixel boundaries as it performs their "revolutionary!" lossless
rotation. If you try to rotate, for an easy to understand example, a 15x13 icon
for some software you are writing. When rotated "losslessly" in all other
programs it will truncate that to an 8x8 image. Well, there goes all those tiny
but important pixels that you needed to convey your message on the toolbar.
Ooops. In lossless rotations Photoline again checks against the original and
then replace those border pixels from the original. Rotate a 15x13 image and you
get back a 13x15 image.
== 11 of 16 ==
Date: Mon, Nov 17 2008 8:51 am
From: Bert Hyman
In news:Xns9B5976686F563ReplyScoreID@216.168.3.30 "HEMI-Powered"
<none@none.sn> wrote:
> I only use Irfanview for creating thumbnail index sheets but a
> quick check didn't show EXIF to me, maybe it is there beyond
> "information" and I just didn't see it.
With IrfanView 4.20, select Image->Information. At the bottom left of
the popup should be a button labeled "EXIF info".
--
Bert Hyman St. Paul, MN bert@iphouse.com
== 12 of 16 ==
Date: Mon, Nov 17 2008 9:10 am
From: "HEMI-Powered"
ben-taklin added these comments in the current discussion du
jour ...
>>However, on the relatively rare occasions where I need to
>>reprocess an image, to minimize any damage from the
>>save-open-edit- recompress-resave cycle, I will note the
>>startining file size in KB and set the compression factor to
>>something that creates a slightly LARGER new file size, the
>>idea being that this should reasonably guarantee an equivalent
>>or even less compression the second time around.
>
> Or, you could use Photoline as your editor. It has a built-in
> system found in no other editing program. It retains the
> original image in memory, compares that against your edits,
> and then resaves the new one with zero change in compression
> level, the only data changed in the saved image is that which
> you purposely changed. If you change the whole image then the
> same compression level as the original is used.
>
> It's the only truly lossless JPG editor I've ever found. It
> even handles lossless rotations better. All other editors must
> crop the image to JPG sub-sampling pixel boundaries as it
> performs their "revolutionary!" lossless rotation. If you try
> to rotate, for an easy to understand example, a 15x13 icon for
> some software you are writing. When rotated "losslessly" in
> all other programs it will truncate that to an 8x8 image.
> Well, there goes all those tiny but important pixels that you
> needed to convey your message on the toolbar. Ooops. In
> lossless rotations Photoline again checks against the original
> and then replace those border pixels from the original. Rotate
> a 15x13 image and you get back a 13x15 image.
>
I literally just heard of this yesterday. Thank you for the
heads-up and the very useful information.
As I imagine you'd readily agree, the big thing in computer
graphics image post-processing is the learning curve involved in
figuring out what works and what doesn't for any given situation.
That said, most of us have long ago settling on a fav app, which
might be PhotoShop if we can justify it's cost, PS Elements,
Paint Shop Pro before Corel mangled it, Irfanview, and I suppose
Photoline. I have chosen PSP 9 which has an outstanding noise
reduction and sharpening filter called DCNR (Digital Camera Noise
Reduction).
Not that my pictures are especially nice, they are not, but they
do meet my needs and I'm comfortable with quick and dirty or
slower downtown edits. So, for those rare occasions where I
really need to know something about compression or, as you point
out, be able to look at a before and after (there are preview
panes in PSP 9 but they're small), then probably PL is the
choice.
But, I am always interested in learning and continuous
improvement, so could you please re-post the link to where I can
get Photoline and give me a hint as to it's cost? All I recall
from yesterday is that it isn't free but is low cost.
Couple of points/questions: absent JPEG 2000, how can ANY app be
truly lossless? That's not the nature of the JPEG spec as I
understand it. And, the comment is that I always save the
unedited out-of-the-camera file in a sub-folder so that I have it
in it's pristine, full MP state should I need or want to start
over.
Now, lossless rotation is widely available either by setting a
switch in the image header or really doing a 90 deg rot, which by
the def of JPEG will always yield a no-loss rotate.
Thanks, and have a great day.
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 13 of 16 ==
Date: Mon, Nov 17 2008 9:11 am
From: "HEMI-Powered"
ben-taklin added these comments in the current discussion du
jour ...
> It's the only truly lossless JPG editor I've ever found. It
> even handles lossless rotations better. All other editors must
> crop the image to JPG sub-sampling pixel boundaries as it
> performs their "revolutionary!" lossless rotation. If you try
> to rotate, for an easy to understand example, a 15x13 icon for
> some software you are writing. When rotated "losslessly" in
> all other programs it will truncate that to an 8x8 image.
> Well, there goes all those tiny but important pixels that you
> needed to convey your message on the toolbar. Ooops. In
> lossless rotations Photoline again checks against the original
> and then replace those border pixels from the original. Rotate
> a 15x13 image and you get back a 13x15 image.
>
Forgot to mention that I frequently use the History Pallette in PSP
9 to roll-back any number of changes should I need to, such as an
incorrect rotate so other than straight landscape to/from portrait,
that is almost never the issue for me.
Thanks again.
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 14 of 16 ==
Date: Mon, Nov 17 2008 9:12 am
From: "HEMI-Powered"
Bert Hyman added these comments in the current discussion du
jour ...
>> I only use Irfanview for creating thumbnail index sheets but
>> a quick check didn't show EXIF to me, maybe it is there
>> beyond "information" and I just didn't see it.
>
> With IrfanView 4.20, select Image->Information. At the bottom
> left of the popup should be a button labeled "EXIF info".
Hmmm. Guess I'm one rev out of date, mine is 4.10. Got a link, or
I'll just Google for it. Thanks for the heads-up. And, any big
changes other than EXIF?
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 15 of 16 ==
Date: Mon, Nov 17 2008 9:14 am
From: "HEMI-Powered"
Mike Mills added these comments in the current discussion du
jour ...
>> Is there information in a JPG file that I upload from my
>> digital camera that says what degree of compression has been
>> used to write it ?
>> Perhaps in the EXIF data, but I cannot identify it.
>>
> Check your camera settings.
> check the filesize, then resave as a lossless format.
> resave the lossless format as jpg.
> check the difference in size.
>
> Finally.. did it make any *visible* difference?
> open 2 windows and compare or swap windows with 2 versions.
>
If one's app has any sort of JPEG optimizer, as PSP 9 and later do,
then the running file size can be viewed real-time as compression
and/or chroma subsampling are varies. Don't know about any version
of PhotoShop as I don't have any.
Incidently, after I'm all done and ready to save, I ALWAY
immediately re-open images to ensure there was no damage by the
compression. more than 99% of the time I am OK, but for the 1%, a
compression reduction usually fixes the problem.
--
HP, aka Jerry
"Never attribute to malice that which can be adequately explained
by stupidity!" - Hanlon's Razor
== 16 of 16 ==
Date: Mon, Nov 17 2008 9:15 am
From: KentTR
On Mon, 17 Nov 2008 10:42:58 -0600, "HEMI-Powered" <none@none.sn> wrote:
>Yeah, I sure wish you could also!
I just ran this one that I found when trying to retrace my "online" memory:
ftp://ftp.lexa.ru/pub/domestic/jpeg-analyzer/ja001.zip
It might be the one I recall using, the output looks a little familiar, but
don't quote me on it. Yeah, the more I look at the output, the more I think this
is the one. The last line has a "quality" estimation too.
Open a command-prompt window and just type ja filename.jpg
The program and images have to be in the same folder (if you don't want to type
long filename paths).
Example output:
I:\Downloads 03\JPEG Analyzer - ja001>ja waves.jpg
JPEG Analyzer v.0.01 (Win32) FREEWARE
Written by Dmitry Gorshkov
Copyright (c) 2003-2004 All Rights Reserved.
Scanning...: waves.jpg
FFD8 at 00000000 SOI (Segment Of Image)
FFE0 at 00000002 APP0 (JPEG Identification) Type: JFIF
Type: JFIF - standard JPEG marker
FFDB at 00000014 DQT (Definition Of Quantization Table)
FFDB at 00000059 DQT (Definition Of Quantization Table)
FFC2 at 0000009E *SOF2 (UNSUPPORTED) (Adobe PhotoShop)
SOF2 Info: X: 2816, Y: 2112, Mode: Color (24 bits)
FFC4 at 000000B1 DHT (Descriptor Of Huffman Table)
FFC4 at 000000D1 DHT (Descriptor Of Huffman Table)
FFDA at 000000EF SOS (Segment Of Scanning)
FFC4 at 0003020A DHT (Descriptor Of Huffman Table)
FFDA at 0003023E SOS (Segment Of Scanning)
FFC4 at 00067D53 DHT (Descriptor Of Huffman Table)
FFDA at 00067D8B SOS (Segment Of Scanning)
FFC4 at 000884D6 DHT (Descriptor Of Huffman Table)
FFDA at 00088513 SOS (Segment Of Scanning)
FFC4 at 000B1591 DHT (Descriptor Of Huffman Table)
FFDA at 000B15E8 SOS (Segment Of Scanning)
FFC4 at 000FFA8B DHT (Descriptor Of Huffman Table)
FFDA at 000FFAB4 SOS (Segment Of Scanning)
FFDA at 00170D50 SOS (Segment Of Scanning)
FFC4 at 001795F1 DHT (Descriptor Of Huffman Table)
FFDA at 0017961A SOS (Segment Of Scanning)
FFC4 at 001A2525 DHT (Descriptor Of Huffman Table)
FFDA at 001A254F SOS (Segment Of Scanning)
FFC4 at 001D05FC DHT (Descriptor Of Huffman Table)
FFDA at 001D0624 SOS (Segment Of Scanning)
FFD9 at 00273D60 EOI (End Of Image)
Maked by: Independent JPEG Group's library (Quality=96) (color or b&w)
Progressive JPEG
==============================================================================
TOPIC: Using 8MP camera at 5MP resolution
http://groups.google.com/group/rec.photo.digital/t/94b2fa0434ed74d7?hl=en
==============================================================================
== 1 of 3 ==
Date: Mon, Nov 17 2008 7:57 am
From: Bates
On Nov 16, 3:46 pm, spasmous2 <spasm...@gmail.com> wrote:
> I bought a Ricoh R7 8MP camera recently. On the settings, I opted to
> run it in 5MP mode which gives smaller file sizes for virtually no
> difference in image appearance (to my eye anyway). I was thinking
> there would be a decrease in noise in the images due to the pixels
> being about 1.4 times larger. It's hard to see if that is actually the
> case - does anyone know what kind of downsampling is used on digital
> cameras?
The pixels should not actually increase in size. The sensor itself is
just using fewer pixels to capture the image so the size of pixel
should be the same.
On some cameras (particularly high end video cameras used on
microscopes) you can "bin" pixels to increase sensitivity - ie you can
use two pixels on the sensor to create one pixel in the image (or 4 to
1) etc....The resolution decreases but the sensitivity increases. I
would think however on your Ricoh, it is simply leaving out the
information from the non-used pixels though.
== 2 of 3 ==
Date: Mon, Nov 17 2008 8:19 am
From: carl-thornton
On Mon, 17 Nov 2008 07:57:06 -0800 (PST), Bates <nw1008@gmail.com> wrote:
>The pixels should not actually increase in size. The sensor itself is
>just using fewer pixels to capture the image so the size of pixel
>should be the same.
No. A digital camera only uses fewer sensor pixels when sending a live-view feed
to an EVF or LCD on the camera, or sometimes when using the larger sensor for
capturing lower-resolution video-frames (often this is done with pixel-binning
instead though, for better low-light low-noise performance). All cameras that
allow you to choose a smaller image size for the resulting stilll-frame JPG file
does so by using the full sensor data and then downsampling it.
Depending on the downsampling algorithm used, this can blur fine details (e.g.
bicubic) and also blur/average out some noise too in the process. If you have no
need for higher resolution images, and you need to shoot at higher ISOs that can
be noisier, you can do some extra in-camera noise-reduction by downsampling,
choosing a smaller image size. It's not the best way to do it but for some
people's needs it might be all they care for. That's perfectly fine to do so.
As has been proven time and time again, resolution, quality, noise, none of that
really matters in an award-winning image. The content of an image will win out
over those things each and every time. I once had a 1024x768 image from an early
digital camera. The subject so striking that it even held up to being printed at
13"x18", after some well-executed upsampling to remove the garishly huge pixel
blocks. The image having so much impact that nobody cared about the ultra-soft
edges (which were part of the original to begin with to some extent). They never
even noticed the softness in the photo because the subject was more important to
their eye and mind. The lower quality hidden behind the impact of the subject.
There are no absolutes when it comes to photography. The only possible absolute
in photography is that the image will hold its own at any resolution, or it
won't at all at any resolution.
== 3 of 3 ==
Date: Mon, Nov 17 2008 9:11 am
From: "trouble"
If I understand your post you seem to be implying that the aesthetic quality
of a photographic image is more important than its technical quality.
That is sheer heresy.
==============================================================================
TOPIC: What, 2 stop dynamic range?
http://groups.google.com/group/rec.photo.digital/t/608479883d22d5a3?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Nov 17 2008 8:12 am
From: Rich
Lord forgive them.
Dpreview.com:
Sony has announced the development of the finest-yet pixel-pitch
1/2.5" sensor. The 12.2MP CMOS sensor has been developed for mobile
phone cameras, but is of a size commonly used in compact and super
zoom cameras. The IMX060PQ sensor, which Sony brands 'Exmor' in common
with its DSLR CMOS sensors, will also be available incorporated into
an F2.8 28mm-equiv lens unit with piezoelectric driven autofocus -
relatively advanced for a camera phone module.
== 2 of 2 ==
Date: Mon, Nov 17 2008 8:26 am
From: Calvin Dobbs
On Mon, 17 Nov 2008 08:12:39 -0800 (PST), Rich <rander3127@gmail.com> wrote:
>Lord forgive them.
>
>Dpreview.com:
>Sony has announced the development of the finest-yet pixel-pitch
>1/2.5" sensor. The 12.2MP CMOS sensor has been developed for mobile
>phone cameras, but is of a size commonly used in compact and super
>zoom cameras. The IMX060PQ sensor, which Sony brands 'Exmor' in common
>with its DSLR CMOS sensors, will also be available incorporated into
>an F2.8 28mm-equiv lens unit with piezoelectric driven autofocus -
>relatively advanced for a camera phone module.
And yet, I've seen some award-winning photographs presented in a 2-bit depth
image. (Posterized pure blacks and whites.) Some of those images are still being
printed that way as examples in photography reference books to show you what can
be done within such limitations -- IF you are a REAL pro.
That's the part that hurts all of you, doesn't it. Something that you wish you
could be by just purchasing the right camera. And yet, we all know that that's
never going to happen, don't we.
You people look more and more silly every day, to anyone who is a real pro.
==============================================================================
TOPIC: Which free software could acquire 48 bits color depth pictures from a
scanner ?
http://groups.google.com/group/rec.photo.digital/t/4a04fec022c17778?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Nov 17 2008 8:57 am
From: Paul Furman
bugbear wrote:
> Guilbert STABILO wrote:
>> => Do you know any free software or plugin which could work with 48
>> bits pictures acquired from a scanner ?
>
> Cinepaint
>
> http://www.cinepaint.org/
Ah... that makes sense for b&w I guess...
"Top Reasons to Use CinePaint
4. Gallery-quality printing. B&W photographs have only one color
channel and degrade quickly when manipulated as 8-bit images. CinePaint
has higher fidelity and offers a 16-bit printing path to the print-head
using GutenPrint."
--
Paul Furman
www.edgehill.net
www.baynatives.com
all google groups messages filtered due to spam
==============================================================================
TOPIC: Nikon D700x may see the light of day as D900 (D800??)
http://groups.google.com/group/rec.photo.digital/t/36ac775d20500e85?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Nov 17 2008 9:08 am
From: "trouble"
This belongs in the RichA catalog of non-sequiturs.
==============================================================================
TOPIC: sigma buys foveon
http://groups.google.com/group/rec.photo.digital/t/b45194b6b402b71a?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Nov 17 2008 9:11 am
From: Paul Furman
Alfred Molon wrote:
> In article <161120081337159604%nospam@nospam.invalid>, nospam says...
>
>>>> and the colour resolution of the human eye is 1/10 that of luminance,
>>>> so bayer is already ahead.
>>> That is a completely different issue.
>> how is it different? you have 5x as much chroma resolution as your eyes
>> can see.
>
> But it makes no sense to design an image sensor around the limitations
> of the human eye. Otherwise by your logic, since the human eye cannot
> see colours in darkness, cameras should switch to monochrome when light
> levels drop beyond a certain point.
That should make a more natural looking night scene. Nikon does this at
high ISO and yeah it is a bit of a cheat but a cheat with a basis in
reality <grin>. If you didn't want it to look like night then no.
--
Paul Furman
www.edgehill.net
www.baynatives.com
all google groups messages filtered due to spam
==============================================================================
You received this message because you are subscribed to the Google Groups "rec.photo.digital"
group.
To post to this group, visit http://groups.google.com/group/rec.photo.digital?hl=en
To unsubscribe from this group, send email to rec.photo.digital+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/rec.photo.digital/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
0 comments:
Post a Comment