How does process color work

[vacpress]

Anyone here allready know anything about writing printer drivers...

or at least, writing a program that can break an image into a grid and put a color value in each space of the grid, and then process that info into a long file of coordinates and color pixels?

[Chagrin]

#!/usr/bin/perl

use GD;

my $image = GD::Image->new("whatever.jpg");

my ($width, $height) = $image->getBounds();
foreach $x (0..$width) {
  foreach $y (0..$height) {
    my($red, $green, $blue) = $image->rgb($image->getPixel($x, $y));

    print "color is $red $green $blue at $x $y\n";
  }
}

Hey, that's the easy part.

[vacpress]

Chagrin - please elaborate on this - did you look at the "4 color painthead" in the cnc gantry printer thread?

[vacpress]

so this code - can you repost it with comments?

i am looking at it. it.. opens a file, finds the files resolution, devides by that number and then finds the color value for each division. the it prints the data to the screen? tell me more! MORE. i was jsut this minute reading about ghostscript and thinking about a postscript vector based driver...

[vacpress]

here is somethign that may help with this problem.


"Printer Driver Block Diagram"

[Chagrin]

Aw geez, "four color painthead"... now you want me to convert it to CMYK. I'm trying to answer one question at a time

OK, back from the beginning, yes you did get the basic flow of the program right -- it's moving pixel by pixel in the image and printing the RGB values of that pixel. I don't see any need to copy all that data into a "grid" as you mentioned earlier since that can all be done on the fly as the hardware moves. I was just trying to demonstrate how you can walk through an image and look at those pixel values.

I saw in another thread that someone recommended ghostscript, and this really isn't the way to go. Ghostscript is mainly used when the hardware speaks the standard language of Postscript, which nearly all printers do, but that's completely out of scope for us. Similarly, using vector-based printing (like a plotter) as opposed to raster-based printing (like every other printer) would add massive levels of complexity to the problem. I can't even begin to ponder all of the algorithms used to find the path for the printhead and routines necessary to draw something as simple as an arc, much less optimizing either. "floodfills" are completely out of the question. Leave that stuff to the professionals

[publitime]

i use a program for doing signmaking.
In the program there is a proffesional RIP.
For all large format printers there is a driver in the program.
Maeby that will be usefull.
I will post the question on a german cnc forum.
Maybe i can find there somebody who can write a printerdriver.

[vacpress]

chagrin - thanks for the reply!

it seems i have 2 choices - either trying to try and use a mix of regular plotter CNC software with 4-color seperations run into a "raster to vector" convertor

or to write my own raster based software. this is preferable because it will be fun. if the program starts in the uper left corner of the image and reads to the right, it can scan the image as the painthead reproduces the dots..

how would i just use a .bmp? is there a good source of info on this type of coding?

- what is that provess called in the code you wrote, where can i learn more about it? is there a way to use it with CMYK values instead of RGB?

i can iamgine easily getting the thing to move (x)steps to the left for each pixel, and (x) step forward to advance to he next line, then seeing what color is in that cell, and sending the command to a program in a PICmicro that mixes the paint and produces the dot, send a "go forward" command and then it does it again.


thanks....

[vacpress]

publitime- i am trying to find a forum where people are working on these issues. i know there are at least 2 places to look but havent found any. I am looking for:

1-people who are involved in image editing software that would understand how to process a file into coordinates and color values.

2-people who are involved in writing general hardware or printer drivers...

HPGl, HP RTL are both acronyms that seem usefull to look at.


does the information at:
http://www.ghostscript.com/doc/gnu/...es.htm#Uniprint

help or confuse things?
anyone?

[publitime]

vacpress

I'm also searching the net to find a way to write a driver.
What will be the best program for you to write a driver

[publitime]

vac

Take a look at
http://www.noobeed.com/
There can be something intressting

[Chagrin]

You don't really want to get into the business of decoding image file formats directly. Even bitmaps have numerous headers and compression stuff you'd need to wade through before you could even begin to make heads and tails of the pixels in the image. The "GD" library is an excellent place to start to avoid all that stuff, as I did in my example.

I barely know anything about printing processes, but I do know it's possible to convert RGB to CMYK. It's something on the order of:

    $C = 1 - ( $red / 255 );
    $M = 1 - ( $green / 255 );
    $Y = 1 - ( $blue / 255 );

    my $K = 1;

    $K = $C if ($C < $K);
    $K = $M if ($M < $K);
    $K = $Y if ($Y < $K);

    $C = ($C - $K) / (1 - $K);
    $M = ($M - $K) / (1 - $K);
    $Y = ($Y - $K) / (1 - $K);

...but I think I have my intensities inverted. Inevitably there will be a lot of tweaking to get the colors looking right.