Hi list,
I have to display a jpeg image (no PB for this) and also to print it,
however with PIL (or other ?) I know how to retrieve its size & DPI
but I don't know how to get its printing size?
JY
--
A woman's a woman until the day she dies, but a man's only a man as
long as he can. -- Moms Mabley
I always thought that unscaled print size = (WidthInPixels x DPI) by
(HeightInPixels x DPI)
On 14/01/2012 6:57 AM, Jean-Yves F. Barbier wrote:
Hi list,
I have to display a jpeg image (no PB for this) and also to print it,
however with PIL (or other ?) I know how to retrieve its size & DPI
but I don't know how to get its printing size?JY
Not at all, check with Gimp: scale image is ≠ from print scale;
some programs uses your formula, but most uses the print size
(that appears in the GD>Miscellany>Image info window).
That allows you to have ie: a 600x600 pixels image that only takes
110x110 monitors pixels but print on a square inch.
JY
On Sat, 14 Jan 2012 09:14:45 +0000 Gadget/Steve <GadgetSteve@live.co.uk> wrote:
I always thought that unscaled print size = (WidthInPixels x DPI) by
(HeightInPixels x DPI)
--
Take this with a grain of salt, but my understanding is that the DPI or resolution value stored in the image is what is to be used when scaling the image for printing. In other words, if the image's DPI is 300 and you have a 900x900 image then the optimal result should be 3 inch x 3 inch on the page. That means that if the printer's DPI is something like 600 then you'll want to scale the image before printing so the result is still 3in x 3in.
When displaying on screen the image's DPI is usually ignored and just the pixel size is used (unless the document is also scaling the image to fit in the window or something.)
On 1/14/12 7:07 AM, Jean-Yves F. Barbier wrote:
On Sat, 14 Jan 2012 09:14:45 +0000 > Gadget/Steve<GadgetSteve@live.co.uk> wrote:
I always thought that unscaled print size = (WidthInPixels x DPI) by
(HeightInPixels x DPI)Not at all, check with Gimp: scale image is ≠ from print scale;
some programs uses your formula, but most uses the print size
(that appears in the GD>Miscellany>Image info window).That allows you to have ie: a 600x600 pixels image that only takes
110x110 monitors pixels but print on a square inch.
--
Robin Dunn
Software Craftsman
Take this with a grain of salt, but my understanding is that the DPI or
resolution value stored in the image is what is to be used when scaling
the image for printing. In other words, if the image's DPI is 300 and
you have a 900x900 image then the optimal result should be 3 inch x 3
inch on the page. That means that if the printer's DPI is something
like 600 then you'll want to scale the image before printing so the
result is still 3in x 3in.
Unfortunately, the only part of your reasoning that is almost
universal is the display of the picture dot-per-dot (although,
gimp allows you to override this with an option that has the same
name:)
When displaying on screen the image's DPI is usually ignored and just
the pixel size is used (unless the document is also scaling the image to
fit in the window or something.)
But for the printing itself, it is a real mess.
This is why I need to retrieve this information, compare it with DPI
and process the picture depending on the backend used.
JY
On Sat, 14 Jan 2012 11:30:47 -0800 Robin Dunn <robin@alldunn.com> wrote:
--
Beam me up, Scotty, there's no intelligent life down here!
Probably nor really useful, but
A jpeg image, its internal structure, is more than just
a set of juxtaposed pixels. It must be viewed as a set
of "Fourier coefficients" (pixels blocks). Resizing
a jpeg image implies a resampling of the image in
the pixel space and the creation of a new image. This
is achieved through a Fourier transfomation. This also
explains why a jpeg resizing is a lossy process.
But for the printing itself, it is a real mess.
Not really. The usage is to have, to keep the source
image with its largest, original definition and to
reduce its size accordingly to the need. This can be
a "small" screen bitmap (in pixel) or a printed picture
(in cm) in a book. The image itself is dpi independent.
jmf
On 14 jan, 20:49, "Jean-Yves F. Barbier" <12u...@gmail.com> wrote:
One again, it is the theory... far from practice.
As it seems there's no solution, I'll ad a warning to users to
mind they're own image preparation.
JY
On Sun, 15 Jan 2012 10:55:56 -0800 (PST) jmfauth <wxjmfauth@gmail.com> wrote:
> But for the printing itself, it is a real mess.
Not really. The usage is to have, to keep the source
image with its largest, original definition and to
reduce its size accordingly to the need. This can be
a "small" screen bitmap (in pixel) or a printed picture
(in cm) in a book. The image itself is dpi independent.
--
Unitarians pray "To whom it may concern".
Let's be practical. If you can not print your image
in human dimensions with satisfaction, can be mm, inch,
pixel, didot or big point (LaTeX), that just means your
source image has not enough points. Like every bitmap image.
jmf
On 15 jan, 20:19, "Jean-Yves F. Barbier" <12u...@gmail.com> wrote:
On Sun, 15 Jan 2012 10:55:56 -0800 (PST) > > jmfauth <wxjmfa...@gmail.com> wrote:
> > But for the printing itself, it is a real mess.
> Not really. The usage is to have, to keep the source
> image with its largest, original definition and to
> reduce its size accordingly to the need. This can be
> a "small" screen bitmap (in pixel) or a printed picture
> (in cm) in a book. The image itself is dpi independent.One again, it is the theory... far from practice.
As it seems there's no solution, I'll ad a warning to users to
mind they're own image preparation.
Jean-Yves F. Barbier wrote:
I always thought that unscaled print size = (WidthInPixels x DPI) by
(HeightInPixels x DPI)
Well, it should be division, not multiplication. Pixels divided by
pixels/inch gives inches.
Not at all, check with Gimp: scale image is ≠ from print scale;
some programs uses your formula, but most uses the print size
(that appears in the GD>Miscellany>Image info window).That allows you to have ie: a 600x600 pixels image that only takes
110x110 monitors pixels but print on a square inch.
I believe you are misunderstanding something here. That could only
happen if you have the window zoomed out. There are no magic values in
a JPEG header.
Part of the problem might come from the fact that there is a DPI value
in the image, and there is a DPI value for each device on which it is
rendered. Let's say you have a 600x600 pixel image, and the header
records it as 100 DPI. When we display things in monitors, we usually
ignore the image DPI and render one dot per pixel. So, if you display
that image on a monitor that's running 96 DPI, it will appear on screen
at about 6" x 6".
If I do a dot-by-dot rendering to a printer that has a 300 DPI
resolution, which is what a standard BitBlt would do, it will print at
2" x 2", and appear way too small. Because we expect printed images to
honor the original DPI value, somebody somewhere has to rescale the
image so the DPIs match. That is, the 600x600 image at 100 DPI will
have to be scaled up to 1800x1800 at 300 DPI in order to print on our
printer at the desired size (6" x 6"). That has to be done by an
application. The printer won't do it. The printer doesn't understand
JPEGs, it only understands pixels.
If you have a 600x600 image, the only way it will show up as 110x110 on
your display is if you have the image zoomed out by 1:6.
Gadget/Steve <GadgetSteve@live.co.uk> wrote:
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
jmfauth wrote:
Probably nor really useful, but
A jpeg image, its internal structure, is more than just
a set of juxtaposed pixels. It must be viewed as a set
of "Fourier coefficients" (pixels blocks). Resizing
a jpeg image implies a resampling of the image in
the pixel space and the creation of a new image. This
is achieved through a Fourier transfomation. This also
explains why a jpeg resizing is a lossy process.
Well, that's glossing over a lot of rather important details. Inside
the JPEG, the image is stored as frequency levels, not as pixels. In
most images, the pixel values change gradually as we move across the
image, so the frequencies tend to be low. That's how we get such good
compression -- we convert to frequencies, then drop out the highest
frequencies. This also explains why text usually looks so bad in JPEG
-- good text requires sharp edges, and sharp edges mean high frequencies.
The Fourier transform is the way we convert between pixels and frequencies.
It is possible to rescale an image in the frequency domain, but most
image programs convert the images to uncompressed pixels as their very
first operation, then do all succeeding operations (including scaling)
with that array of uncompressed pixels, then convert back to JPEG before
saving to disk.
On 14 jan, 20:49, "Jean-Yves F. Barbier" <12u...@gmail.com> wrote:
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Well, it was an attempt to present the things a little bit
differently, assuming the reader/poster has some knowledge.
Sometimes, pointing on a specific point of a theory helps
to understand the whole theory.
I'm neither an image processing specialist, nor a jpeg
specialist. The day I found and read some articles
describing the jpeg structure. It was obvious to me.
I do not understand and I never take the time to understand
the whole implementation. However, the principle was
"sparkling" to me. This is exactly what we are doing
in time domain Fourier transform spectroscopy. (I wrote a
lot of software to proccess data on that field.)
Jgeg or FFT spectroscopy, the keyword is signal processing.
jmf
On 16 jan, 20:05, Tim Roberts <t...@probo.com> wrote:
jmfauth wrote:
> On 14 jan, 20:49, "Jean-Yves F. Barbier" <12u...@gmail.com> wrote:
> Probably nor really useful, but
> A jpeg image, its internal structure, is more than just
> a set of juxtaposed pixels. It must be viewed as a set
> of "Fourier coefficients" (pixels blocks). Resizing
> a jpeg image implies a resampling of the image in
> the pixel space and the creation of a new image. This
> is achieved through a Fourier transfomation. This also
> explains why a jpeg resizing is a lossy process.Well, that's glossing over a lot of rather important details. Inside
the JPEG, the image is stored as frequency levels, not as pixels. In
most images, the pixel values change gradually as we move across the
image, so the frequencies tend to be low. That's how we get such good
compression -- we convert to frequencies, then drop out the highest
frequencies. This also explains why text usually looks so bad in JPEG
-- good text requires sharp edges, and sharp edges mean high frequencies.The Fourier transform is the way we convert between pixels and frequencies.
It is possible to rescale an image in the frequency domain, but most
image programs convert the images to uncompressed pixels as their very
first operation, then do all succeeding operations (including scaling)
with that array of uncompressed pixels, then convert back to JPEG before
saving to disk.--
Getting really OT - particularly since most software will uncompress
the image before any re-sizing anyway, but...
Well, that's glossing over a lot of rather important details. Inside
the JPEG, the image is stored as frequency levels, not as pixels. In
most images, the pixel values change gradually as we move across the
image, so the frequencies tend to be low. That's how we get such good
compression -- we convert to frequencies, then drop out the highest
frequencies.
I'm pretty sure this is not quite correct -- jpeg doesn't drop the
high frequencies, unless at a really low quality setting - this is how
Wikipedia describes that step:
"""
The amplitudes of the frequency components are quantized. Human vision
is much more sensitive to small variations in color or brightness over
large areas than to the strength of high-frequency brightness
variations. Therefore, the magnitudes of the high-frequency components
are stored with a lower accuracy than the low-frequency components.
The quality setting of the encoder (for example 50 or 95 on a scale of
0–100 in the Independent JPEG Group's library[15]) affects to what
extent the resolution of each frequency component is reduced. If an
excessively low quality setting is used, the high-frequency components
are discarded altogether.
"""
most
image programs convert the images to uncompressed pixels as their very
first operation, then do all succeeding operations (including scaling)
with that array of uncompressed pixels, then convert back to JPEG before
saving to disk.
exactly -- if you do need "lossless" re-scaling, jpegtran is nice -- I
wish there were a python wrapper around it -- anyone know of one?
-Chris
On Mon, Jan 16, 2012 at 11:05 AM, Tim Roberts <timr@probo.com> wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
>most
> image programs convert the images to uncompressed pixels as their very
> first operation, then do all succeeding operations (including scaling)
> with that array of uncompressed pixels, then convert back to JPEG before
> saving to disk.exactly -- if you do need "lossless" re-scaling, jpegtran is nice -- I
wish there were a python wrapper around it -- anyone know of one?
Descrete Fourier Transformation Elements.
In natural language: What counts is not the operation(s)
you are applying: It is the domain in which you are
applying these operations that counts. An operation in one
domain has an impact in the transformed domain (mathematically,
this is called a convolution product).
Two practical (positive or negative) consequences of this
in data processing.
- Either this convolution penalizes. It implies a loss
of information.
- Or one can use the properties of the convolution to
deliberately model the data. This is filtering. Gain of
information.
Thanks to the trigonometric circle, the complexe analysis and
the discrete FT algorithm, some operations (rare and in any
way not to be generalized) reduce to simple geometrical
manipulations in the complexe z-plane in either domain. And
no loss of information. (jpegtran uses these cases - I very
quickly take a look at a tech. documentation in German I
found - )
Note: in numerical computing, the data (array of numbers)
are always convoluted, simply because there can be only a
finite number of points (convolution with a square function).
jmf
Chris Barker wrote:
On Mon, Jan 16, 2012 at 11:05 AM, Tim Roberts <timr@probo.com> wrote:
... That's how we get such good
compression -- we convert to frequencies, then drop out the highest
frequencies.I'm pretty sure this is not quite correct -- jpeg doesn't drop the
high frequencies, unless at a really low quality setting...
Yes, I should have said "attenuate the highest frequencies", not "drop
out", especially since I was being picky to begin with...
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.