JPG compression - yet another question !
Topaz
camera that says what degree of compression has been used to write
it ?
Perhaps in the EXIF data, but I cannot identify it.
Thanks in advance.
Bert Hyman
news:5c576072-bab3-4921...@i18g2000prf.googlegroups.com
Topaz <rsimp...@gmail.com> wrote:
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.
--
Bert Hyman St. Paul, MN be...@iphouse.com
KentTR
Does IrfanView report the chroma sub-sampling? (I have it here, just too lazy
load it up and check right now.)
There used to be (or is) a small command-line (DOS) program that would analyze
an image and tell you what YCbCr chroma sub-sampling (2,1,1 / 4,2,2 / 1,1,1
etc.) was applied and at what compression level. Does anyone remember that
program and what it was called? I doubt I could even find it on my hard-drives
anymore, it's been so long ago. That little program would do exactly what you
want.
David J Taylor
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
Bert Hyman
<ken...@somedomain.com> wrote:
> On 17 Nov 2008 13:59:44 GMT, Bert Hyman <be...@iphouse.com> wrote:
>
>>In
>>news:5c576072-bab3-4921...@i18g2000prf.googlegroups.com
>>Topaz <rsimp...@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.
KentTR
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 ....
HEMI-Powered
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
HEMI-Powered
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.
Mike Mills
12e825...@i18g2000prf.googlegroups.com:
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.
HEMI-Powered
...
>>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.
HEMI-Powered
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?
HEMI-Powered
>>Is there information in a JPG file that I upload from my
> 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.
ben-taklin
>
>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.
Bert Hyman
<no...@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".
HEMI-Powered
jour ...
>>However, on the relatively rare occasions where I need to
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.
HEMI-Powered
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.
HEMI-Powered
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?
HEMI-Powered
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.
KentTR
>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
Paul Furman
The camera may or may not include a custom field, for example:
Make - NIKON CORPORATION
Maker Note (Vendor): -
Image Quality - FINE
--
Paul Furman
www.edgehill.net
www.baynatives.com
all google groups messages filtered due to spam
David J Taylor
[]
> 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?
Yes, you are correct. PSP-10 also uses a pure number. I was wrong when I
mentioned percentage. In another library I use when programming the
values are 1..100, where 80 is pretty good, and 95 excellent. Again, pure
number, and not a percentage (although with 100 being near-perfect, it's
tempting to think in percentages!). IrfanView uses a 1..100 scale as
well.
I also use the PSP-10 optimiser (Export to JPEG) and agree it's most
handy. I use it when sizing pictures for a Web site, where the content
and fast download are more important than the last bit of quality.
Cheers,
David
ben-taklin
Getting off-topic here...
On Mon, 17 Nov 2008 11:10:14 -0600, "HEMI-Powered" <no...@none.sn> wrote:
> I have chosen PSP 9 which has an outstanding noise
>reduction and sharpening filter called DCNR (Digital Camera Noise
>Reduction).
I agree about those 2 things about PSP. I still keep it installed just for their
CA-removal tool for fringing/blooming sensor artifacts. I've found no other
plugin or software that handles sensor-blooming as well. (Though it is not
useful for lateral CA, the kind imparted by refraction of optics, where colors
disperse more at the edges.) I have to admit though, the Hue/Saturation tool in
Photoline can work equally well. But it does take some time to learn how to use
it effectively. It allows you to select a very narrow range of colors,
feathering that range, then desaturate and change its luminosity level to match
original surrounding pixels. The same as PSP's tool. It's just not as simple to
use as PSP's where you select the fringing colors all at once and hit "OK".
It's DCNR tool is also very nice. There are many 3rd party ones now that do
more, but not as simple and good at the same time.
>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.
www.pl32.net (or com, both work)
It's about $80? USD after conversion.
Do read the manual on this one. As much as I despise reading manuals this
program requires that effort. It does so much in such a small package that this
is not an editor for beginners, by any stretch of the imagination. Your previous
experience with the other programs will help you. Here's another helpful link
that will help you to find and convert what you already know into Photoline
work-flow methods and tool-names.
http://www.geocities.com/advanced_pser/graphic_editor_cross_reference.htm
>
>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.
It's lossless in the same way that you can unzip a compressed ZIP or RAR file
and get back every bit of the original contents.
You might like to know that Photoline is one of the only few editors out there
that supports the new HDPhoto format and has done so for almost a year now. This
new image format is one of the very few things that Microsoft did right. It's
designed to support 16-bit depth images and all MetaData info while using JPEG
compression. Think of it basically as a 16-bit JPG.
It'll eventually catch on as more programs support it.
Use Photoline's really nice "Web Export" feature to compare different
compression types against each other (and against the original) and instantly
see file-sizes and image quality in zoomed-in views to decide which is best to
use for each kind of image being saved.
I for one can't live without that nice side-by-side-by-side image compression
feature in any editor anymore.
>
>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.
Yes, but in all other applications their "rotate losslessly" throws away those
border-pixels to match the 8-pixel JPG compression-block boundaries.
Bert Hyman
> On 17 Nov 2008 16:51:05 GMT, in rec.photo.digital Bert Hyman
><be...@iphouse.com> wrote:
>
>>In news:Xns9B5976686F5...@216.168.3.30 "HEMI-Powered"
>><no...@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".
>
> Note that the EXIF feature is one of those added by the Irfanview
> Plugins which have to dl'd and installed separately from the program.
Ah! Didn't know that; I thought it was a native feature. I download and
install the complete set of plugins each time I move up a version.
Bert Hyman
<no...@none.sn> wrote:
> 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?
Someone else just pointed out that the EXIF display is not a native
feature, but is done by a plugin. Since I always install the complete
set of plugins each time I move up a version, I never noticed.
David J Taylor
[]
> 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.
Jerry,
JPEG 2000 includes an option for lossless operation, as does standard
JPEG. It's not widely available in standard JPEG, though. And JPEG 2000
isn't widely used, either.
http://en.wikipedia.org/wiki/JPEG_2000
Personally, if I want lossless I use PNG.
Cheers,
David
HEMI-Powered
jour ...
>>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.
>
> www.pl32.net (or com, both work)
>
> It's about $80? USD after conversion.
Thanks, muchly!
> Do read the manual on this one. As much as I despise reading
> manuals this program requires that effort. It does so much in
> such a small package that this is not an editor for beginners,
> by any stretch of the imagination. Your previous experience
> with the other programs will help you. Here's another helpful
> link that will help you to find and convert what you already
> know into Photoline work-flow methods and tool-names.
>
> http://www.geocities.com/advanced_pser/graphic_editor_cross_ref
> erence.htm
Climbing the learning curve is always tough. Had a bitch of a
time when I first got a DSLR. And, it is lack of time and lack of
a tutorial book that keeps me from RAW.
>>
>>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.
>
> It's lossless in the same way that you can unzip a compressed
> ZIP or RAR file and get back every bit of the original
> contents.
OK, but that'd be like using LZW on a TIFF image. The JPEG spec
is specifically written to BE lossy, that is how it achieves it's
stupendous reductions. It is interesting to note that the spec
was originally developed to help photographers hawk their wares
in a much more efficient manner on the slow computers and comm
lines quite some time back.
> You might like to know that Photoline is one of the only few
> editors out there that supports the new HDPhoto format and has
> done so for almost a year now. This new image format is one of
> the very few things that Microsoft did right. It's designed to
> support 16-bit depth images and all MetaData info while using
> JPEG compression. Think of it basically as a 16-bit JPG.
I have no clue what that is.
> It'll eventually catch on as more programs support it.
The trouble with any standard is that once it is out there,
everybody jumps on and new ideas cannot gain traction.
> Use Photoline's really nice "Web Export" feature to compare
> different compression types against each other (and against
> the original) and instantly see file-sizes and image quality
> in zoomed-in views to decide which is best to use for each
> kind of image being saved.
>
> I for one can't live without that nice side-by-side-by-side
> image compression feature in any editor anymore.
>
>>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.
>
> Yes, but in all other applications their "rotate losslessly"
> throws away those border-pixels to match the 8-pixel JPG
> compression-block boundaries.
I've never noticed any damage, but then, I'm not looking nor am I
using any analytical tools to check. It is a hobby for me, not a
job.
>
Just curious, what do you do that requires this much
sophistication? Pro? Just super interested?
HEMI-Powered
jour ...
> HEMI-Powered wrote:
I have NEVER heard of lossless standard JPEG and have never seen an
app that can do that, certainly not PSP anything and I've been
using it since it's CompuServe shareware days. JPEG 2000 is useless
as nothing supports it. Likewise, I rarely use PSPimage unless I
must save layers and vectors for a work-in-progress.
I am aware of JPEG 2000, David, have long been aware, and PSP
supports it but if I post pictures that way, nobody can see them.
Hell, the OE crowd can't even see a simple yEnc.
Thanks for the info.
HEMI-Powered
jour ...
> HEMI-Powered wrote:
As I understand the JPEG spec, David, it IS a unitless number
from 1 to 100. What I've read says that the original idea for 1
was to approximate the size of a LZW compressed TIFF, about half,
while 100 is just for people wanting intentional pixellation and
blobs! <grin>
In PSP, as I believe the spec says, 1 is least compression and
100 is most,while many programs have it entirely backwards for
some reason. I used to save at around 15 before I could see what
I was doing. Now,I rarely go over 10 unless the image size is
large. Frequently I am at 8, 7 or even 5. And, I get a lot more
artifacts with noise reduced scans than digitals, and often have
to go much lower.
David J Taylor
[]
> As I understand the JPEG spec, David, it IS a unitless number
> from 1 to 100. What I've read says that the original idea for 1
> was to approximate the size of a LZW compressed TIFF, about half,
> while 100 is just for people wanting intentional pixellation and
> blobs! <grin>
Sounds good to me!
> In PSP, as I believe the spec says, 1 is least compression and
> 100 is most,while many programs have it entirely backwards for
> some reason. I used to save at around 15 before I could see what
> I was doing. Now,I rarely go over 10 unless the image size is
> large. Frequently I am at 8, 7 or even 5. And, I get a lot more
> artifacts with noise reduced scans than digitals, and often have
> to go much lower.
I tend to stick with 8 these days, but I do use full resolution images
from the camera which are less sensitive to having a slightly greater JPEG
compression used, as the images are slightly less sharp at the pixel level
than if, for example, you use or resample a 10MP image down to 2-3MP. For
the Web, I'm often saving at a compression level of 30 in PSP to reduce
file size.
Cheers,
David
David J Taylor
> "HEMI-Powered" <no...@none.sn> wrote:
>
>> 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
>
> compressed JPEG data in memory and where a JPEG tile* has not been
> altered during the edit it simply writes that original JPEG data
> back. That is, instead of recompressing the whole picture it only
> recompresses the tiles that have been modified. So the unaltered
> parts are indeed saved losslessly. If you are only altering a small
> part of an image, e.g. adding a caption or removing redeye, this kind
> of editor is very useful. (Unfortunately in BetterJPEG's case its
> text tool stinks as is doesn't anti-alias....)
>
> *JPEGs are made up of 8x8 or 16x16 pixel tiles.
No, JPEG 2000 uses wavelet transforms instead of DCT:
http://en.wikipedia.org/wiki/JPEG_2000
David
HEMI-Powered
jour ...
> "HEMI-Powered" <no...@none.sn> wrote:
>
>> 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
>
> If it works in the same way as BetterJPEG then it keeps the
> original compressed JPEG data in memory and where a JPEG tile*
> has not been altered during the edit it simply writes that
> original JPEG data back. That is, instead of recompressing the
> whole picture it only recompresses the tiles that have been
> modified. So the unaltered parts are indeed saved losslessly.
> If you are only altering a small part of an image, e.g. adding
> a caption or removing redeye, this kind of editor is very
> useful. (Unfortunately in BetterJPEG's case its text tool
> stinks as is doesn't anti-alias....)
>
> *JPEGs are made up of 8x8 or 16x16 pixel tiles.
>
Yes. I've always referred to them as "blocks" but "tiles" works for
me. Harkening back to why the spec was written was for photographs,
not fine detail, not lines, not vector-style objects and certainly
not fine text.
What is BetterJPEG, one of the new ideas that preserves the
original data better somehow? I don't follow the technology but how
can a lossless algorithm even approach that of a lossy one,
especially if it claims to preserve anything?
But then, the nature of innovation is that somebody may well have
developed a better mousetrap.
HEMI-Powered
jour ...
>> If it works in the same way as BetterJPEG then it keeps the
>> original compressed JPEG data in memory and where a JPEG
>> tile* has not been altered during the edit it simply writes
>> that original JPEG data back. That is, instead of
>> recompressing the whole picture it only recompresses the
>> tiles that have been modified. So the unaltered parts are
>> indeed saved losslessly. If you are only altering a small
>> part of an image, e.g. adding a caption or removing redeye,
>> this kind of editor is very useful. (Unfortunately in
>> BetterJPEG's case its text tool stinks as is doesn't
>> anti-alias....)
>>
>> *JPEGs are made up of 8x8 or 16x16 pixel tiles.
>
> No, JPEG 2000 uses wavelet transforms instead of DCT:
>
> http://en.wikipedia.org/wiki/JPEG_2000
>
isn't Marty referring to ordinary JPEG just above, David? I believe
he is correct about that, or at least the sampling algorithm does
use 8x8 and 16x16 blocks of pixels to decide what to throw away.
HEMI-Powered
jour ...
> HEMI-Powered wrote:
> []
>> As I understand the JPEG spec, David, it IS a unitless number
>> from 1 to 100. What I've read says that the original idea for
>> 1 was to approximate the size of a LZW compressed TIFF, about
>> half, while 100 is just for people wanting intentional
>> pixellation and blobs! <grin>
>
> Sounds good to me!
David, I think it is maybe 10 or more years since I even
attempted to look at this but when I finally switched from PSP 3
all the way to PSP 8, I began to notice that I was actually
introducing artifacts, pixelation, sometimes posterization and
aliasing by using even 15 or 20 compression numbers. So, around
maybe 2000 or 2001 I began to open or at least display my just-
saved images to check before I blew away the unformatted bitmap
in PSP's memory.
As I said earlier, I almost never see any damage, but there have
been a few really pathological cases where the image was
essentially destroyed by even a setting of 8. Never have been
able to find a common reason for it, but it doesn't happen often
enough to spend brain cells on predicting; I just look and be
done with it.
>> In PSP, as I believe the spec says, 1 is least compression
>> and 100 is most,while many programs have it entirely
>> backwards for some reason. I used to save at around 15 before
>> I could see what I was doing. Now,I rarely go over 10 unless
>> the image size is large. Frequently I am at 8, 7 or even 5.
>> And, I get a lot more artifacts with noise reduced scans than
>> digitals, and often have to go much lower.
>
> I tend to stick with 8 these days, but I do use full
> resolution images from the camera which are less sensitive to
> having a slightly greater JPEG compression used, as the images
> are slightly less sharp at the pixel level than if, for
> example, you use or resample a 10MP image down to 2-3MP. For
> the Web, I'm often saving at a compression level of 30 in PSP
> to reduce file size.
>
I agree with you and would probably do the same if I save ultra
large images. But for reasons you may disagree with, but do
understand, I shoot generally at 6 MP and reduce to 1600 x 1200
these days. I do use the full 12 my Rebel XSi can produce but
rarely. When I moved from 1280 x 960 and 1400 x 1050 images
earlier this year, I noticed a rather large jump in file size. I
don't much give a rip about HDD space and images that small
perform very well on my 2.6GHz AMD Athlon CPU, but when posting
even this modest size, I want to be respectful of others download
times.
For those rare times that I want to send smaller JPEGs via E-mail
or some other medium to people on slow connections, I'll manually
reduce the pixel size and up the compression a whole bunch. I
don't go onto web sites per se but if I did, I'd probably use 30
or so as you do.
Have a great day, David!
David J Taylor
> David J Taylor added these comments in the current discussion du
> jour ...
>> No, JPEG 2000 uses wavelet transforms instead of DCT:
>>
>> http://en.wikipedia.org/wiki/JPEG_2000
>>
> isn't Marty referring to ordinary JPEG just above, David? I believe
> he is correct about that, or at least the sampling algorithm does
> use 8x8 and 16x16 blocks of pixels to decide what to throw away.
I thought he was comparing JPEG 2000 with "BetterJPEG", whatever that is
(I suspect it's a program).
Cheers,
David
David J Taylor
[]
> David, I think it is maybe 10 or more years since I even
> attempted to look at this but when I finally switched from PSP 3
> all the way to PSP 8, I began to notice that I was actually
> introducing artifacts, pixelation, sometimes posterization and
> aliasing by using even 15 or 20 compression numbers. So, around
> maybe 2000 or 2001 I began to open or at least display my just-
> saved images to check before I blew away the unformatted bitmap
> in PSP's memory.
>
> As I said earlier, I almost never see any damage, but there have
> been a few really pathological cases where the image was
> essentially destroyed by even a setting of 8. Never have been
> able to find a common reason for it, but it doesn't happen often
> enough to spend brain cells on predicting; I just look and be
> done with it.
There were some issues with the lower JPEG compression levels not working
correctly in some versions of Paint Shop Pro - possibly PSP8 or PSP-9, but
I no longer have the details to hand. It might be worth a Google
search....
Yes, I appreciate your reduced pixel mode compared to full camera
resolution, and I think that will need a lower JPEG compression to show
the equivalent amount of artefacts compared to a full camera resolution
image.
Cheers,
David
MoreyAndersen
>"HEMI-Powered" <no...@none.sn> wrote:
>>
>> What is BetterJPEG, one of the new ideas that preserves the
>> original data better somehow?
>
>www.betterjpeg.com
>
>It's just a program for editing jpegs without causing generational loss.
>It came out some years ago, but I found it tended to crash so in the end I
>didn't buy it, possibly there's an improved version out by now as it's a
>couple of years ago that I was trying it. Its editing abilities were very
>simple, probably no better than irfanview's in fact, but its attraction was
>that editing didn't cause any generational loss.
>
>There are a whole bunch of specialist programs like this around, another
>one is JPEG Wizard (I think that's its name) which allows you to adjust the
>quality setting on a tile by tile basis so that important parts of the
>picture (eg. the subject) are saved at high quality and unimportant stuff
>(eg. the background) at low quality to optimise space. I have a feeling
>that it may also have offered similar featured to BetterJpeg re. lossless
>editing.
>
>Programs that I do use quite a bit are Jpegcrop and Jpegjoin, which are
>freeware programs that can losslessly crop, rotate, or stitch together
>jpegs (to make panoramas). (Of course, Irfanview can do lossless rotation,
>but not lossless cropping or panorama making (unless these have been added
>since I last upgraded)). As with BetterJpeg the secret is simply to deal in
>whole tiles and manipulate the data in its compressed form, rearranging the
>tiles or aggregating them into new pictures.
None of them can retain the full image information when doing rotations and
permutations on anything other than image dimensions in multiples of 8-pixels.
Always losing some image data no matter what they do. "Lossless" they are not.
They should be more truthful and call their methods "almost lossless".
Photoline has no such drawbacks.
David J Taylor
[]
> Programs that I do use quite a bit are Jpegcrop and Jpegjoin, which
> are freeware programs that can losslessly crop, rotate, or stitch
> together jpegs (to make panoramas). (Of course, Irfanview can do
> lossless rotation, but not lossless cropping or panorama making
> (unless these have been added since I last upgraded)). As with
> BetterJpeg the secret is simply to deal in whole tiles and manipulate
> the data in its compressed form, rearranging the tiles or aggregating
> them into new pictures.
Yes, IrfanView 4.20 can now do lossless crop, with a plug-in.
David
David J Taylor
> "David J Taylor" <david-...@blueyonder.neither-this-part.nor-this-
> bit.co.uk> wrote:
>
>> Marty Fremen wrote:
>
>>> *JPEGs are made up of 8x8 or 16x16 pixel tiles.
>>
>> No, JPEG 2000 uses wavelet transforms instead of DCT:
>
> lossless editing of normal jpegs.
OK, that hadn't been completely clear.
The existance of lossless JPEGs seems to be not that widely known....
David
Chris Malcolm
You can do lossless editing of jpegs without requiring the jpeg
compression itself to be lossless.
Jpeg compression is like a quality window of a certain size. If you
use editors which can produce jpegs of substantially higher quality
level than your camera does, you can load, edit, and save your jpeg at
least a few times without any loss due to jpeg compression simply
because you're working at a higher jpeg quality level than your
camera.
I've done that with ex-camera highest quality 14MP jpegs of around
5MP, using editors capable of at least 15MB jpeg output of images of
that size (when detailed enough), and found that looking for losses
very carefully indeed at pixel level have failed to find any in three
successive edits and recompressions of such images. I haven't tried
more than three simply because in my current workflow I never need to
do more than three. I've checked very carefully because I can get free
editors which do all I want on jpegs, and I'd have to pay a lot of
money to buy editors which would allow me to avoid working in
jpegs. If that money won't buy me noticeably better image quality I'd
prefer to spend the money on photographic hardware which will improve
my image quality.
--
Chris Malcolm
David J Taylor
[]
> You can do lossless editing of jpegs without requiring the jpeg
> compression itself to be lossless.
Of course, but there was confusion on this thread earlier.
> Jpeg compression is like a quality window of a certain size. If you
> use editors which can produce jpegs of substantially higher quality
> level than your camera does, you can load, edit, and save your jpeg at
> least a few times without any loss due to jpeg compression simply
> because you're working at a higher jpeg quality level than your
> camera.
Yes, I've seen the same, but I would normally save to a lossless format
(e.g. PNG) if I was doing something really critical.
> I've done that with ex-camera highest quality 14MP jpegs of around
> 5MP, using editors capable of at least 15MB jpeg output of images of
> that size (when detailed enough), and found that looking for losses
> very carefully indeed at pixel level have failed to find any in three
> successive edits and recompressions of such images. I haven't tried
> more than three simply because in my current workflow I never need to
> do more than three. I've checked very carefully because I can get free
> editors which do all I want on jpegs, and I'd have to pay a lot of
> money to buy editors which would allow me to avoid working in
> jpegs. If that money won't buy me noticeably better image quality I'd
> prefer to spend the money on photographic hardware which will improve
> my image quality.
I've been rather lower down the scale of images - my typical DSLR 6MP JPEG
has been 1.5-2MB, using the "standard" compression rather than "fine". A
10MP DSLR JPEG with the same compression is coming in at around 2.5-3MB.
Using the lower compression values in the low-cost Paint Shop Pro it's
easy to "double" those file sizes, so I could probably get similar results
to you. As a general principle, though, I try and avoid post-processing,
and try to "get it right first time".
Cheers,
David
HEMI-Powered
You could be entirely right, David. I did go back up into the full
paragraph to try to figure out where the asterisk was for his
footnote about the 8x8 and 16x16 blocks and thought I had it right,
but maybe not. The confusion in all of this is why I asked so many
questions about "new" JPEG specs, such as "BetterJPEG" I'd never
heard of before.
Frankly, I've never even tried JPEG2000 because a) Usenet and
things like normal folk E-mail doesn't support it well and b) the
compression is much less.
HEMI-Powered
jour ...
> There were some issues with the lower JPEG compression levels
> not working correctly in some versions of Paint Shop Pro -
> possibly PSP8 or PSP-9, but I no longer have the details to
> hand. It might be worth a Google search....
Yes, both 8 and even 9 have some issues. PSP 8, my last beta test,
had real bad problems at a compression setting of only 1 and could
have problems as high as 5. As I recall, 9 mainly had an issue at
1. Why exactly anyone would even want to go that low is beyond me
if LZE TIFF works, except that one cannot save EXIF to a compressed
TIFF.
> Yes, I appreciate your reduced pixel mode compared to full
> camera resolution, and I think that will need a lower JPEG
> compression to show the equivalent amount of artefacts
> compared to a full camera resolution image.
>
I'm not a techie on this, David, nor do I have your graphics or
photography expertise, but I would think that at least one reason
why artifacts are less visible is that there so many more millions
of pixels for JPEG to choose from AND the image size is so huge on
any real monitor that one is likely to only see it at a reduced
size where the defects are harder to spot.
Cheers!
HEMI-Powered
jour ...
>> original data better somehow?
>
Thanks.
> It's just a program for editing jpegs without causing
> generational loss. It came out some years ago, but I found it
> tended to crash so in the end I didn't buy it, possibly
> there's an improved version out by now as it's a couple of
> years ago that I was trying it. Its editing abilities were
> very simple, probably no better than irfanview's in fact, but
> its attraction was that editing didn't cause any generational
> loss.
What I cannot understand - but do not dispute - is why one would
want multiple graphics apps depending on the problem(s) du jour.
I mean, the littler apps must be less capable overall, aren't
they? And, isn't there a huge learning curve for a production app
like PS or PSP plus Irfanview plus maybe (now) Photoline and
Betterjpg?
> There are a whole bunch of specialist programs like this
> around, another one is JPEG Wizard (I think that's its name)
> which allows you to adjust the quality setting on a tile by
> tile basis so that important parts of the picture (eg. the
> subject) are saved at high quality and unimportant stuff (eg.
> the background) at low quality to optimise space. I have a
> feeling that it may also have offered similar featured to
> BetterJpeg re. lossless editing.
For us simple folk that just enjoy things like collecting car
pictures but are neither pros nor excessively anally retentive on
the absolute best quality, aren't specialty programs overkill?
Again, I'm not dissing you or anyone who finds them useful, but
Honest to God, defects happen so rarely for me that they are FAR
overshadowed just by my own lack of expertise and inability to
use RAW.
But, I AM always on the lookout for new ideas so I do muchly
appreciate you taking time to explain this. Sure hope the OP
hasn't gone unconscious by now! <grin>
> Programs that I do use quite a bit are Jpegcrop and Jpegjoin,
> which are freeware programs that can losslessly crop, rotate,
> or stitch together jpegs (to make panoramas). (Of course,
> Irfanview can do lossless rotation, but not lossless cropping
> or panorama making (unless these have been added since I last
> upgraded)). As with BetterJpeg the secret is simply to deal in
> whole tiles and manipulate the data in its compressed form,
> rearranging the tiles or aggregating them into new pictures.
>
Since you're already doing a good job in edumacating me, can you
tell me what your workflow might be that would require 2, 3, 4 or
more separate specialty apps? Or, are you suggesting that it is
only when you come across a toughie, as I do occasionally, that
you want to switch over to something more suited to the
particular problem?
Again, thanks for enlightening me, Marty.
HEMI-Powered
jour ...
> Marty Fremen wrote:
I need to Google for that to replace my 4.10 ...
Zack Torgens
>David J Taylor <david-...@blueyonder.neither-this-part.nor-this-bit.co.uk> wrote:
>> Marty Fremen wrote:
>>> "David J Taylor" <david-...@blueyonder.neither-this-part.nor-this-
>>> bit.co.uk> wrote:
>>>
>>>> Marty Fremen wrote:
>>>
>>>>> *JPEGs are made up of 8x8 or 16x16 pixel tiles.
>>>>
>>>> No, JPEG 2000 uses wavelet transforms instead of DCT:
>>>
>>> As noted in my other post I wasn't talking about lossless jpegs, but
>>> lossless editing of normal jpegs.
>
>> OK, that hadn't been completely clear.
>
>> The existance of lossless JPEGs seems to be not that widely known....
>
>You can do lossless editing of jpegs without requiring the jpeg
>compression itself to be lossless.
This occurs in only one editor that I know of, Photoline. Because it doesn't use
the standard method of putting the whole image back through the JPG compression
routine each time you save it.
>
>Jpeg compression is like a quality window of a certain size. If you
>use editors which can produce jpegs of substantially higher quality
>level than your camera does, you can load, edit, and save your jpeg at
>least a few times without any loss due to jpeg compression simply
>because you're working at a higher jpeg quality level than your
>camera.
>
>I've done that with ex-camera highest quality 14MP jpegs of around
>5MP, using editors capable of at least 15MB jpeg output of images of
>that size (when detailed enough), and found that looking for losses
>very carefully indeed at pixel level have failed to find any in three
>successive edits and recompressions of such images. I haven't tried
>more than three simply because in my current workflow I never need to
>do more than three. I've checked very carefully because I can get free
While what you say does minimize new JPG artifacts being introduced into an
image, even at the lowest (non-lossless) settings the JPG compression routine,
has to, by its very nature, invent new pixel data working from the previous
compressed data. Do it again and you are laying down another layer of
compression that is based on the last compression done. And so forth. This is
why I'm glad I found an editor that doesn't do that and treats JPG images much
like any other lossless format. Now I don't have to resave my edited images in
some other format when I use JPG-only output from any camera, or worry if
someone won't be able to view it on their computer. If I only work on part of an
image I am assured that only that part of the image will be put through the same
compression method as was used originally. The unedited portions are retained,
pixel for pixel, with zero change through hundreds of JPG resaves, if so needed.
>editors which do all I want on jpegs, and I'd have to pay a lot of
>money to buy editors which would allow me to avoid working in
>jpegs. If that money won't buy me noticeably better image quality I'd
>prefer to spend the money on photographic hardware which will improve
>my image quality.
A wise idea. You can become addicted to editing, wrongly thinking you can fix
all images that way. When what really counts is getting the photograph correct
in the camera in the first place. Even more important than hardware is honing
your talent, then any camera can produce a masterpiece. Just as those who
wrongly think they can fix everything in editing, they also wrongly think that
if they just had the right camera they'll become a pro one day. It's never about
the cost or quality of your photography equipment, it's what you can do with it.
Chris Malcolm
Obviously that suits the kind of editing you do. It wouldn't be of any
benefit to me, because I nearly always do editing operations which
involve the entire image.
>>editors which do all I want on jpegs, and I'd have to pay a lot of
>>money to buy editors which would allow me to avoid working in
>>jpegs. If that money won't buy me noticeably better image quality I'd
>>prefer to spend the money on photographic hardware which will improve
>>my image quality.
> A wise idea. You can become addicted to editing, wrongly thinking you can fix
> all images that way. When what really counts is getting the photograph correct
> in the camera in the first place. Even more important than hardware is honing
> your talent, then any camera can produce a masterpiece. Just as those who
> wrongly think they can fix everything in editing, they also wrongly think that
> if they just had the right camera they'll become a pro one day. It's never about
> the cost or quality of your photography equipment, it's what you can do with it.
I agree with you. What I mostly do in editors is stuff that can't be
done by "getting it right in camera", because its kinds of processing
not available in camera.
--
Chris Malcolm
David J Taylor
[]
> It's really only an occasional thing, where I want to modify a jpeg
> and want to avoid further loss without the overhead of saving it as
> PNG or TIFF which is likely to increase file size up to 10 fold. The
> only one of the programs I mentioned that I use with any regularity
> is jpegcrop for lossless cropping, for instance this is useful when
> cropping pictures which are going to sent to an online printing
> service, since a lot of these places only accept JPEGs (and even if
> they accept TIFFs, the upload time is a pain).
jpegcrop is a favourite of mine as well.
David
HEMI-Powered
jour ...
>> Since you're already doing a good job in edumacating me, can
>> you tell me what your workflow might be that would require 2,
>> 3, 4 or more separate specialty apps? Or, are you suggesting
>> that it is only when you come across a toughie, as I do
>> occasionally, that you want to switch over to something more
>> suited to the particular problem?
>
> It's really only an occasional thing, where I want to modify a
> jpeg and want to avoid further loss without the overhead of
> saving it as PNG or TIFF which is likely to increase file size
> up to 10 fold. The only one of the programs I mentioned that I
> use with any regularity is jpegcrop for lossless cropping, for
> instance this is useful when cropping pictures which are going
> to sent to an online printing service, since a lot of these
> places only accept JPEGs (and even if they accept TIFFs, the
> upload time is a pain).
OK, that seems reasonable, Marty. As I said, this is also rather
rare for me and as long as I use a little less compression than
the original as judged by re-edit file size, I've never seen
noticable damage.
The only time I save to a lossless format is for work-in-progress
stuff, and then I usually use the proprietary pspimage file
because it supports all the neat stuff including vector text,
layers, and the like. It'd be even nicer if the undo history
stuff were also saved but it is not.
I also use simple BMP files for "raw" scans because it is fast
and reliable.
> In summary, being able to crop or otherwise tweak an image
> without generational loss is basically useful where you only
> have a jpeg to start with and the end result is also required
> to be a jpeg for whatever reason.
>
In my case, it is usually something I spot later actually wrong
with the photographic part, like some distractions I want to
clone out, maybe a hot pixel or two, things like that. Relatively
minor stuff, but occasionally I'll spot noise or something I
hadn't seen before. But, if the changes are at all extensive OR I
want to do a radical crop, I'll go back to the original camera
image and start over.
Now, I KNOW that leveling an image multiple times and things like
fixing perspective distortion iteratively can produce damage, but
I've never seen it nearly bad enough to stop doing what I think
can improve the visual quality of the photo, even if technical
quality may suffer. But, in those cases, it isn't a JPEG issue at
all, but more an aliasing issue and/or a simple resampling issue
of the in-memory bitmap.
Can't say I can come within a country mile of your expertise, but
I sure wish I could! Have a good day.
Topaz
>
> - Tekst uit oorspronkelijk bericht weergeven -
This is the OP speaking.
Just like to thanks the people here for all ther effort in trying to
help; it seems that brief answer to my question is no. Although, at
the resolutuion of a typical photo (5Meg):
The theortical size is 2560 x 1920 x 24 = 117 964 800 (Irfan status
bar)
The actual size on file i = 2 395 425 (Windows file properties)
The average bits per pixel = 4 (Irfan EXIF)
This probably tells me something . . .
Anyway, you folks seem to be enjoying yourselves without me :-)
Have a good day!
HEMI-Powered
> This is the OP speaking.
> Just like to thanks the people here for all ther effort in
> trying to help; it seems that brief answer to my question is
> no. Although, at the resolutuion of a typical photo (5Meg):
> The theortical size is 2560 x 1920 x 24 = 117 964 800 (Irfan
> status bar)
That is 4,915,200 pixels which would be about 15MB for the in-
memorry bitmap using 24 bit color with 3 bytes per pixel. If
Irfanview is showing 17MB then there are other things taking up
the space besides just the pixels, the header info, and EXIF.
Examples might be many other things in the alpha channel of the
image such as vector graphics, layers and the like.
> The actual size on file i = 2 395 425 (Windows file
> properties) The average bits per pixel = 4 (Irfan EXIF)
What file type has these properties, JPEG? Bits or bytes per
pixel have no real meaning beyond a completely uncompressed
image, but think about it this way: for 24 bit color - 16.7
million colors - each of 3 bytes for the red, green, and blue
channels can have only 256 variations (0 to 255 in binary) and
256 x 256 x 256 = 16.7 million. Thus, for example, any true gray
scale can only have 256 shades of gray since all 3 channels must
be the same.
However, once JPEG does it's magic, all bets are off. EXIF is
rather small even with a thumbnail that Windows can see and so is
a JPEG header. The rest are the "mangled" pixels that have been
processed according to the user's compression and chroma
subsampling settings - and the nature of the image bitmap itself
- and hundreds of thousand, maybe millions, of bytes of data
representing even millions of pixels have been discarded.
Following this to it's conclusion, one can see that if the image
is compressed enough - meaning a LOT of pixels have been
"lossy"'d away, then the image is not much more than one big
blob.
>
> This probably tells me something . . .
What?
> Anyway, you folks seem to be enjoying yourselves without me
> :-) Have a good day!
>
Treads have a life of their own, but I honestly do not recall you
coming back in after the very beginning when everyone told you
that it just isn't possible to recover the compression factor
from EXIF or anyplace else. I gave you some ideas on how to
compensate for this as did others. It is entirely up to you
whether you want to listen or not. Beyond that, yes, the
discussion became quite esoteric and mathematical. Certainly
beyond my technical abilities, yet I learned a great deal.
If you're still confused by anything, jump back into this thread
OR start a new one. The same people will likely help you further.
Good luck and have a great day!
phil-abrahms
>Treads have a life of their own, but I honestly do not recall you
>coming back in after the very beginning when everyone told you
>that it just isn't possible to recover the compression factor
>from EXIF or anyplace else.
I was wondering why everyone was still going on about it after this was posted
on the very first day. It's that DOS program you asked about. It analyzes the
JPEG compression in a photo. You must have missed this.
On Mon, 17 Nov 2008 11:15:07 -0600, KentTR <ken...@somedomain.com> wrote:
>On Mon, 17 Nov 2008 10:42:58 -0600, "HEMI-Powered" <no...@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
HEMI-Powered
jour ...
> I was wondering why everyone was still going on about it after
> this was posted on the very first day. It's that DOS program
> you asked about. It analyzes the JPEG compression in a photo.
> You must have missed this.
Guess I did as I know of no way to determine the nature of the
compression algorithm used in a JPEG file. After all the
gibberish in the dump below, this little DOS utility purports to
say that the quality is 96?! First of all, the number is
backasswards as the JPEG spec is 1 highest to 100 lowest, and not
the normal way that percentage-like numbers are thrown around.
So, please explain again, since I missed it and apparently so did
the OP, how looking at remaining pixels after tons of them have
been "lossied" away permanently exactly where any information is
even available for analysis? The best I could guess might be to
try to examine and evaluate the types of pixel blocks left over
after the compression and do some sort of reverse engineering on
them to do a theoretical calculation of the original compression
spec. And, while I may still be missing it, I don't see anything
about chroma subsampling which plays a big role in all of this,
as does the very nature of the individual image.
--
Topaz
I didn't get back right away because I don't check this group so often
and I was rather overwhelmed by the quantity and technical nature of
the replies. For which again, my thanks; especially for HP's short
explanation of the output I posted earlier.
For info, the file I whose details I quoted was a JPEG.
It was quickly clear to me that the answer to
>> 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 ?
was almost certainly no, nothing meaningful.
I have also learnt a lot here, for example I was sent Googling for
chroma (sub)sampling.
But I could not make much sense of the output from the "magic" DOS
analyis program !
Greetings.
HEMI-Powered
> I didn't get back right away because I don't check this group
> so often and I was rather overwhelmed by the quantity and
> technical nature of the replies. For which again, my thanks;
> especially for HP's short explanation of the output I posted
> earlier. For info, the file I whose details I quoted was a
> JPEG.
Glad I could be of help, Topaz. As I said last time, for good or
for bad, threads can take on a life of their own which often
overwhelms an OP who just has a basic question and isn't
interested in really long, esoteric dissertations. Trust me, I
was pretty well snowed by the math myself so I tried to ask
clarifying questions along the way.
> It was quickly clear to me that the answer to
>>> 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 ?
> was almost certainly no, nothing meaningful.
>
> I have also learnt a lot here, for example I was sent Googling
> for chroma (sub)sampling.
Chroma is another buzz word for "color quality" so this parameter
guides the mathematics of the JPEG algorithm according to what it
"sees" for the type of colors in the image including the full
range of brightness/contrast and the HSL (Hue, Saturation,
Lightness) color model. If you don't want to mess up your images,
be wary of going much below 2x2 1x1 1x1. I have settled on 1x2
for nearly all of my images which I find is an excellent
compromise between final file size and quality. 1x1 1x1 1x1 is
considered none, which looks more/only at the pixels themselves
and results in the highest possible quality at a given
compression number but also the largest file size. As you go down
the list, file sizes get smaller and smaller but quality begins
to suffer. The idea is to give the user, i.e., presumed to be the
photographer, maximum flexibility.
> But I could not make much sense of the output from the "magic"
> DOS analyis program !
> Greetings.
>
Me, neither!
What have you concluded from all this?
Marty Fremen
> It was quickly clear to me that the answer to
>>> 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
>>> ?
> was almost certainly no, nothing meaningful.
The bits per pixel value is actually meaningful as a quality indicator, as
it is a nominal value that indicates the largest size that the compression
setting in use would produce. For instance the images from my Nikon camera
all state 4 bits per pixel in the EXIF, but my calculations show the actual
bits per pixel achieved vary from about 0.8 - 4 depending on the complexity
of the image, with a typical value being about 3.
However I don't know how to translate these nominal bits per pixel values
into the conventional 0-100 JPEG quality settings. However ISTM from
experimentally recompressing images that "4 bits per pixel" quality is
around the same as Irfanview's 95% setting with chroma subsampling
disabled.