Most widely available lossless format for documents?

[gruhn]

I forgot to mention that the above screen shots were made on an LCD
display,

Don't worry, it was self evident. Of course, it tends to break the validity
of the test...

 

[Donald Link]

I forgot to mention that the above screen shots were made on an LCD display,
with cleartype turned on. So, they will look very blurry on CRTs.

I do not know what crt you are using but my Sun Microsystem PC monitor
with a Sony tube displays them better than what the LCD does.

 

[Zarbol Tsar]

So this leaves me with a question in my mind that what you

Hm. Right; if 'DozeXP doesn't include Imaging, it certainly
includes some sort of application that's capable of viewing
TIFFs in G4 or LZW. When I was in Chennai last July, the folks
at the place I was visiting were all running vanilla 'DozeXP
with a minimum of 3rd-party apps installed, and they had no
problems opening and viewing G4 and LZW TIFFs without installing
any other software.

AFAICT WinXP uses the "Microsoft Fax and Picture Viewer" which is
most probably launched by right-clicking a graphics file and then
selecting this application.

It can theoretically be run by executing this command but strangely
there does not seem to be a way to then load a graphics file other
than by dragging it onto the application:

%windir%\System32\rundll32.exe
%SystemRoot%\system32\shimgvw.dll,ImageView_Fullscreen

It seems from http://snipurl.com/cgrl that this application can view
TIFF files

Perhaps MS Paint (launched by executing
%SystemRoot%\System32\mspaint.exe) offers more graphics formats that
the MS Fax and Picture Viewer. I don't really know.

 

[Zarbol Tsar]

Echo most of that ... with the caveat that both IrfanView and
ImageMagic are truly ***EXCELLENT*** software!

I know and very much like IrfanView. However, I have never come
across ImageMagick so I figure I would like to try it now.

At http://www.imagemagick.org/script/binary-releases.php? there is a
choice of four Windoes versions:

Dynamic at 16-bits-pixel
Static at 16-bits-pixel
Dynamic at 8-bits-pixel
Static at 8-bits-pixel

I have no real idea what the difference is. How do I choose which
one?

Furthermore the info on Imagemagick and WIndows to be found at
http://www.imagemagick.org/www/Install-windows.html
refers to single and multi threaded runtime support options. Er,
what?

Can someone kindly steer me through what choice(s) to make. Thank
you.

 

[Dances With Crows]

I know and very much like IrfanView. However, I have never come
across ImageMagick so I figure I would like to try it now.

ImageMagick is mostly command-line stuff. If you don't grok the
command-line, you might not like it. The default CMD.EXE shell on
Windows is absolutely horrible compared to the shells like bash, tcsh,
and zsh available on Unix-like systems. Fortunately, you can install
Cygwin and run bash on Windows, or you can boot from a Knoppix CD and
use bash there if you want to learn more about the command line.

At http://www.imagemagick.org/script/binary-releases.php? there is a
choice of four Windoes versions:
Dynamic at 16-bits-pixel Static at 16-bits-pixel
Dynamic at 8-bits-pixel Static at 8-bits-pixel
I have no real idea what the difference is.

"Dynamic" and "static" refer to whether the executables rely on shared
libraries ("DLLs" in Windows-speak) or the executables have the
necessary libraries built in. Static executables are larger and usually
less memory-efficient. The 16-bpp version will handle images that have
16 bits/pixel. Most of the images you see only have 8 bits/pixel, but
16 is becoming more popular since some scanners will scan at that bit
depth and the greater dynamic range makes some editing tasks easier.
Video cards *still* only grok 8 bits R, 8 bits G, and 8 bits B though.

Furthermore the info on Imagemagick and WIndows to be found at
http://www.imagemagick.org/www/Install-windows.html refers to single
and multi threaded runtime support options. Er, what?

"Single thread" and "multi thread" are fairly standard programming
terms. A single-thread executable can only respond to one event at a
time, and may respond sluggishly to user input if the user puts in a lot
of input while the executable is performing CPU or I/O-intensive work.
A multi-thread executable has 2 or more "threads". Each thread can
perform work at the same time[0], which makes it possible for a
correctly written multi-thread program to accept user input with little
delay while it does CPU or I/O intensive work.

It's more difficult to write and debug a multi-threaded program than it
is to write and debug a single-threaded program. Lots of really useful
stuff (Firefox, OpenOffice, Gimp, etcetera) is multi-threaded because
the advantages outweigh the extra programming and debugging time needed.
Many small, short programs (grep, tr, sed, etcetera) are usually
single-threaded because A) they typically execute quickly B) multiple
threads wouldn't help them much.

Can someone kindly steer me through what choice(s) to make.

The 8-bit dynamically-linked version, unless you need to work with 16
bpp images. If you need to do that, use the 16-bit dynamic one. HTH,

[0] Not really, unless you have multiple CPUs. In all modern OSes, the
kernel divides up the available CPU time into timeslices, and assigns
each running process a set of timeslices based on process priority,
whether the process is sleeping or not, the phase of the moon, and some
semi-complex and clever math. Timeslices are short (~25-100
milliseconds, usually) though, so a modern computer can *appear* to be
doing lots of things at once, even though it's really doing thing X
for 1/20 of a second, doing thing Y for 1/20 of a second, doing thing Z
for 1/20 of a second, doing thing X... etcetera. If you have 2 or more
CPUs, 2 or more processes can run at the same time. This can be useful
for obvious reasons.

 

[Andrew Morton]

However, text should be saved as text - an OCR program can translate

Really? If it's handwritten? Mathematical equations? Different
language?

Yes. Handwriting is nearer to a drawing, so I wouldn't count that unless
only the text itself needs to be recorded. There are plenty of markup
languages for equations. In what way might a different language be a
problem? More information can be gleaned from a text file with language
settings in it than from an image, for example if I were editing something
flagged as being in English then I would know to spell colour as colour
whereas if it were flagged as American English I would spell colour as
color.
Getting a bit off-topic for this newsgroup.

Andrew

 

[David Combs]

Allow me to to ask some surely-naive questions --
most probably answerable via an integer divide
mandated to have no remainder, or something
similar. But I was never any good at
being able to follow (understand) where books
would say thing like:

The reader can fill in the obvious steps.

..., which by elementary algebra simplifies to ...


... , which is clearly equivalent to a divide by zero.

So I'll be asking you to show the elided steps:



....

Most raster graphics file formats, in addition to being
an array of X by Y pixel data values, encode what
real-world dimensions the span of X and Y are intended
to represent.

GIF does not, and the default assumption is 72 dpi.
Unless the receiving/rendering app is smart enough to
ask the user (and rescale),

Ask the user what?

And then rescale to what, and why?


any GIF raster bigger than

about 576 x 756 won't print properly on US letter size

Why not? Could you show enough so that I can myself
do similar calculations and deductions for other such
situations. Thanks.

(allowing for some unprintable margin area).

So where does this get done, what part of the
math handles this?

So if you scan the 8x10.5 region of a letter-size
document at 300 dpi, you'll get a 2400 x 3150 raster.

A "raster" being what, a rectangle of pixels considered
by the printer software/hardware as being a single
print-level item?

If you save it as GIF, a "dumb" (and maybe not so
dumb) receiving app may think it's supposed to print
that at 33.33 x 43.75 inches.

Why might it think this?

In what way would a "smarter" app come to a different
conclusion, and how?

I just ran this experiment in Photoshop 7.0. Created
a 300 dpi 8x10.5 image. Saved it as .GIF. When it
re-opened, Photoshop thought it was a 33x44 inch image,

... because ...

and would have attempted to print it at that size.
Workaround?

Unless 72 dpi is ideal for the subject matter,

(such as?)

using
.GIF will cause extra work for recipients of the files,
when they attempt to print them.

Thanks!

David

 

[CSM1]

Comments in body.

Allow me to to ask some surely-naive questions --
most probably answerable via an integer divide
mandated to have no remainder, or something
similar. But I was never any good at
being able to follow (understand) where books
would say thing like:

The reader can fill in the obvious steps.

..., which by elementary algebra simplifies to ...


... , which is clearly equivalent to a divide by zero.

So I'll be asking you to show the elided steps:



...

Ask the user what?

What DPI to print the image at.

The final printed size depends on the pixel dimensions and the resolution
the printer is set to.

The math is:
Horizontal pixels divided by printer dpi setting = the inches of the printed
image in the horizontal dimension.

Vertical pixels divided by printer dpi setting = the inches of the printed
image in the vertical dimension.

A 2400 horizontal pixel by 3000 vertical pixel image will produce a
8 inch by 10 inch print on the paper when the printer resolution is set to
300 dpi.
2400/300=8
3000/300=10

And then rescale to what, and why?


any GIF raster bigger than

Why not? Could you show enough so that I can myself
do similar calculations and deductions for other such
situations. Thanks.


So where does this get done, what part of the
math handles this?

The unprintable margin area varies with the specific printer, it is the clos
est to the edge that a specific printer is capable to printing on the paper.

For my HP 712 the minimum margin is 0.25 inches on the right and left
margins and 0.04 inches on the top and 0.46 inches on the bottom when using
letter size paper.

You have to look up the specifications on your printer to find the minimum
margins.

You subtract the minimum margins of your printer from the paper size to find
what the maximum image size that can be printed with your printer.

For the HP 712 the maximum size I can print on letter size paper is 8.0
inches by 10.5 inches.

A "raster" being what, a rectangle of pixels considered
by the printer software/hardware as being a single
print-level item?

A "raster" being the actual image. A raster is the square dots that make up
the image. They are arranged in a rectangle H dots wide by V dots high.

Why might it think this?

In what way would a "smarter" app come to a different
conclusion, and how?



... because ...

Gif does not record the dpi in the header of the image file. Gif only
records the horizontal and vertical dimensions of the image and the color
information.

(such as?)

An arbitrary value chosen by just about everybody that writes image software
for Windows.

 

[Dances With Crows]

[ cross-posting trimmed ]
["Followup-To:" header set to comp.periphs.scanners.]

Allow me to to ask some surely-naive questions -- most probably
answerable via an integer divide mandated to have no remainder, or
something similar. But I was never any good at being able to follow
(understand) where books would say thing like:

The reader can fill in the obvious steps.

How did you make it through high school?

This isn't always true. TIFF does, BMP doesn't, JPEG doesn't unless the
info is in an EXIF tag.

Ask the user what? And then rescale to what, and why?

Ask the user what DPI to use, and rescale the image to that DPI, so
it'll fit on a printer page or satisfy the user's requirements.

Why not? Could you show enough so that I can myself do similar
calculations and deductions for other such situations. Thanks.

GIF resolution = 72 pixels/inch. 576 pixels / 72 pixels/inch = 8
inches. 756 pixels / 72 pixels/inch = 10.5 inches. This is a very
basic form of dimensional analysis, and you should've had that in high
school chemistry class.

So where does this get done, what part of the math handles this?

An application can query the printer filter ("printer driver") and ask
it "what is the maximum printable area on paper tray N?". The math can
be handled in the application or the printer filter. Most common
printers cannot print on the top 0.5" or bottom 0.5" of an 8.5x11" sheet
of paper.

A "raster" being what, a rectangle of pixels considered by the printer
software/hardware as being a single print-level item?

raster =~ "raster image". A raster image is a rectangular array of
pixels. "Single print-level item" may or may not be the case--don't
worry about it; that's what the hardware and middleware do.

Why might it think this?

See the paragraph where I talked about dimensional analysis. 2400
pixels / 72 pixels/inch = 33.33 inches.

In what way would a "smarter" app come to a different conclusion, and
how?

A "smart" application would query the printer filter, find out that the
maximum printable area of one page is much smaller than 33x44 inches,
then pop up a dialog box that said, "Image is much larger than page.
Scale image to fit on one page? (Y/N/Cancel/Whiskey)" The File->Print
menus of most consumer-level apps have dialog boxes/preferences/things
that allow you to apply "scale to fit page" to all the images you're
using.

... because ...

GIF does not store resolution info, so the DPI is always assumed to be
72. A 300 DPI 8x10.5" image is (8 inches*300 pixels/inch) = 2400 pixels
wide and (10.5 inches*300 pixels/inch) = 3150 pixels high. 2400 pixels
/ 72 pixels/inch = 33.33 inches, etcetera.

Workaround?

"Scale image to fit paper" in File->Print options or Edit->Preferences.

(such as?)

Not much. 72 DPI looks "too grainy" to most people. It'd be OK for
things that look boxy anyway, like flowcharts or very simple blocky
logos.

Aye, and GIF sucks because its color palette is limited.

 

[jjs]

What DPI to print the image at.

I never heard of DPI metric stored in an image, and if it is there, it's
just a handy metric for those who don't understand that pixels-is-pixels.

 

[Dances With Crows]

[ inappropriate crossposting trimmed ]
["Followup-To:" header set to comp.periphs.scanners.]

I never heard of DPI metric stored in an image,

Just 'cause you've never heard of it doesn't mean it doesn't exist. The
TIFF standard defines 3 tags, one for horizontal resolution, one for
vertical resolution, one for (pixels/inch, pixels/cm, unitless), and
that part of the standard's been around for at least 10 years. I
believe the JPEG guys have defined an EXIF tag or 2 that stores this
information, and GIMP's native format stores resolution data. TIFF's
resolution info is the most widely used because the format is
ubiquitous.

and if it is there, it's just a handy metric for those who don't
understand that pixels-is-pixels.

On CRT/LCD or on disk, pixels are pixels. When you want to transfer an
image from these "virtual" formats to a more "real" format like paper,
it can help to have pixels/inch data available because of real-world
considerations. If you want to reproduce a scanned image exactly, you
can do that more easily if you know the scanned image was originally
scanned at 600 DPI.

 

[gruhn]

I never heard of DPI metric stored in an image, and if it is there, it's

just a handy metric for those who don't understand that pixels-is-pixels.

Agree re: pixels, don't agree re: just.

If you scan something in, it has a definite "actual size". DPI is a way to
save that info. Shirley there are people and applications who find that far
handier than getting an image and guessing. Or storing the size in the file
name. Or...

 

[toby]

I never heard of DPI metric stored in an image,

I'm not sure what you mean. Many image formats -- from TIFF all the way
down through BMP -- have header fields specifically defined for
resolution info, and these are usually put to good use. In addition,
Photoshop typically uses whatever "application specific" data is
provided for in order to record its own "image resource" metadata,
which invariably includes resolution (and units).

Some images don't have meaningful physical dimensions (e.g. digital
camera grabs); but many do (e.g. scans).

and if it is there, it's
just a handy metric for those who don't understand that

pixels-is-pixels.

They also have pixel counts, of course.

 

[jjs]

Agree re: pixels, don't agree re: just.

If you scan something in, it has a definite "actual size". DPI is a way to
save that info. Shirley there are people and applications who find that
far
handier than getting an image and guessing. Or storing the size in the
file
name. Or...

Or being smart.

 

[gruhn]

Or being smart.

Explain how "just guessing wrong" is "smart."

 

[jjs]

Explain how "just guessing wrong" is "smart."

Guessing isn't neccessary; understanding simple arithmetic is smart enough.

 

[gruhn]

Guessing isn't neccessary; understanding simple arithmetic is smart
enough.

We're not having the same conversation as each other.

 

[Hecate]

Some images don't have meaningful physical dimensions (e.g. digital
camera grabs); but many do (e.g. scans).

All images have physical dimensions. On a computer they're expressed
as pixels. On a print the resolution is expressed as dpi. The dpi is
completely immaterial as far as an image on a computer is concerned.

 

[toby]

All images have physical dimensions. On a computer they're expressed
as pixels. On a print the resolution is expressed as dpi. The dpi is
completely immaterial as far as an image on a computer is concerned.

A pixel count is dimensionless. The resolution value gives a pixel a
physical scale. There's really nothing to discuss here - this is all
taken as read.

 

[gruhn]

A pixel count is dimensionless

No. Pixel is a valid unit. W x H pixels is grand as dimensions go.

The resolution value gives a pixel a physical scale

That's true. But "dimension" needn't by "real world."

There's really nothing to discuss here - this is all
taken as read.

I wrote nothing above.