scott@sage.uchicago.edu (Scott Deerwester) (05/19/89)
I've been enjoying Scene in both 0.8 and 0.9. As I write this, my
screen background is a photograph of a beach with palm trees... if I
could only get the DSP to do steel drums... I've done a bit of
hacking in PostScript to diddle with the brightness and contrast of
images (in the sense of PostScript's "image" operator), and thought
that others might be interested in similar diddling. To use this,
change x and y to the dimensions of your image, and bits to the number
of bits of grey scale (probably either 1 or 8). Brightness ranges
from -1 to 1, with lower numbers being darker, and 0 applying no
transformation at all to the image. Contrast is similar. Small
positive values (ranging from 0.1 to 0.3) for both have given me the
best results, especially for images that began life as color photos.
Insert your bitmap (a Whole Big Bunch of hex numbers) at the
appropriate place. Only caveat that I'm aware of is that if your
bitmap doesn't have as many elements as you said it did, you may
expect garbage to follow.
%!PS-Adobe-1.0
%%BoundingBox: 0.000 0.000 512.000 480.000
%
% Author:
% Scott Deerwester, University of Chicago
% Copyright:
% You may freely copy this code, provided that a copy
% of this notice is included with all copies.
%
/x 512 def % Number of columns
/y 480 def % Number of rows
/bits 8 def % Number of bits of grey scale
/brightness 0.3 def
/contrast 0.2 def
/picstr x string def
gsave
x y scale
{
% Uncomment the following line if your image looks like a negative
% 1 exch sub
brightness 0 ne
{
dup
brightness 0 gt
{
1 exch sub
} if
9 mul 1 add log brightness mul
1 brightness sub mul add
} if
contrast 0 ne
{
dup 360 mul sin contrast mul sub
} if
}
settransfer
x y bits
[x 0 0 y neg 0 y]
{currentfile picstr readhexstring pop}
image
% Insert your bitmap here
grestoremoore@PULSAR.FAC.CS.CMU.EDU (Dale Moore) (05/20/89)
Bounding Box and Floating point numbers. Scott Deerwester recently sent a message to comp.sys.next, and comp.lang.postscript. The message contained a PostScript program. A portion of the message is below >Insert your bitmap (a Whole Big Bunch of hex numbers) at the >appropriate place. [text deleted] > >%!PS-Adobe-1.0 >%%BoundingBox: 0.000 0.000 512.000 480.000 >% According to the document structuring conventions, a bounding box is an orderd set of four "integers". Now, the above numbers certainly look like floating point numbers. And we all know that floating point numbers aren't integers. I don't mean to pick on Scott Deerwester. Alot of the PostScript stuff that comes from Next suffers the same problems. But I've a couple of utilities that look at such things as "%%BoundingBox" and I wonder if I should reject these things for not being formatted properly. If I should accept these floating point numbers, should I round 'em off or truncate 'em? See, the spec doesn't really say. Maybe what we need is a Document Structuring Convention and Encapsulated PostScript validation utility! It sure would save me few heated arguments. (No... My software's not busted yours is!) Dale Moore --
john@trigraph.UUCP (John Chew) (05/22/89)
In article <5031@pt.cs.cmu.edu> moore@PULSAR.FAC.CS.CMU.EDU (Dale Moore) writes: ... >>%%BoundingBox: 0.000 0.000 512.000 480.000 ... >According to the document structuring conventions, >a bounding box is an orderd set of four "integers". > >Now, the above numbers certainly look like floating point >numbers. And we all know that floating point numbers aren't >integers. ... >But I've a couple of utilities that look at such things as >"%%BoundingBox" and I wonder if I should reject these things for >not being formatted properly. If I should accept these >floating point numbers, should I round 'em off or truncate 'em? >See, the spec doesn't really say. We got hit by this problem a little while back when *Adobe* Illustrator '88 (v1.8.3) created a file with a BoundingBox comment that had real numbers such as "54.125" (I don't know if it's significant, but all the fractions were multiples of an eighth). I would suggest that any properly written utility be able to accept not-quite-PS-Adobe-conformant comments, possibly issuing a warning indicating what action it is taking. Such a utility should neither round nor truncate, but should rather round the lower left co-ordinates down and the upper right co-ordinates up, so as to guarantee a valid bounding box for the document. John -- john j. chew, iii phone: +1 416 425 3818 AppleLink: CDA0329 trigraph, inc., toronto, canada {uunet!utai!utcsri,utgpu,utzoo}!trigraph!john dept. of math., u. of toronto poslfit@{utorgpu.bitnet,gpu.utcs.utoronto.ca}