Image Manipulation Program Features

128 views
Skip to first unread message

Peter Mattis

unread,
Jul 29, 1995, 3:00:00 AM7/29/95
to
Suppose someone decided to write a graphical image manipulation program
(akin to photoshop). Out of curiousity (and maybe something else), I have a
few (2) questions:

What kind of features should it have? (tools, selections, filters, etc.)
What file formats should it support? (jpeg, gif, tiff, etc.)

Thanks in advance,
Peter Mattis

Gerry S Hayes

unread,
Jul 30, 1995, 3:00:00 AM7/30/95
to

Ahh, this is something we've been throwing around for a while and
considering doing; with the school year coming up, it might be a while
before we have the time, though. This is one thing that Linux really
needs, IMO; a word processor is much less important with TeX and around.

Here are some idea; anyone may feel free to use them, though I reserve
the right to use them myself as well.

I'll start with a list of file formats that should be directly
supported: PBM, PGM, PPM, PNG. Once you have those four, have your
program call the various netpbm tools to convert to one of the above.
There's no reason to duplicate the coding already done for this. Just
pipe other images through the pnm things. This should work equally
well for saving. The reason for PNG is to allow for non-bitmap
characteristics like transparency, comments, interlacing, etc.

Second, a word on features. I'd prefer to see each feature
implemented as an external filter that could be called from the
command line. For instance, make a ppmfill command that takes a set
of coordinates, a color, and any other options you want. Then a
command line:

ppmfill -x5 -y37 -color Red myfile.ppm

would exhibit behaviour as if the user were in a paint program and had
clicked on 5,37 with a red fill. You might want to incorporate these
filters on the source level rather than call them as external
utilities simply for reasons of speed, but I'd start off by calling
the netpbm utils (gamma, brightness, flash, etc) as external programs
and only later assimilate their source if performance was really poor.
Once again, there's no reason to duplicate the effort already done
here. Keep the Unix paradigm of many external utilities working
together in mind. Allow for passing a bitmap as a selection mask to
the various filters, or handle that internally.
Make it easy for the user to add external filters to the menus. Say
I write ppmlensflare; let me edit a .rc file to stick it on a
"Filter" menu or some such.

Now, which features do I want? Everything netpbm, ImageMagick, and
xpaint have, to start. Then, selection by box, circle, polygon, and
magic wand. Ability to add to the current selection (rather than
replace it). Ability to draw circles, boxes, polygons, splines, ovals,
spray paint, flood fill, various brush shapes and sizes (user
definable by bitmaps), arcs (circle and elliptical), and anything else
nifty looking that xfig or tgif have. The ability to do any of the
above filled or unfilled, with independent control of fill style
(vertical, horizontal, and radial gradiants; smooth fill; pattern
fill; solid fill; etc) and line style. Blurs, smoothers, embossers,
edge detectors, ripple and whirlpool effects, lens flare, despecklers,
arbitrary convolutions, sparkle, etc. Cut, paste, copy, etc. The
ability to paste transparently (with filter-style transparency,
transparenty level settable) would be extremely nice. Settable grid
to snap to. Palette control - gamma, brightness, red, green, blue,
hue, saturation, ability to mark a certain color as the transparent
one (for PNG), color quantization and dithering, ability to do
photo-negative effects, ability to substitute one color for another or
control the RGB/HSV values of just one color in the palette (for
indexed images). Everything xv has for palette manipulation, plus more.

The user interface would require a lot of thought. Some ideas: the
tool bar (with all of your tools on it), color/palette bar, and image
canvas should be seperate windows. Allow the tool bar and color bar
to be resized so they can be vertical, horizontal, big, or little.
Allow multiple image canvases. Make resizing the canvas without
resizing the image on it simple. Allow a "save space" option which
uses smaller fonts and icons to conserve screen real estate. Don't
assume an 8bpp display. Allow hot keys (user definable, preferrably)
for everything, and make the defaults either Photoshop-compatible or
ImageMagick-compatible.

I've probably forgotten a lot, but this should be enough to get some
discussion going. I'm interested in responses, too, because if nobody
else starts work on this I'll probably start doing it (very slowly,
with nothing released at least until next summer).

TTFN,

Sumner


Jeff Garzik

unread,
Jul 30, 1995, 3:00:00 AM7/30/95
to
In article <petm-29079...@charnley.hip.berkeley.edu>,

Peter Mattis <pe...@soda.csua.berkeley.edu> wrote:
>Suppose someone decided to write a graphical image manipulation program
>(akin to photoshop). Out of curiousity (and maybe something else), I have a
>few (2) questions:
>
> What kind of features should it have? (tools, selections, filters, etc.)
> What file formats should it support? (jpeg, gif, tiff, etc.)

I am currently putting the finishing touches on the first version of a
program that uses the latest version of the netpbm tools to do all its
file format conversion and image manipulation. It also has a very
easy to use plug-in interface (akin to Photoshop) that works with any
Linux script or binary. It supports shared memory for plug-ins that
support it, and it will write the image to a temp file for those that
don't (such as shell script plug-ins).

It will be GPLed and the source and binaries will be available for
Linux and Solaris initially.

Jeff

Albert Cahalan

unread,
Jul 31, 1995, 3:00:00 AM7/31/95
to
>>>>> "G" == Gerry S Hayes <sum...@CMU.EDU> writes:

>> Suppose someone decided to write a graphical image manipulation program
>> (akin to photoshop). Out of curiousity (and maybe something else), I have a
>> few (2) questions:
>>
>> What kind of features should it have? (tools, selections, filters, etc.)
>> What file formats should it support? (jpeg, gif, tiff, etc.)

G> I'll start with a list of file formats that should be directly supported:
G> PBM, PGM, PPM, PNG. Once you have those four, have your program call the

PNG alone will do, maybe add JPEG for lossy compression.

G> Second, a word on features. I'd prefer to see each feature implemented as
G> an external filter that could be called from the command line. For
...
G> clicked on 5,37 with a red fill. You might want to incorporate these
G> filters on the source level rather than call them as external utilities
G> simply for reasons of speed, but I'd start off by calling the netpbm utils
G> (gamma, brightness, flash, etc) as external programs and only later
G> assimilate their source if performance was really poor. Once again,

Use shared memory or maybe some feature of ELF binaries to avoid the pipe.
--

Albert Cahalan
alb...@ccs.neu.edu

Mark Dobie

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
In <gk6z71W00...@andrew.cmu.edu> Gerry S Hayes <sum...@CMU.EDU> writes:

>I'll start with a list of file formats that should be directly
>supported: PBM, PGM, PPM, PNG. Once you have those four, have your
>program call the various netpbm tools to convert to one of the above.
>There's no reason to duplicate the coding already done for this. Just
>pipe other images through the pnm things. This should work equally
>well for saving. The reason for PNG is to allow for non-bitmap
>characteristics like transparency, comments, interlacing, etc.

I considered this approach for an image processing toolkit. One problem
with the pnm formats is that they are quite limited in what you can
store, for example

- only one image per file (short sequences might be nice)
- up to three planes per image (some images have more, eg satellite pics)
- limited to integer values for pixel data

Another problem is storing related information with an image. It's true,
this can go in as comments, but then you have the problem that the
comments are not passed through the pnmplus filters. Oh dear. Still,
you can get get quite a lot done that way.

(These comments are based on the last release of pbmplus, I don't know
if netpbm has improved matters)

Piping through filters would be a neat way to get free multitasking
between your processing and your GUI, but how would you go about, say, a
progress gauge? I guess you could update it as you read stuff in from
the pipe.

Mark


--
Mark Dobie
M.R....@ecs.soton.ac.uk University of Southampton
http://diana.ecs.soton.ac.uk/~mrd/cv.html MS Windows? Linux and X!


David L. Buckwalter

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
Anyone know the correct syntax for using a .Xdefaults file to set up the
number of lines kept by the scroll bar.
I know the command to turn on the scroll bar is
name*scrollBar: on
where name is the name given in an xterm -name "name" call but I can't
find the correct form for the number of lines to keep. If anyone can
help I would be greatly appreciative.

I know I can do it when calling the xterm with
xterm -name "name" -sl 2000
but want to put everything in the .Xdefaults file if possible.

Thanks
David

Scott Sadler

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
buck...@possum.appl.wpafb.af.mil (David L. Buckwalter) wrote:
>Anyone know the correct syntax for using a .Xdefaults file to set up the
>number of lines kept by the scroll bar.
>I know the command to turn on the scroll bar is
> name*scrollBar: on
>where name is the name given in an xterm -name "name" call but I can't
>find the correct form for the number of lines to keep. If anyone can
>help I would be greatly appreciative.

Maybe this will work. I got it in the xterm man page:

RESOURCES
The program understands all of the core X Toolkit resource
names and classes as well as:

saveLines (class SaveLines)
Specifies the number of lines to save beyond the top
of the screen when a scrollbar is turned on. The
default is 64.

So, in your .Xdefaults, you will want to add something like:

XTerm*saveLines: 2000

--
Scott W. Sadler - Ohio (R)
International TechneGroup Inc
s...@iti-oh.com


Donald R. Dahlquist

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to David L. Buckwalter, Donald R. Dahlquist

In article <3vlsai$d...@podev.appl.wpafb.af.mil>, <buck...@possum.appl.wpafb.af.mil>
writes:


> Anyone know the correct syntax for using a .Xdefaults file to set up the
> number of lines kept by the scroll bar.

> I know I can do it when calling the xterm with
> xterm -name "name" -sl 2000
> but want to put everything in the .Xdefaults file if possible.
>

Mr. Buckwalter,

The syntax is:

name*saveLines: 2000


Regards,

Donald R. Dahlquist
X Terminal Consulting
(612) 645-0064
do...@XTerm.Com

Christopher J. Laurel

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
In article <gk6z71W00...@andrew.cmu.edu>,

Much more important than following the UNIX paradigm is making the
program fast, memory-efficient, and easy to use.
Don't do it the UNIX way--do it the right way. Rather than forking
processes and writing temp files all over the place, dynamically load
code modules. This is not to say that the program shouldn't be useable
from the command line, just that making each image editing function a
separate executable is the wrong way to go about it.

--Chris
cla...@best.com
ch...@dimensionx.com

Dim Dam.. Dominique FRANCOIS

unread,
Aug 3, 1995, 3:00:00 AM8/3/95
to David L. Buckwalter, francois

In article <3vlsai$d...@podev.appl.wpafb.af.mil>, buck...@possum.appl.wpafb.af.mil (David L. Buckwalter) writes:
\_ Anyone know the correct syntax for using a .Xdefaults file to set up the
\_ number of lines kept by the scroll bar.
\_ I know the command to turn on the scroll bar is
\_ name*scrollBar: on
\_ where name is the name given in an xterm -name "name" call but I can't
\_ find the correct form for the number of lines to keep. If anyone can
\_ help I would be greatly appreciative.
\_
\_ I know I can do it when calling the xterm with
\_ xterm -name "name" -sl 2000
\_ but want to put everything in the .Xdefaults file if possible.
\_
\_ Thanks
\_ David

man xterm :

xterm*saveLines: 1024

Dom.
--
____
( / )
_ / / _______ Tel : (1) 44 78 48 68
Dim Dam .. (_X__/_(_)/ / / o Email : fran...@ircam.fr
--
____
( / )
_ / / _______ Tel : (1) 44 78 48 68
Dim Dam .. (_X__/_(_)/ / / o Email : fran...@ircam.fr

Daniel L. Gould

unread,
Aug 5, 1995, 3:00:00 AM8/5/95
to
(Please bear with me, as I am not an expert in this by any stretch of the
imagination)

I agree with alot of what has been said so far. Though the package is
not sold any more, one of the nicest things that I use is called "WHIP".
It is a set of image processing tools that were made by GH Hanaway and
Assoc. for the SGI awhile back. There are literally thousands of tools,
many of which can take thousands of options, such as different matrices
and filters. It is both a set of C function calls and tools that can be
called from the command line. Pictures are loaded into a frame buffer
and there is a program that lets you view the contents of the frame
buffer so when you run a command you instantly see the results (you can
also work with plain files without viewing tehm to do things like
conversions, etc). A tool can be built up over time if there is an easy
format and structure so people can add their own functions.
I think the way to start would be to write a C library that people can
call from their programs, then start to make UNIX shell callable
programs. After that, a GUI can be added on top. A nice interface for
doing more complex operations might also be something like AVS or IRIS
data explorer where you make networks by connecting the modules together
to perform a complex task (but you would still have the unix and c
modules so you could write c programs or shell scripts).
I think other people can probably answer the questions of what file
formats, image processing tools, kernels, etc better than I can.

--
Dan Gould psychosysadmin of goober! http://www.mbhs.edu/~dgould/
d...@wintermute.mbhs.edu internet account collector! (esp supercomputers!)
Duct tape is like the force, it has a dark side, a light side, and it
holds the universe together. -Carl Zwanig

Reply all
Reply to author
Forward
0 new messages