hi all,
i've added some new features to pix_set : - roisize and roioffset which allow to set only a small part of the whole image - fill which set all the pixels by sending only one value (no need to make a huge list...)
the help patch have been updated and i also make an example 04.pix/27.bitmap_font.pd
feedback are welcome feel free to include it in Gem i'm using it to display text and other simple graphics on a LED matrix
this is in my github repos on the branch "pix_set" git://github.com/avilleret/Gem.git
++ a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
wow, cool,
thanks
Cyrille
Le 07/12/2012 01:50, Antoine Villeret a écrit :
hi all,
i've added some new features to pix_set :
- roisize and roioffset which allow to set only a small part of the whole image
- fill which set all the pixels by sending only one value (no need to
make a huge list...)
the help patch have been updated and i also make an example 04.pix/27.bitmap_font.pd
feedback are welcome feel free to include it in Gem i'm using it to display text and other simple graphics on a LED matrix
this is in my github repos on the branch "pix_set" git://github.com/avilleret/Gem.git
++ a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 12/07/2012 01:50, Antoine Villeret wrote:
hi all,
i've added some new features to pix_set :
- roisize and roioffset which allow to set only a small part of the whole image
- fill which set all the pixels by sending only one value (no need to
make a huge list...)
the help patch have been updated and i also make an example 04.pix/27.bitmap_font.pd
feedback are welcome feel free to include it in Gem
thanks for your patches.
eventually i would like to have generic ROI support for all pix_ objects (apart from some objects where it doesn't make sense). this however, would require a "rewrite" (substantial adaption) of the processing core of all objects :-(
fgmasdr IOhannes
i think this is a good idea i usually make changes to pix_object to fit the requirement of my working projects if i have the opportunity to do that for other objects (and i hope this happens soon) i'll let you know
best
a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/7 IOhannes m zmölnig zmoelnig@iem.at:
On 12/07/2012 01:50, Antoine Villeret wrote:
hi all,
i've added some new features to pix_set :
- roisize and roioffset which allow to set only a small part of the whole
image
- fill which set all the pixels by sending only one value (no need to
make a huge list...)
the help patch have been updated and i also make an example 04.pix/27.bitmap_font.pd
feedback are welcome feel free to include it in Gem
thanks for your patches.
eventually i would like to have generic ROI support for all pix_ objects (apart from some objects where it doesn't make sense). this however, would require a "rewrite" (substantial adaption) of the processing core of all objects :-(
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-07 13:39, Antoine Villeret wrote:
i think this is a good idea i usually make changes to pix_object to fit the requirement of my working projects if i have the opportunity to do that for other objects (and i hope this happens soon) i'll let you know
so my plan is actually something like this: - - add a new property "ROI" to the GemState. - - add a new object [pix_roi] that allows you to set the roi in a normalized form (0..1 rather than 0..<width>); this object will simply set the "ROI" property. - - have the pix_objects use these roi-property.
in order for the latter to work more consistently, it would be nice (in a 2nd step?), to change the architecture of the pix_objects slightly:
- - add new virtual methods called like processLineRGBA(void*data, unsigned int width, imageStruct*img);
for line-wise processing (with context).
GemPixObject would then take care of calling processLine correctly for the given ROI.
if done correctly, we could also utilize this to allow parallel processing of pixes as well (see [1].
fgmasdr IOhannes
[1] http://hirntier.blogspot.co.at/2009/02/parallelizing-video-routines.html
best
a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/7 IOhannes m zmölnig zmoelnig@iem.at:
On 12/07/2012 01:50, Antoine Villeret wrote:
hi all,
i've added some new features to pix_set : - roisize and roioffset which allow to set only a small part of the whole image - fill which set all the pixels by sending only one value (no need to make a huge list...)
the help patch have been updated and i also make an example 04.pix/27.bitmap_font.pd
feedback are welcome feel free to include it in Gem
thanks for your patches.
eventually i would like to have generic ROI support for all pix_ objects (apart from some objects where it doesn't make sense). this however, would require a "rewrite" (substantial adaption) of the processing core of all objects :-(
fgmasdr IOhannes
_______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
_______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
it sounds great,
how can I help ? who starts ?
+ a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/11 IOhannes m zmoelnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-07 13:39, Antoine Villeret wrote:
i think this is a good idea i usually make changes to pix_object to fit the requirement of my working projects if i have the opportunity to do that for other objects (and i hope this happens soon) i'll let you know
so my plan is actually something like this:
- add a new property "ROI" to the GemState.
- add a new object [pix_roi] that allows you to set the roi in a
normalized form (0..1 rather than 0..<width>); this object will simply set the "ROI" property.
- have the pix_objects use these roi-property.
in order for the latter to work more consistently, it would be nice (in a 2nd step?), to change the architecture of the pix_objects slightly:
processLineRGBA(void*data, unsigned int width, imageStruct*img);
- add new virtual methods called like
for line-wise processing (with context).
GemPixObject would then take care of calling processLine correctly for the given ROI.
if done correctly, we could also utilize this to allow parallel processing of pixes as well (see [1].
fgmasdr IOhannes
[1] http://hirntier.blogspot.co.at/2009/02/parallelizing-video-routines.html
best
a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/7 IOhannes m zmölnig zmoelnig@iem.at:
On 12/07/2012 01:50, Antoine Villeret wrote:
hi all,
i've added some new features to pix_set : - roisize and roioffset which allow to set only a small part of the whole image - fill which set all the pixels by sending only one value (no need to make a huge list...)
the help patch have been updated and i also make an example 04.pix/27.bitmap_font.pd
feedback are welcome feel free to include it in Gem
thanks for your patches.
eventually i would like to have generic ROI support for all pix_ objects (apart from some objects where it doesn't make sense). this however, would require a "rewrite" (substantial adaption) of the processing core of all objects :-(
fgmasdr IOhannes
_______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
_______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDG9QQACgkQkX2Xpv6ydvTC8QCfUE8isxKGWz7EKPS4Vz7aNk6w bk8AnjRUwJdQw5r9opjCkDAmyFl5JUup =lJyp -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-11 14:16, Antoine Villeret wrote:
it sounds great,
how can I help ? who starts ?
i started to implement [pix_roi] and adapted [pix_set] accordingly.
[pix_set] now also tries to write on an incoming image (rather than always using it's own image). hopefully this won't break anything.
check whether it does what it should.
fgmasdr IOhannes
is does
thanks
while i understood the need of normalized coordinates for texture in OpenGL, i dislike it in pix_objets, because we deal with array of pix and i think it's more human readable to use pixel coordinate in this case this also add some conversion both in the code and in the patch but this is only my point of view
i started a pix_roi-help.pd and updated pix_set-help.pd (remove my roi messages) (in my repos, on master branch git://github.com/avilleret/Gem.git)
+ a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/11 IOhannes m zmoelnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-11 14:16, Antoine Villeret wrote:
it sounds great,
how can I help ? who starts ?
i started to implement [pix_roi] and adapted [pix_set] accordingly.
[pix_set] now also tries to write on an incoming image (rather than always using it's own image). hopefully this won't break anything.
check whether it does what it should.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDHZwoACgkQkX2Xpv6ydvRKjwCeL1TkkDCUBDclPGijlqmOEwbw N2AAoNZhdnV+BdN6Jbn4r55n4w2eBLAO =NL2h -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-11 18:48, Antoine Villeret wrote:
is does
thanks
while i understood the need of normalized coordinates for texture in OpenGL, i dislike it in pix_objets, because we deal with array of pix and i think it's more human readable to use pixel coordinate in this case this also add some conversion both in the code and in the patch but this is only my point of view
i understand that (esp. in the context of pix_set), but i want ROI to also work with simpler effects where you might want to specify an area, where the effect is applied, without having to care about the pix dimensions. also Gem uses normalized values whenever possible.
i started a pix_roi-help.pd and updated pix_set-help.pd (remove my roi messages) (in my repos, on master branch git://github.com/avilleret/Gem.git)
cool
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-11 19:00, IOhannes m zmoelnig wrote:
On 2012-12-11 18:48, Antoine Villeret wrote:
is does
thanks
while i understood the need of normalized coordinates for texture in OpenGL, i dislike it in pix_objets, because we deal with array of pix and i think it's more human readable to use pixel coordinate in this case this also add some conversion both in the code and in the patch but this is only my point of view
i understand that (esp. in the context of pix_set), but i want ROI to also work with simpler effects where you might want to specify an area, where the effect is applied, without having to care about the pix dimensions. also Gem uses normalized values whenever possible.
however, i'm not so much opposed to add a special message to specify the ROI in absolute values and [pix_roi] would then normalize the values internally.
fgmadr IOhannes
and what about the opposite ? stay in discrete coordinate in the code and add a normalized message ? in that way the conversion is done only once (when the ROI is set in normalized coord) and not each time we set the data (for pix_set) maybe i'm going wrong...
+ a
-- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/11 IOhannes m zmoelnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-11 19:00, IOhannes m zmoelnig wrote:
On 2012-12-11 18:48, Antoine Villeret wrote:
is does
thanks
while i understood the need of normalized coordinates for texture in OpenGL, i dislike it in pix_objets, because we deal with array of pix and i think it's more human readable to use pixel coordinate in this case this also add some conversion both in the code and in the patch but this is only my point of view
i understand that (esp. in the context of pix_set), but i want ROI to also work with simpler effects where you might want to specify an area, where the effect is applied, without having to care about the pix dimensions. also Gem uses normalized values whenever possible.
however, i'm not so much opposed to add a special message to specify the ROI in absolute values and [pix_roi] would then normalize the values internally.
fgmadr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDHeHAACgkQkX2Xpv6ydvTIGQCeO2tuvkrwvMWD85eYk7wV17CE o6AAoJjTHpoqTjp+UDuiK95zQHiWDbIm =8jSq -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 12/11/2012 19:24, Antoine Villeret wrote:
and what about the opposite ? stay in discrete coordinate in the code and add a normalized message ? in that way the conversion is done only once (when the ROI is set in normalized coord) and not each time we set the data (for pix_set) maybe i'm going wrong...
i'd rather not. the way it is now, [pix_roi] is independent of the actual pixes. i very much like it that way.
one could provide helper-functions to easily convert a given ROI/pix to absolute coordinates on the C++ layer, if you care about the programming overhead. the computational overhead is small enough.
fgmasdr IOhannes
ok you're the boss :-)
about the pix_set, i had a fill method which doesn't care about the ROI should it ?
+ a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/11 IOhannes m zmölnig zmoelnig@iem.at:
On 12/11/2012 19:24, Antoine Villeret wrote:
and what about the opposite ? stay in discrete coordinate in the code and add a normalized message ? in that way the conversion is done only once (when the ROI is set in normalized coord) and not each time we set the data (for pix_set) maybe i'm going wrong...
i'd rather not. the way it is now, [pix_roi] is independent of the actual pixes. i very much like it that way.
one could provide helper-functions to easily convert a given ROI/pix to absolute coordinates on the C++ layer, if you care about the programming overhead. the computational overhead is small enough.
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Tue, Dec 11, 2012 at 1:48 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
one could provide helper-functions to easily convert a given ROI/pix to absolute coordinates on the C++ layer, if you care about the programming overhead. the computational overhead is small enough.
It should be easy enough to do this on the patcher level with pix_info, pix_film outlet etc. right?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-11 18:48, Antoine Villeret wrote:
i started a pix_roi-help.pd and updated pix_set-help.pd (remove my roi messages) (in my repos, on master branch git://github.com/avilleret/Gem.git)
thanks applied. pushed.
fgmasdr IOhannes
-
Antoine Villeret -
chris clepper -
Cyrille Henry -
IOhannes m zmoelnig -
IOhannes m zmölnig