[9fans] How to read/write pixels from Memimage - Plan9

This is a discussion on [9fans] How to read/write pixels from Memimage - Plan9 ; Hello. I'm porting Bell Labs' Pico image language over to Plan 9 to use the Plan 9 native image format (image(6)), and I chose to use Memimage. I'd like to know how to get the 32-bit RGB pixel information out ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 27

Thread: [9fans] How to read/write pixels from Memimage

  1. [9fans] How to read/write pixels from Memimage

    Hello. I'm porting Bell Labs' Pico image language over to Plan 9 to
    use the Plan 9 native image format (image(6)), and I chose to use
    Memimage. I'd like to know how to get the 32-bit RGB pixel
    information out of a Memimage and into a properly allocated array of
    u32ints, and to do the reverse. Is that possible? Thanks.


  2. Re: [9fans] How to read/write pixels from Memimage

    > Hello. I'm porting Bell Labs' Pico image language over to Plan 9 to
    > use the Plan 9 native image format (image(6)), and I chose to use
    > Memimage. I'd like to know how to get the 32-bit RGB pixel
    > information out of a Memimage and into a properly allocated array of
    > u32ints, and to do the reverse. Is that possible? Thanks.


    A good way to answer questions like these is to

    cd /sys/src/cmd
    grep -n Memimage *.c */*.c */*/*.c

    Looking through the output, all of these:

    /sys/src/cmd/crop.c
    /sys/src/cmd/resample.c
    /sys/src/cmd/jpg/writepng.c

    are examples of programs that use memimages
    in a byte-at-a-time fashion.

    Russ


  3. Re: [9fans] How to read/write pixels from Memimage

    However, I want to be able to read 32-bit color values. How does
    Memimage store colors and will the code I use work? I can change it
    to 24-bit if necessary, but that would make it slower to read files.
    If I do what these programs say, how will my u32int be arranged?

    On Jan 26, 2008, at 9:05 AM, Russ Cox wrote:

    >> Hello. I'm porting Bell Labs' Pico image language over to Plan 9 to
    >> use the Plan 9 native image format (image(6)), and I chose to use
    >> Memimage. I'd like to know how to get the 32-bit RGB pixel
    >> information out of a Memimage and into a properly allocated array of
    >> u32ints, and to do the reverse. Is that possible? Thanks.

    >
    > A good way to answer questions like these is to
    >
    > cd /sys/src/cmd
    > grep -n Memimage *.c */*.c */*/*.c
    >
    > Looking through the output, all of these:
    >
    > /sys/src/cmd/crop.c
    > /sys/src/cmd/resample.c
    > /sys/src/cmd/jpg/writepng.c
    >
    > are examples of programs that use memimages
    > in a byte-at-a-time fashion.
    >
    > Russ
    >



  4. Re: [9fans] How to read/write pixels from Memimage

    > However, I want to be able to read 32-bit color values. How does
    > Memimage store colors and


    You should be able to answer this by reading the programs
    I pointed out as well as color(6), image(6), and memdraw(2).
    If all else fails, you could try writing a simple program and
    see how far you get.

    > will the code I use work?


    Probably not at first (whose code does?), but eventually.

    > I can change it to 24-bit if necessary, but that would make it slower to read files.
    > If I do what these programs say, how will my u32int be arranged?


    The answers to these questions are *in* those programs
    (not to mention the manual pages!). Given that your reply
    came in four minutes after my post, it sounds like you didn't
    actually read the programs I pointed out. The first one on
    the list, /sys/src/cmd/crop.c, picks up a Plan 9 image file
    and then walks over every 32-bit pixel looking for a given color.
    And it's only 211 lines. Between that and the documentation
    I'd think that would be enough to answer questions about
    how colors are stored. At the least it should prompt
    questions that are more specific than "how do I do this?"

    Read /sys/src/cmd/crop.c, color(6), image(6), and memdraw(2).

    Russ


  5. Re: [9fans] How to read/write pixels from Memimage

    The code led me to confusion, so I just decided to use wordaddr. It
    works properly now, and my Pico is now up at /n/sources/contrib/
    pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
    files are in /lib/face/.

    On Jan 26, 2008, at 9:55 AM, Russ Cox wrote:

    >> However, I want to be able to read 32-bit color values. How does
    >> Memimage store colors and

    >
    > You should be able to answer this by reading the programs
    > I pointed out as well as color(6), image(6), and memdraw(2).
    > If all else fails, you could try writing a simple program and
    > see how far you get.
    >
    >> will the code I use work?

    >
    > Probably not at first (whose code does?), but eventually.
    >
    >> I can change it to 24-bit if necessary, but that would make it
    >> slower to read files.
    >> If I do what these programs say, how will my u32int be arranged?

    >
    > The answers to these questions are *in* those programs
    > (not to mention the manual pages!). Given that your reply
    > came in four minutes after my post, it sounds like you didn't
    > actually read the programs I pointed out. The first one on
    > the list, /sys/src/cmd/crop.c, picks up a Plan 9 image file
    > and then walks over every 32-bit pixel looking for a given color.
    > And it's only 211 lines. Between that and the documentation
    > I'd think that would be enough to answer questions about
    > how colors are stored. At the least it should prompt
    > questions that are more specific than "how do I do this?"
    >
    > Read /sys/src/cmd/crop.c, color(6), image(6), and memdraw(2).
    >
    > Russ
    >



  6. Re: [9fans] How to read/write pixels from Memimage

    > The code led me to confusion, so I just decided to use wordaddr. It
    > works properly now, and my Pico is now up at /n/sources/contrib/
    > pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
    > files are in /lib/face/.


    some book examples are failing:

    cpu% 8.out
    1: new[x,y] = x % y
    8.out 181613: suicide: sys: trap: divide error pc=0x000023fd


  7. Re: [9fans] How to read/write pixels from Memimage

    That transformation is in the book? It divides by zero for y == 0. I
    have to look.

    I'm working on an update. It adds:
    r x y w h file (done)
    Reads a certain rectangle of a file. This makes crop(1)'s -r option
    three lines of rc or /bin/sh:
    echo 'r '$1' '$2' '$3' '$4' '$5'
    new = old
    w '$6 | pico
    Simple variables (started)
    Undo command u (done)
    Use of RGB24 instead of RGBA32 to make the examples work (done)
    Using Brdstr instead of Bgetc/Bungetc (this is not working)

    On Jan 27, 2008, at 1:05 PM, Skip Tavakkolian wrote:

    >> The code led me to confusion, so I just decided to use wordaddr. It
    >> works properly now, and my Pico is now up at /n/sources/contrib/
    >> pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
    >> files are in /lib/face/.

    >
    > some book examples are failing:
    >
    > cpu% 8.out
    > 1: new[x,y] = x % y
    > 8.out 181613: suicide: sys: trap: divide error pc=0x000023fd
    >



  8. Re: [9fans] How to read/write pixels from Memimage

    Well I just found it, and I couldn't believe it. I'm going to look at
    Gerard's original source for the VAX and see what he does on divide
    by zero.

    On Jan 27, 2008, at 1:05 PM, Skip Tavakkolian wrote:

    >> The code led me to confusion, so I just decided to use wordaddr. It
    >> works properly now, and my Pico is now up at /n/sources/contrib/
    >> pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
    >> files are in /lib/face/.

    >
    > some book examples are failing:
    >
    > cpu% 8.out
    > 1: new[x,y] = x % y
    > 8.out 181613: suicide: sys: trap: divide error pc=0x000023fd
    >



  9. [9fans] pico

    FYI

    Byron Rakitzis (of posix rc fame) produced a version popi with the JIT
    compiler, though sadly his where for cpus which are common cpus these days.

    Also possibly of interest is the paper from the 10th edition manual
    http://plan9.bell-labs.com/10thEdMan/pico.pdf

    And a few fun pictures that where generated
    http://plan9.bell-labs.com/10thEdMan/v2pix.html

    -Steve

  10. Re: [9fans] How to read/write pixels from Memimage

    Okay, I just found out that division by zero meant a black pixel
    would be placed, so I am going to add that and upload a new version.

    On Jan 27, 2008, at 1:05 PM, Skip Tavakkolian wrote:

    >> The code led me to confusion, so I just decided to use wordaddr. It
    >> works properly now, and my Pico is now up at /n/sources/contrib/
    >> pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
    >> files are in /lib/face/.

    >
    > some book examples are failing:
    >
    > cpu% 8.out
    > 1: new[x,y] = x % y
    > 8.out 181613: suicide: sys: trap: divide error pc=0x000023fd
    >



  11. Re: [9fans] How to read/write pixels from Memimage

    It's up.

    On Jan 27, 2008, at 6:44 PM, Pietro Gagliardi wrote:

    > Okay, I just found out that division by zero meant a black pixel
    > would be placed, so I am going to add that and upload a new version.
    >
    > On Jan 27, 2008, at 1:05 PM, Skip Tavakkolian wrote:
    >
    >>> The code led me to confusion, so I just decided to use wordaddr. It
    >>> works properly now, and my Pico is now up at /n/sources/contrib/
    >>> pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
    >>> files are in /lib/face/.

    >>
    >> some book examples are failing:
    >>
    >> cpu% 8.out
    >> 1: new[x,y] = x % y
    >> 8.out 181613: suicide: sys: trap: divide error pc=0x000023fd
    >>

    >



  12. Re: [9fans] How to read/write pixels from Memimage

    Another question: in RGB24, how are colors composited: 0x00RRGGBB or
    0xRRGGBB00? I can't seem to get a picture that is solid red; just a
    wacky line art picture.

    On Jan 27, 2008, at 7:18 PM, Pietro Gagliardi wrote:

    > It's up.
    >
    > On Jan 27, 2008, at 6:44 PM, Pietro Gagliardi wrote:
    >
    >> Okay, I just found out that division by zero meant a black pixel
    >> would be placed, so I am going to add that and upload a new version.
    >>
    >> On Jan 27, 2008, at 1:05 PM, Skip Tavakkolian wrote:
    >>
    >>>> The code led me to confusion, so I just decided to use wordaddr. It
    >>>> works properly now, and my Pico is now up at /n/sources/contrib/
    >>>> pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
    >>>> files are in /lib/face/.
    >>>
    >>> some book examples are failing:
    >>>
    >>> cpu% 8.out
    >>> 1: new[x,y] = x % y
    >>> 8.out 181613: suicide: sys: trap: divide error pc=0x000023fd
    >>>

    >>

    >



  13. Re: [9fans] How to read/write pixels from Memimage

    > Another question: in RGB24, how are colors composited: 0x00RRGGBB or
    > 0xRRGGBB00? I can't seem to get a picture that is solid red; just a
    > wacky line art picture.


    read image(6). all the details are spelled out there. (you likely want an alpha
    channel in your image, so that each pixel is 4 bytes.)

    - erik

  14. Re: [9fans] How to read/write pixels from Memimage

    9fans is not a blog, try blogger.com
    >
    >
    >> (you likely want an alpha
    >>
    >> channel in your image, so that each pixel is 4 bytes.)
    >>

    >
    > Apparently, my RGB24 manipulation was wrong, and now it works like a
    > charm. The next step is to support a construct like new.red and to
    > eliminate the use of undocumented stuff (I peeked in
    > /sys/include/draw.h and /sys/src/libbio/brdstr.c for some hacks).
    >



  15. Re: [9fans] How to read/write pixels from Memimage

    On Jan 28, 2008 1:24 AM, wrote:
    > 9fans is not a blog, try blogger.com


    now now now :-)

    Why give the guy a hard time, he's actually discussing real coding he
    is doing :-)

    ron

  16. Re: [9fans] pico

    > Byron Rakitzis (of posix rc fame) produced a version popi with the JIT
    > compiler, though sadly his where for cpus which are common cpus these days.


    Computers and compilers are fast enough now
    that you can get away with just feeding code
    into a C compiler instead of writing a full JIT.
    And there's no porting to do!

    I just put a pico on sources that does this - 738 lines,
    not many of which are the "JIT".

    9fs sources
    cd /n/sources/contrib/rsc/pico
    mk demo

    Russ


  17. Re: [9fans] pico

    Wow, that's very impressive!

    open: /tmp/something does not exist (2x)
    no image lerp
    no image doug

    But you have a preview, which I was going to add soon.

    I am sticking with my code interpreter because I know how to use one
    (I toiled over hoc. and fossil ate my code up last December) and it
    doesn't require hooking to a C compiler. I do like the preprocessor
    idea though.

    On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:

    >> Byron Rakitzis (of posix rc fame) produced a version popi with the
    >> JIT
    >> compiler, though sadly his where for cpus which are common cpus
    >> these days.

    >
    > Computers and compilers are fast enough now
    > that you can get away with just feeding code
    > into a C compiler instead of writing a full JIT.
    > And there's no porting to do!
    >
    > I just put a pico on sources that does this - 738 lines,
    > not many of which are the "JIT".
    >
    > 9fs sources
    > cd /n/sources/contrib/rsc/pico
    > mk demo
    >
    > Russ
    >



  18. Re: [9fans] pico

    well i agree that russ did a good job but JITs are fun and often
    make things 10 times faster.

    brucee

    On Jan 29, 2008 11:30 AM, Pietro Gagliardi wrote:
    > Wow, that's very impressive!
    >
    > open: /tmp/something does not exist (2x)
    > no image lerp
    > no image doug
    >
    > But you have a preview, which I was going to add soon.
    >
    > I am sticking with my code interpreter because I know how to use one
    > (I toiled over hoc. and fossil ate my code up last December) and it
    > doesn't require hooking to a C compiler. I do like the preprocessor
    > idea though.
    >
    >
    > On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:
    >
    > >> Byron Rakitzis (of posix rc fame) produced a version popi with the
    > >> JIT
    > >> compiler, though sadly his where for cpus which are common cpus
    > >> these days.

    > >
    > > Computers and compilers are fast enough now
    > > that you can get away with just feeding code
    > > into a C compiler instead of writing a full JIT.
    > > And there's no porting to do!
    > >
    > > I just put a pico on sources that does this - 738 lines,
    > > not many of which are the "JIT".
    > >
    > > 9fs sources
    > > cd /n/sources/contrib/rsc/pico
    > > mk demo
    > >
    > > Russ
    > >

    >
    >


  19. Re: [9fans] pico

    In the latest update, I tried adding differentiating between color
    and b/w images. However, I can't test anything because every time I
    try a line like

    x new = dennis

    I get something that ends in "(double-free?)" and then the program
    crashes, but something like

    x new
    x new =

    do call the error() function. The lexer did not change since I
    started this update, but it did change when I improved symbol handling.

    On Jan 29, 2008, at 12:30 AM, Bruce Ellis wrote:

    > well i agree that russ did a good job but JITs are fun and often
    > make things 10 times faster.
    >
    > brucee
    >
    > On Jan 29, 2008 11:30 AM, Pietro Gagliardi wrote:
    >> Wow, that's very impressive!
    >>
    >> open: /tmp/something does not exist (2x)
    >> no image lerp
    >> no image doug
    >>
    >> But you have a preview, which I was going to add soon.
    >>
    >> I am sticking with my code interpreter because I know how to use one
    >> (I toiled over hoc. and fossil ate my code up last December) and it
    >> doesn't require hooking to a C compiler. I do like the preprocessor
    >> idea though.
    >>
    >>
    >> On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:
    >>
    >>>> Byron Rakitzis (of posix rc fame) produced a version popi with the
    >>>> JIT
    >>>> compiler, though sadly his where for cpus which are common cpus
    >>>> these days.
    >>>
    >>> Computers and compilers are fast enough now
    >>> that you can get away with just feeding code
    >>> into a C compiler instead of writing a full JIT.
    >>> And there's no porting to do!
    >>>
    >>> I just put a pico on sources that does this - 738 lines,
    >>> not many of which are the "JIT".
    >>>
    >>> 9fs sources
    >>> cd /n/sources/contrib/rsc/pico
    >>> mk demo
    >>>
    >>> Russ
    >>>

    >>
    >>



  20. Re: [9fans] pico

    This only happens with black/white images, I ran a color image (boyd)
    through and it worked fine. I think it's with the run function...

    On Jan 29, 2008, at 3:33 PM, Pietro Gagliardi wrote:

    > In the latest update, I tried adding differentiating between color
    > and b/w images. However, I can't test anything because every time I
    > try a line like
    >
    > x new = dennis
    >
    > I get something that ends in "(double-free?)" and then the program
    > crashes, but something like
    >
    > x new
    > x new =
    >
    > do call the error() function. The lexer did not change since I
    > started this update, but it did change when I improved symbol
    > handling.
    >
    > On Jan 29, 2008, at 12:30 AM, Bruce Ellis wrote:
    >
    >> well i agree that russ did a good job but JITs are fun and often
    >> make things 10 times faster.
    >>
    >> brucee
    >>
    >> On Jan 29, 2008 11:30 AM, Pietro Gagliardi wrote:
    >>> Wow, that's very impressive!
    >>>
    >>> open: /tmp/something does not exist (2x)
    >>> no image lerp
    >>> no image doug
    >>>
    >>> But you have a preview, which I was going to add soon.
    >>>
    >>> I am sticking with my code interpreter because I know how to use one
    >>> (I toiled over hoc. and fossil ate my code up last December) and it
    >>> doesn't require hooking to a C compiler. I do like the preprocessor
    >>> idea though.
    >>>
    >>>
    >>> On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:
    >>>
    >>>>> Byron Rakitzis (of posix rc fame) produced a version popi with the
    >>>>> JIT
    >>>>> compiler, though sadly his where for cpus which are common cpus
    >>>>> these days.
    >>>>
    >>>> Computers and compilers are fast enough now
    >>>> that you can get away with just feeding code
    >>>> into a C compiler instead of writing a full JIT.
    >>>> And there's no porting to do!
    >>>>
    >>>> I just put a pico on sources that does this - 738 lines,
    >>>> not many of which are the "JIT".
    >>>>
    >>>> 9fs sources
    >>>> cd /n/sources/contrib/rsc/pico
    >>>> mk demo
    >>>>
    >>>> Russ
    >>>>
    >>>
    >>>

    >



+ Reply to Thread
Page 1 of 2 1 2 LastLast