Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!hp-sdd!adp From: adp@hp-sdd.HP.COM (Tony Parkhurst) Newsgroups: comp.graphics Subject: Re: Intelligent scaling of bit-mapped graphics (Help!) Message-ID: <679@hp-sdd.HP.COM> Date: Mon, 19-Jan-87 13:48:47 EST Article-I.D.: hp-sdd.679 Posted: Mon Jan 19 13:48:47 1987 Date-Received: Tue, 20-Jan-87 18:56:11 EST References: <2872@gitpyr.gatech.EDU> Reply-To: adp@hp-sdd.UUCP (Tony Parkhurst) Organization: Hewlett Packard, San Diego Lines: 235 I was unable to directly mail to you so here is a copy of the letter I tried to send. After seeing other responses to your request, I think you will prefer this method due to the simplicity and lower CPU required for the task. However, some may argue that this is not the proper method, but I think it will generate acceptable results. Have fun. -----------------------(undelivered letter)------------------------- Your in luck, I just devised a simple agorithm to resize any arbitrary size image to 640x400 for my Amiga. You should not have any problem modifying it to size the 640x400 images up to whatever resolution you are using. (simply change the 640x400 constants to your final resolution, and change 'xsize' and 'ysize' to 640x400.) Feel free to use as you wish as long as not for huge profits (unless I get a share :-) (also, if you are making a public domain printer driver, feel free to use it.) First, a couple of caveats: 1 -- This algorithm does pixel averaging, therefore, when resizing to a lower resolution (not your case), it behave like a low-pass filter, and you will tend to lose fine detail. 2 -- depending on the actual ratio of sizing up, there may or may not be artifacts. Try it and see how it looks. 3 -- The resizing is done first horizontally then vertically, therefore it is possible that some artifacts will be introduced at this level but it is not likely to make much difference. The program itself takes 4 input files (header, red, green and blue) of arbitrary size(the header file has the size in it) where each pixel is 24 bits (8 bits red, 8 bits green and 8 bits blue) and outputs one file which is 640x400 (but still has 24-bits per pixel aranged in the file as ...rgbrgbrgbrgbrgb...). The output is like this becuase then I run it into a different filter for dithering and diffusing etc. It should not be hard to modify for any reasonable format. The algorithm works like this (this is a conceptual model only, the implementation is a little simpler) if my input has a res of 1197x872, and my output is 640x400, I take the row of 1197 pixels and stretch it out 640 times, so there are 640 of the first pixel, 640 of the next and so forth. Then, for output, I gather up 1197 pixels (add them together and divide by 1197) then output one pixel (I do this 640 times). See how 640x1197 == 1197x640. I do the same thing for rows (872 ==> 400). Technically, the horizontal is resized before the verticle so there may be additional artifacts, but not too likely. The implementation doesn't bother stretching the pixels since we can assume that the pixels are replicas (that is part of the premise) so, all we have to do is keep kounts of what we need and what we have. hopefully, this will explain most of the inner workings of the program. Also, only integer math is used, so it is pretty efficient and accurate, and 32-bit integers should be uses (instead of 16-bit) because 1197 * 255 (max pixel value) > 32567. However, since you will be working with 4 bits per pixel (or whatever), you may be able to use 16-bit ints. Lotsa luck --- here is a shar file... ----------------------------------------------------------------------- #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # picomp.c # This archive created: Wed Jan 14 10:21:33 1987 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'picomp.c'" '(3473 characters)' if test -f 'picomp.c' then echo shar: "will not over-write existing file 'picomp.c'" else sed 's/^ X//' << \SHAR_EOF > 'picomp.c' X/* Copyright (c) 1987 Tony Parkhurst */ X X/* This may be used for non-profit only and copyright notice X should remain intact. Usual courtesy and customs. X Feel free to include this in other non-profit software, X but usual credit where due please. X*/ X X/* picomp takes the image files of various sizes and compresses them X to a 640 by 400 rgb image. */ X X/* Usage: picomp image */ X/* inputs are image.red image.green image.blue image.header, X outputs image.rgb (640x400 rbyte, gbyte bbtye). */ X X/* basic algorithm is: if image is 1197 x 942, then X each of 1197 pixels is stretched out 640 times, then 1197 X are gathered at a time for 640 outputs... */ X X#include X X#define HRES 1280 X#define VRES 1024 X#define HAMI 640 X#define VAMI 400 X X X#define MIN(x,y) (x 255 || r < 0){ X fprintf(stderr,"Warning: Red component out of range: %d\n",r); X } X if(g > 255 || g < 0){ X fprintf(stderr,"Warning: Green component out of range: %d\n",g); X } X if(b > 255 || b < 0){ X fprintf(stderr,"Warning: Blue component out of range: %d\n",b); X } X X putc(r,frgb); X putc(g,frgb); X putc(b,frgb); X X } X X } /* for y */ X} SHAR_EOF if test 3473 -ne "`wc -c < 'picomp.c'`" then echo shar: "error transmitting 'picomp.c'" '(should have been 3473 characters)' fi fi exit 0 # End of shell archive -- **************** Insert 'Standard' Disclaimer here: OOP ACK! ***************** * Tony Parkhurst -- {hplabs|sdcsvax|ncr-sd|hpfcla|ihnp4}!hp-sdd!adp * * OR hp-sdd!adp@nosc.arpa * *******************************************************************************