Re:
>Barry Watzman wrote:
>> I think TIFF is a mistake; I'd use JPEG, at about 5K to 10K per square
>inch for color, or about 1/3 that for monochrome.
>
>Umm, ten thousand dpi!?
I don't think so--that's 10K per "square inch". Linear resolution would be
the square root of that--100 dpi, no?
Cheers,
Chuck
***************
You are not reading what I said.
I never said ANYTHING about "pixels".
When I said 10K per square inch, that was not a reference to "pixels", it
was a reference to finished JPEG file size. E.g. 10,000 BYTES total file
size per square inch. You can do that with 100 dpi resolution, and you can
do that (using a lot more compression) with 600 dpi resolution. But I have
found that if you have a JPEG whose total file size is 5,000 to 10,000 bytes
per square inch (500k to 1 megabyte for an 8.5" x 11" color page), then in
my experience there will be NO detectable degradation compared to a lossless
file format, for purposes of viewing, printing or OCR (but monochrome images
can be a lot smaller than that).
Again, the file size of a JPEG file is independent of resolution, the issue
is "how much compression are you going to use". And I have no argument that
if you use too much compression, the quality will be crap.
But, at the same time, there is too much emotion connected with the fact
that JPEG is "lossy" and TIFF is "lossless". If neither a person nor an OCR
program can detect a difference, then the "losses" can be concluded to be
both insignificant and irrelevant. It's not like an executable program
where all losses are absolutely unacceptable. JPEG can be crap if you use a
lot of compression, but if you don't get carried away and keep the
compression low to moderate, I maintain that a JPEG file is
indistinguishable from a TIFF file for all practical purposes.
By the way, several people have asked what resolution I scan at, and the
answer is 300 DPI MINIMUM for everything, but I sometimes scan at 600 dpi if
there is extremely fine detail present. I've used 600 dpi for some
schematics where the "original" in a manual was a blueprint-sized page
reduced to 8.5" x 11" (or even 11" x 17") and it was already at the point
where you needed a magnifying glass to read it.
I have recently went looking through my crap draw, and have come across
two things of interest:
an ATI GRAPHICS SOLUTION CGA/MDA video card. The only noticable defect
is a damaged componet (capicator?) on the corner.
An EGA/VGA 2-in-1 card. Dunno how it handles VGA modes with a EGA
monitor, cause I don't have a EGA monitor or a ISA box without
integrated video.
A complete, working ESDI drive and controller. I can't use it cause I
dunno what the hell the settings are. Image:
http://segin.no-ip.org/computers/ (look near the bottom)
An old MIDI program for Windows 95/98, called "CakeWalk Professional 7".
Dunno if that's intresting, but I need the serial code for it (it has a
serial AND a CD-KEY... I have the key on the original slimline jewel
case)... And no, this isn't a warez beg.
--
The real problem with C++ for kernel modules is: the language just sucks.
-- Linus Torvalds
> Does anyone here know what the exact procedure is to generate an RSX-11M 3.2
> system from distribution RL01s to an RL02?
I'll check if I have a 3.2 sysgen manual.
Of 75 emails this morning, 44 (including 4 of mine) were on the subject of
PDP-8 memory. From those only two provided any information on the subject.
A few were well off track. Signal to noise -13db! In any other media
that far down in the noise would be an unreadable signal.
Allison
Re: I thought PDF's could just be used to *encapsulate* regular TIFF's?
I.e., in much the same way that they can encapsulate JPEGs, etc.
It can; in fact, when you create a PDF from a scanner, encapsulation is all
that Acrobat is doing, it's the scanner software that determines the format,
which can be tiff, jpeg or some other formats that the scanner software
supports. But by default, it is almost always JPEG.
Murphy's having some real fun with me this week...
It seems that the failure of the outside world to access Blue Feather's FTP site was only the beginning. Within a couple of hours after I started troubleshooting last night, I discovered that our entire domain, including mail and web servers, had disappeared from the 'net.
The problem turned out to be (and I never saw this coming) -- our firewall/router! It had, apparently, decided that it was simply going to give up the ghost, and not give ANY indication in its (alleged) self-diagnostics.
No amount of power-cycling has fixed it, so I am going to replace it. Post-haste, I would add. The original unit was a Watchguard Firebox II that I got as a freebie, but Watchguard's current products are way too expensive for my tastes.
If anyone knows of a good, solid VPN router, in the $400-$500 (max) range, with at least the following features I would appreciate hearing about it. I'm currently looking at Zyxel (the Zywall 5) and Multitech (RouteFinder 830).
--Must support 1:1 NAT mapping.
--Must support at least IPSec VPN with 3DES or AES encryption, and the VPN client must be low-cost or included.
--Preferably, should also support PPTP for when IPSec is blocked at the originating end (I've seen it happen).
--Must be RACK-MOUNTED, as in it has rack ears or brackets. This is NOT negotiable.
--The manufacturer must NOT, unlike Watchguard and Juniper Networks, nickle-and-dime its users to death for extra features.
Thanks much, and I apologize for the hassles. I never saw this one coming...
-=-=-=-=-=-=-=-=-=-=-=-
Bruce Lane, Owner & Head Hardware Heavy,
Blue Feather Technologies -- http://www.bluefeathertech.com
kyrrin (at) bluefeathertech do/t c=o=m
"If Salvador Dali had owned a computer, would it have been equipped with surreal ports?"
Re:
I think his point was "adjust quality factor so resulting
image file has a size of ~10KB per sq in of original document".
E.g., A size is ~90 sq in so target a 1MB file size.
(note that this would correspond to an UNCOMPRESSED TIFF scanned
at 300dpi! -- did I do the math right? -- in which case, the
whole argument starts to fall apart since a 300dpi TIFF
*compressed* would be much smaller! Or, for that given size,
a COMPRESSED TIFF could be scanned at a much higher resolution)
****************
You do understand what I was saying; unlike others, you understood that I
was talking about resulting file size, not pixels. However, in the last
paragraph, you missed one point, which was that my guideline of 5k to 10K
per square inch was for color photographs. For monochrome, I cut that by
2/3, so my guideline becomes more like 1.5k to 3k per square inch. And this
is very conservative, for files that will be, for all practical purposes,
indistinguishable from the original. For many if not most uses, you can
actually go a lot smaller.
>
>Subject: Re: PDP-8 /e/f/m memory
> From: Don <THX1138 at dakotacom.net>
> Date: Tue, 15 Aug 2006 09:36:04 -0700
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Allison wrote:
>>> But cache RAM is power hungry and has little practical chance
>>> of being converted to BBSRAM
>>
>> Most are not, few if any of mine are not. NOTE: many of those rams
>> are CMOS and at high cycle rates the power needed is impressive but
>> in standby and low cycle rates the power drops significantly! Often
>> they are spec'd at they fastest cycle time for power use as thats how
>> PCs used them.
>
>CMOS power dissipation is a direct function of clock frequency.
>*But*, you will find that at DC (which is where the device
>operates when in sleep mode) there are huge differences in the
>static Icc between different grades of SRAMs -- from the same
>manufacturer and P/N.
I thought I'd said that. Bit of work history, engineer and product
engineer for a semi company that sold micros and ram.
Allison
>
>Subject: Re: PDP-8 /e/f/m memory
> From: Don <THX1138 at dakotacom.net>
> Date: Tue, 15 Aug 2006 09:33:25 -0700
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>> Because most batteries have shelf life! The average battery dies in
>> a few years from just sitting. The LI cells are designed for very long life.
>> I have a few sub-C sized LI cells that are over 15 years old and going strong.
>
>The shelf life (self discharge rate) of most batteries is *MANY*
>YEARS. The AAA cells I bought last year for my Visor have a
>"expiration date" of 2013.
While your wailing about your maglites your also talking about that
mere 7 year shelf life.
>A low power BBRAM design essentially falls below this self
>discharge rate (unless you get sloppy with the design).
>The real problem is ensuring that the batteries (i.e. the
>equipment that they are stored in) doesn't sit in
>temperature extremes, high humidity, etc.
Yes, I know this from my first CMOS design back in the late 70s.
Heat is a big factor even for the leakage current of the CMOS.
>And, if you're storing your '8 in those conditions, I suspect
>one of these days you'll be in for an unhappy surprise as
>you "suddenly" discover components that have fatigued
What has this to to do with the topic at hand?
Allison
I received the following email....
>We are still using 2 VAX 9440s and 2 9210 computer mainframes at our
>facility in Colorado Springs, Colorado. We are having problems finding
>some parts, MCUs for the CPUs. Any help is appreciated.
If anyone can help with parts for these machines please contact me off-list.
Jay
