[9fans] code inspection needed/appreciated

[9fans] code inspection needed/appreciated

[cej]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

Hello all!

 

I have put a simple code that is intended to manipulate individual RGB pixels, on:

/n/sources/contrib/pac/sys/src/cmd/img/rgb.c

If anyone has time and is willing to help me, I would appreciate inspecting the code and telling me your comments!!

Thank you,

have a great weekend,

 

++pac.

 


[-- Attachment #2: Type: text/html, Size: 2752 bytes --]

Re: [9fans] code inspection needed/appreciated

[erik quanstrom]

could you please explain this code a bit futher.  i'm not sure i understand
what it's supposed to do and how it would be used.

- erik

> Hello all!
> 
>  
> 
> I have put a simple code that is intended to manipulate individual RGB pixels, on:
> 
> /n/sources/contrib/pac/sys/src/cmd/img/rgb.c
> 
> If anyone has time and is willing to help me, I would appreciate inspecting the code and telling me your comments!!
> 
> Thank you,
> 
> have a great weekend,

RE: [9fans] code inspection needed/appreciated

[cej]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

It is intended to be a general 'template' for operations on single pixel, like, e.g., rotation in RGB-space. It should jump the pixels and feed its RGB(A) values to the function doSomethingWithPixel(). I would like to (re)write some image manipulation functions, like color balance, gamma, ...
from NetPBM, and from elsewhere, to native 9 code working on 9 images.
I suffer from being a self-made-man in computing, and of course, from a lack of spare time, as everybody today. Although I did some APE&native ports of my favourite programs, I love plan 9 so much that I want to rewrite some of them in a clean way.
I have much to do with digital imaging, either at work, or as a hobby. I must e3mphasize here that I dont like the paradigm of 'applications' -- user intensive programs, so I'd like to follow the UNIX/Plan9 paradigm of well-tuned single-purpose programs working together glued via a rc script, if I got it right.
Thus, any helping hand ismuch appreciated. Hopefully, one day I'll do rm -fr /n/linux, as i did it with Windoze several years ago.

Back to the question: for the time being, the 'rgb.c' program, after defining the 'do Something...() function to do nothing, should write exactly the same image out, as was the one on the input.

Thanks for your care,
have a great day,

++pac.



-----Original Message-----
From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu on behalf of erik quanstrom
Sent: Fri 3/30/2007 3:44 PM
To: 9fans@cse.psu.edu
Subject: Re: [9fans] code inspection needed/appreciated
 
could you please explain this code a bit futher.  i'm not sure i understand
what it's supposed to do and how it would be used.

- erik

> Hello all!
> 
>  
> 
> I have put a simple code that is intended to manipulate individual RGB pixels, on:
> 
> /n/sources/contrib/pac/sys/src/cmd/img/rgb.c
> 
> If anyone has time and is willing to help me, I would appreciate inspecting the code and telling me your comments!!
> 
> Thank you,
> 
> have a great weekend,


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3807 bytes --]

RE: [9fans] code inspection needed/appreciated

[erik quanstrom]

you may be interested in pico, written by gerald holtzmann in the
mid 80s.  http://spinroot.com/pico/index.html

- erik

Re: [9fans] code inspection needed/appreciated

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 From someone who pushes pixels every day:

You almost certainly don't want a pixel-processing framework that  
breaks things down to pixels!
Most interesting operations on images require a neighbourhood of  
pixels, or even whole-image information.  Furthermore, even for those  
manipulations that don't, a function call per pixel is a huge amount  
of overhead.  Since you mention doing this as a framework, I can only  
imagine that the compiler wouldn't even get to inline the per-pixel  
function, making speedy execution impossible.  With real-sized images  
being in the greater than 2kx3k range these days, you're looking at  
*a lot* of function calls.

Instead, I'd advise you look at a channel-based representation: break  
up RGBA into 4 larger buffers and pass those to your  
"doSomethingWithImage" function.  The addressing requirements are  
simple and it's easy to address sub-images (call the total width  
"pitch", and pass that separately from your current "tile" width).   
And the compiler will have a much easier time unrolling your loops!

Paul

On 2-Apr-07, at 1:29 AM, <cej@gli.cas.cz> wrote:

> It is intended to be a general 'template' for operations on single  
> pixel, like, e.g., rotation in RGB-space. It should jump the pixels  
> and feed its RGB(A) values to the function doSomethingWithPixel().  
> I would like to (re)write some image manipulation functions, like  
> color balance, gamma, ...
> from NetPBM, and from elsewhere, to native 9 code working on 9 images.
> I suffer from being a self-made-man in computing, and of course,  
> from a lack of spare time, as everybody today. Although I did some  
> APE&native ports of my favourite programs, I love plan 9 so much  
> that I want to rewrite some of them in a clean way.
> I have much to do with digital imaging, either at work, or as a  
> hobby. I must e3mphasize here that I dont like the paradigm of  
> 'applications' -- user intensive programs, so I'd like to follow  
> the UNIX/Plan9 paradigm of well-tuned single-purpose programs  
> working together glued via a rc script, if I got it right.
> Thus, any helping hand ismuch appreciated. Hopefully, one day I'll  
> do rm -fr /n/linux, as i did it with Windoze several years ago.
>
> Back to the question: for the time being, the 'rgb.c' program,  
> after defining the 'do Something...() function to do nothing,  
> should write exactly the same image out, as was the one on the input.
>
> Thanks for your care,
> have a great day,
>
> ++pac.
>
>
>
> -----Original Message-----
> From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu on behalf of erik  
> quanstrom
> Sent: Fri 3/30/2007 3:44 PM
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] code inspection needed/appreciated
>
> could you please explain this code a bit futher.  i'm not sure i  
> understand
> what it's supposed to do and how it would be used.
>
> - erik
>
>> Hello all!
>>
>>
>>
>> I have put a simple code that is intended to manipulate individual  
>> RGB pixels, on:
>>
>> /n/sources/contrib/pac/sys/src/cmd/img/rgb.c
>>
>> If anyone has time and is willing to help me, I would appreciate  
>> inspecting the code and telling me your comments!!
>>
>> Thank you,
>>
>> have a great weekend,
>
> <winmail.dat>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGESO8pJeHo/Fbu1wRAnuWAJ42N/vVCK18KwDJRReXlJqCAaKieQCfT+oU
kPbGUyB6lizaknGZ9B1LEgE=
=fClE
-----END PGP SIGNATURE-----

Re: [9fans] code inspection needed/appreciated

[Steve Simon]

> Instead, I'd advise you look at a channel-based representation: break  
> up RGBA into 4 larger buffers and pass those to your  
> "doSomethingWithImage" function. 

Mmm, I agree, however I would add that the ideal data format depends on the
operation being performed and the data source format. Its not a simple problem.

My personal interest is in video and so I am hot on image processing code
which makes no assumptions about how many frames there are - it could even
be could be infinite (resample /dev/tv | page). Also in video many image
processing algrorithms require access to temporarly adjacent frames (or fields).

I put down some thoughts about what I would like to do (but will probably
never get time) here: /n/sources/contrib/steve/Blog

Please don't think I am telling what you should do, just point you at some
random thoughts which will probably raise more questions than they solve ☺

-Steve