Since FLTK is used by Csound itself, I suggest using the FLTK image libraries. The ImageToScore node in CsoundAC already does this. You can look at frontends/CsoundAC/ImageToScore.cpp to see how the FLTK image libraries are used, and at SConstruct to see how they are linked with CsoundAC.dll or .so.

As its name suggests, ImageToScore translates an image file into a CsoundAC score, which can be a node inside a CsoundAC music graph. Thus, the purposes of Cesare's opcodes and ImageToScore are not the same.

Regards,
Mike

-----Original Message-----
>From: Cesare Marilungo 
>Sent: Nov 19, 2007 12:33 PM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] Re: Re: Image opcodes
>
>Hi Andres,
>
>I agree with Michael about the default behavior for scaling values. Keep 
>in mind that my idea was to use these opcodes to extract information 
>from images for musical purposes, not for GUIs (I thought there was a FL 
>opcode for this, already). My idea was to add an optional parameter to 
>set the behavior you're talking about (mapping r g b values as bytes and 
>coords as ints).
>
>I didn't know about CsoundAV, lots of interesting stuff. Can't try it 
>since I'm on gnu/Linux.
>
>Anyway it would be good reuse stuff wherever it's possible. Another 
>problem is which library/ies to use for loading images on the various 
>platforms.
>
>Ciao,
>
>c.
>
>Andres Cabrera wrote:
>> Hi Cesare,
>>
>> El dom, 18-11-2007 a las 20:40 +0100, Cesare Marilungo escribió:
>>   
>>> By default these two opcodes use values scaled from 0.0 to 1.0 so the 
>>> top left pixel is 0,0 and the r g b values are 0.0 to 1.0 too. As 
>>> Michael suggested I plan to add an extra parameter to choose if you want 
>>> to use the exact pixel indexes. So 0 would be default, 1 would be with 
>>> exact pixel indexes and r g b values.
>>>
>>>     
>> Thanks for your work. Just one suggestion to keep values more in line
>> with existing opcodes, it might be good to use ranges between 0 and 255
>> to keep consistency with the existing FL opcodes like FLcolor, etc.
>> Do you think these opcodes could be used to replace the bmopen opcode
>> (which is currently only available on CsoundAV, but is designed to
>> interact with other existing opcodes)?
>>
>> http://www.csounds.com/maldonado/Manual/index.htm
>>
>> Cheers,
>> Andrés
>>
>>   
>>> I would like to hear from you about the naming conventions and such, if 
>>> there's a better way to name these opcodes. If you think they would be 
>>> useful or if they're worthless. Anything.
>>>
>>> Also, at the moment I'm using Imlib and Xlib for this and I developed it 
>>> on gnu/Linux. What library would you use for Windows and MacOS X?
>>>
>>> Thanks in advance for the feedback.
>>>
>>> Ciao,
>>>
>>> c.
>>>
>>> p.s. Here's a .csd to test everything:
>>>
>>> 
>>>
>>> 
>>> sr=48000
>>> ksmps=1
>>> nchnls=2
>>>
>>> giimage1 imageload "image.png" ;edit this to point to a valid image path 
>>> and filename
>>> giimage1w, giimage1h imagesize giimage1
>>> prints "giImage1size: %d,%d\n", giimage1w, giimage1h
>>>
>>> giimage2 imagecreate 800, 600
>>>
>>>         instr 1
>>> kval linseg 0, p3, 1
>>> kred, kgreen, kblue imagegetpixel giimage1, kval, 0 ;scans and print the 
>>> first line of the image (y=0)
>>> printk 0, kblue
>>>         endin
>>>
>>>         instr 2
>>> kval linseg 0, p3, 1
>>> kval2 lfo 1/6,2,0
>>> kval3 lfo 1/6,4,0
>>> kval4 lfo 1/6,8,0
>>> imagesetpixel giimage2, kval,kval2+1/6,1,0,0
>>> imagesetpixel giimage2, kval,kval3+3/6,0,1,0
>>> imagesetpixel giimage2, kval,kval4+5/6,0,0,1
>>>         endin
>>>
>>>         instr 3
>>> imagesave giimage2, "imageout.png"
>>>         endin
>>>
>>>
>>> 
>>>
>>> 
>>> i1 0 0.1
>>> i2 1 1
>>> i3 2 1
>>> e
>>>
>>> 
>>>
>>> 
>>>
>>>     
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>   
>
>
>-- 
>www.cesaremarilungo.com 
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Ok, I'll rewrite the opcodes to use FLTK, then.

It would be great to have them on all platforms.

BTW, here's another test I made which copies an image inside another 
(just for the sake of it). I thought it wouldn't have been possible 
without using python or other tricks, but I wasn't aware of the 
existence of the (fortran style?) loop_xx opcodes:



sr=48000
ksmps=1
nchnls=2

giimage1 imageload "image.png"
giimage2 imagecreate 800,600

    instr 1
kndx = 0
kx_ linseg 0, p3, 1

myloop:
ky_ = kndx/599.0
kr_ kg_ kb_ imagegetpixel giimage1, kx_, ky_
imagesetpixel giimage2, kx_, ky_, kr_, kg_, kb_
loop_lt kndx, 1, 599, myloop
    endin

    instr 2
imagesave giimage2, "imageout.png"
    endin



i1 1 1
i2 2 1
e



Ciao,

- c.

Michael Gogins wrote:
> Since FLTK is used by Csound itself, I suggest using the FLTK image libraries. The ImageToScore node in CsoundAC already does this. You can look at frontends/CsoundAC/ImageToScore.cpp to see how the FLTK image libraries are used, and at SConstruct to see how they are linked with CsoundAC.dll or .so.
>
> As its name suggests, ImageToScore translates an image file into a CsoundAC score, which can be a node inside a CsoundAC music graph. Thus, the purposes of Cesare's opcodes and ImageToScore are not the same.
>
> Regards,
> Mike
>
> -----Original Message-----
>   
>> From: Cesare Marilungo 
>> Sent: Nov 19, 2007 12:33 PM
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] Re: Re: Image opcodes
>>
>> Hi Andres,
>>
>> I agree with Michael about the default behavior for scaling values. Keep 
>> in mind that my idea was to use these opcodes to extract information 
>>     
> >from images for musical purposes, not for GUIs (I thought there was a FL 
>   
>> opcode for this, already). My idea was to add an optional parameter to 
>> set the behavior you're talking about (mapping r g b values as bytes and 
>> coords as ints).
>>
>> I didn't know about CsoundAV, lots of interesting stuff. Can't try it 
>> since I'm on gnu/Linux.
>>
>> Anyway it would be good reuse stuff wherever it's possible. Another 
>> problem is which library/ies to use for loading images on the various 
>> platforms.
>>
>> Ciao,
>>
>> c.
>>
>> Andres Cabrera wrote:
>>     
>>> Hi Cesare,
>>>
>>> El dom, 18-11-2007 a las 20:40 +0100, Cesare Marilungo escribió:
>>>   
>>>       
>>>> By default these two opcodes use values scaled from 0.0 to 1.0 so the 
>>>> top left pixel is 0,0 and the r g b values are 0.0 to 1.0 too. As 
>>>> Michael suggested I plan to add an extra parameter to choose if you want 
>>>> to use the exact pixel indexes. So 0 would be default, 1 would be with 
>>>> exact pixel indexes and r g b values.
>>>>
>>>>     
>>>>         
>>> Thanks for your work. Just one suggestion to keep values more in line
>>> with existing opcodes, it might be good to use ranges between 0 and 255
>>> to keep consistency with the existing FL opcodes like FLcolor, etc.
>>> Do you think these opcodes could be used to replace the bmopen opcode
>>> (which is currently only available on CsoundAV, but is designed to
>>> interact with other existing opcodes)?
>>>
>>> http://www.csounds.com/maldonado/Manual/index.htm
>>>
>>> Cheers,
>>> Andrés
>>>
>>>   
>>>       
>>>> I would like to hear from you about the naming conventions and such, if 
>>>> there's a better way to name these opcodes. If you think they would be 
>>>> useful or if they're worthless. Anything.
>>>>
>>>> Also, at the moment I'm using Imlib and Xlib for this and I developed it 
>>>> on gnu/Linux. What library would you use for Windows and MacOS X?
>>>>
>>>> Thanks in advance for the feedback.
>>>>
>>>> Ciao,
>>>>
>>>> c.
>>>>
>>>> p.s. Here's a .csd to test everything:
>>>>
>>>> 
>>>>
>>>> 
>>>> sr=48000
>>>> ksmps=1
>>>> nchnls=2
>>>>
>>>> giimage1 imageload "image.png" ;edit this to point to a valid image path 
>>>> and filename
>>>> giimage1w, giimage1h imagesize giimage1
>>>> prints "giImage1size: %d,%d\n", giimage1w, giimage1h
>>>>
>>>> giimage2 imagecreate 800, 600
>>>>
>>>>         instr 1
>>>> kval linseg 0, p3, 1
>>>> kred, kgreen, kblue imagegetpixel giimage1, kval, 0 ;scans and print the 
>>>> first line of the image (y=0)
>>>> printk 0, kblue
>>>>         endin
>>>>
>>>>         instr 2
>>>> kval linseg 0, p3, 1
>>>> kval2 lfo 1/6,2,0
>>>> kval3 lfo 1/6,4,0
>>>> kval4 lfo 1/6,8,0
>>>> imagesetpixel giimage2, kval,kval2+1/6,1,0,0
>>>> imagesetpixel giimage2, kval,kval3+3/6,0,1,0
>>>> imagesetpixel giimage2, kval,kval4+5/6,0,0,1
>>>>         endin
>>>>
>>>>         instr 3
>>>> imagesave giimage2, "imageout.png"
>>>>         endin
>>>>
>>>>
>>>> 
>>>>
>>>> 
>>>> i1 0 0.1
>>>> i2 1 1
>>>> i3 2 1
>>>> e
>>>>
>>>> 
>>>>
>>>> 
>>>>
>>>>     
>>>>         
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>   
>>>       
>> -- 
>> www.cesaremarilungo.com 
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>     
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>   


-- 
www.cesaremarilungo.com 

Hi folks,

I thought that it would be better to stick with not using FLTK, at least 
on linux, since one of the reasons I wrote these opcodes was for a 
project for the One Laptop Per Child XO Laptop and FLTK is not available 
there. So I will stick with Imlib (just on gnu/Linux) or maybe ImlibGtk 
to maintain compatibility with it.

Anyway, I rewrote the code so far to have the code which load and save 
images at the top of the source in the first two small proxy functions. 
That way it would be really easy to port them on whatever library and 
I'll promise I'll make them available for compiling for those on Windows 
and MacOS X very soon.

I've also put up a page on my website where you can always get the 
latest version during this phase:

http://www.cesaremarilungo.com/node/20

Ciao,

c.

Cesare Marilungo wrote:
> Ok, I'll rewrite the opcodes to use FLTK, then.
>
> It would be great to have them on all platforms.
>
> BTW, here's another test I made which copies an image inside another 
> (just for the sake of it). I thought it wouldn't have been possible 
> without using python or other tricks, but I wasn't aware of the 
> existence of the (fortran style?) loop_xx opcodes:
>
> 
> 
> sr=48000
> ksmps=1
> nchnls=2
>
> giimage1 imageload "image.png"
> giimage2 imagecreate 800,600
>
>    instr 1
> kndx = 0
> kx_ linseg 0, p3, 1
>
> myloop:
> ky_ = kndx/599.0
> kr_ kg_ kb_ imagegetpixel giimage1, kx_, ky_
> imagesetpixel giimage2, kx_, ky_, kr_, kg_, kb_
> loop_lt kndx, 1, 599, myloop
>    endin
>
>    instr 2
> imagesave giimage2, "imageout.png"
>    endin
>
> 
> 
> i1 1 1
> i2 2 1
> e
> 
> 
>
> Ciao,
>
> - c.
>
> Michael Gogins wrote:
>> Since FLTK is used by Csound itself, I suggest using the FLTK image 
>> libraries. The ImageToScore node in CsoundAC already does this. You 
>> can look at frontends/CsoundAC/ImageToScore.cpp to see how the FLTK 
>> image libraries are used, and at SConstruct to see how they are 
>> linked with CsoundAC.dll or .so.
>>
>> As its name suggests, ImageToScore translates an image file into a 
>> CsoundAC score, which can be a node inside a CsoundAC music graph. 
>> Thus, the purposes of Cesare's opcodes and ImageToScore are not the 
>> same.
>>
>> Regards,
>> Mike
>>
>> -----Original Message-----
>>  
>>> From: Cesare Marilungo 
>>> Sent: Nov 19, 2007 12:33 PM
>>> To: csound@lists.bath.ac.uk
>>> Subject: [Csnd] Re: Re: Image opcodes
>>>
>>> Hi Andres,
>>>
>>> I agree with Michael about the default behavior for scaling values. 
>>> Keep in mind that my idea was to use these opcodes to extract 
>>> information     
>> >from images for musical purposes, not for GUIs (I thought there was 
>> a FL  
>>> opcode for this, already). My idea was to add an optional parameter 
>>> to set the behavior you're talking about (mapping r g b values as 
>>> bytes and coords as ints).
>>>
>>> I didn't know about CsoundAV, lots of interesting stuff. Can't try 
>>> it since I'm on gnu/Linux.
>>>
>>> Anyway it would be good reuse stuff wherever it's possible. Another 
>>> problem is which library/ies to use for loading images on the 
>>> various platforms.
>>>
>>> Ciao,
>>>
>>> c.
>>>
>>> Andres Cabrera wrote:
>>>    
>>>> Hi Cesare,
>>>>
>>>> El dom, 18-11-2007 a las 20:40 +0100, Cesare Marilungo escribió:
>>>>        
>>>>> By default these two opcodes use values scaled from 0.0 to 1.0 so 
>>>>> the top left pixel is 0,0 and the r g b values are 0.0 to 1.0 too. 
>>>>> As Michael suggested I plan to add an extra parameter to choose if 
>>>>> you want to use the exact pixel indexes. So 0 would be default, 1 
>>>>> would be with exact pixel indexes and r g b values.
>>>>>
>>>>>             
>>>> Thanks for your work. Just one suggestion to keep values more in line
>>>> with existing opcodes, it might be good to use ranges between 0 and 
>>>> 255
>>>> to keep consistency with the existing FL opcodes like FLcolor, etc.
>>>> Do you think these opcodes could be used to replace the bmopen opcode
>>>> (which is currently only available on CsoundAV, but is designed to
>>>> interact with other existing opcodes)?
>>>>
>>>> http://www.csounds.com/maldonado/Manual/index.htm
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>        
>>>>> I would like to hear from you about the naming conventions and 
>>>>> such, if there's a better way to name these opcodes. If you think 
>>>>> they would be useful or if they're worthless. Anything.
>>>>>
>>>>> Also, at the moment I'm using Imlib and Xlib for this and I 
>>>>> developed it on gnu/Linux. What library would you use for Windows 
>>>>> and MacOS X?
>>>>>
>>>>> Thanks in advance for the feedback.
>>>>>
>>>>> Ciao,
>>>>>
>>>>> c.
>>>>>
>>>>> p.s. Here's a .csd to test everything:
>>>>>
>>>>> 
>>>>>
>>>>> 
>>>>> sr=48000
>>>>> ksmps=1
>>>>> nchnls=2
>>>>>
>>>>> giimage1 imageload "image.png" ;edit this to point to a valid 
>>>>> image path and filename
>>>>> giimage1w, giimage1h imagesize giimage1
>>>>> prints "giImage1size: %d,%d\n", giimage1w, giimage1h
>>>>>
>>>>> giimage2 imagecreate 800, 600
>>>>>
>>>>>         instr 1
>>>>> kval linseg 0, p3, 1
>>>>> kred, kgreen, kblue imagegetpixel giimage1, kval, 0 ;scans and 
>>>>> print the first line of the image (y=0)
>>>>> printk 0, kblue
>>>>>         endin
>>>>>
>>>>>         instr 2
>>>>> kval linseg 0, p3, 1
>>>>> kval2 lfo 1/6,2,0
>>>>> kval3 lfo 1/6,4,0
>>>>> kval4 lfo 1/6,8,0
>>>>> imagesetpixel giimage2, kval,kval2+1/6,1,0,0
>>>>> imagesetpixel giimage2, kval,kval3+3/6,0,1,0
>>>>> imagesetpixel giimage2, kval,kval4+5/6,0,0,1
>>>>>         endin
>>>>>
>>>>>         instr 3
>>>>> imagesave giimage2, "imageout.png"
>>>>>         endin
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>> 
>>>>> i1 0 0.1
>>>>> i2 1 1
>>>>> i3 2 1
>>>>> e
>>>>>
>>>>> 
>>>>>
>>>>> 
>>>>>
>>>>>             
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>>> "unsubscribe csound"
>>>>
>>>>
>>>>         
>>> -- 
>>> www.cesaremarilungo.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>> "unsubscribe csound"
>>>     
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> "unsubscribe csound"
>>
>>   
>
>


-- 
www.cesaremarilungo.com