Bugs item #3453593, was opened at 2011-12-07 06:14
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3453593&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build-system
Group: win32
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: plugins don't work with MinGW builds
Initial Comment:
when building Gem with MinGW, the resulting Gem.dll cannot use any of the resulting plugins (e.g. gem_imageSGI.dll)
uncommenting the debugging printout in PluginFactoryTIMPL.h reveals, that Gem and the plugin see _different_ pluginfactories! (at least their addresses differ)
system:
- Gem-0.93git59cc4030375e20
- Windows7
- MinGW/MSYS
- g++-4.6.1
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3453593&group_…
Bugs item #3453590, was opened at 2011-12-07 06:10
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3453590&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build-system
Group: win32
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: MinGW compiled GemBase crashes
Initial Comment:
when using Gem compiled with MinGW, virtually all objectclasses derived from GemBase crash when they receive any message.
only GemBase subclasses are affected, other objectclasses like [gemwin] or [gemhead] work fine.
system:
- Gem-0.93git59cc4030375e20
- Windows7
- MinGW/MSYS
- g++-4.6.1
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3453590&group_…
Hello Iohannes / list,
I've worked on a few help files. It was mainly help files that were not
in the Gem format.
I've done that using git.
You can find them here:
git@github.com:nixhol/Gem.git
the name of the branch is:
help-files
I've cloned the Gem sourceforge repository, then i've created a branch,
worked on the files, and then i've pushed my modifs on my github repository.
Is this the good workflow for contributing to Gem using git? or do you
prefer another way?
Thanks
Nicolas
--
http://nim.on.free.fr
Bugs item #3195435, was opened at 2011-02-28 12:00
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3195435&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: any operating system
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_film prints an error msg if frame <0 but not if = 0
Initial Comment:
This is a very minor issue, however...
The right inlet of [pix_film] accepts a frame number which ranges from 1 to N if the video has N frames.
If it receives a negative frame number, it prints an error message:
error: [pix_film]: selection number must be > 0
To be consistent, it should print the same error message when it receives 0 as the frame number, but it doesn't.
Indeed I thing the condition is actually that the frame be >=1 (consider floats!)
Also I would suggest to specify in the help patch that the frame numbers start from 1 (unless I am the only one who would expect it to start from 0)
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-12-05 02:00
Message:
i agree that it should be consistent.
i also agree that the frames should range from 0..(N-1) rather than 1..N?
i even think that for (most?) backends the frame number ranges from
0..(N-1).
does the problem still exist with Gem-0.93?
(minor sidenote: the error message says indeed that the frame number must
be ">0" but the check is done whether it is "!<0", so this should be ok)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3195435&group_…
Bugs item #3336856, was opened at 2011-06-27 02:28
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3336856&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: linux
>Status: Pending
>Resolution: Postponed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_film crashes with Apple Animation (runlength) videos
Initial Comment:
pix_film crashes when loading png-encoded videos.
I encoded them with ffmpeg using -vcodec png.
I don't know which backend is being used for decoding the video files (how can I find out?) but lqtplay plays the same files without crashing (and Gem is linked against the same libquicktime as lqtplayed, at least that's what ldd says).
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-12-05 01:56
Message:
more information is requried in order to fix this.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-06-27 03:09
Message:
could you please provide a (short) movie that triggers the problem?
also, please provide a backtrace of the crash,
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-06-27 03:09
Message:
could you provide a backtrace of the crash?
on linux/osx/similar you can use gdb for producing one:
$ gdb -args /path/to/pd -nrt -stderr -lib Gem -open /my/faulty/patch.pd
[...]
(gdb) run
[... do something to trigger the crasher bug ...]
(gdb) backtrace
[...]
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-06-27 02:36
Message:
Sorry It's NOT PNG, it's Apple Animation codec (runlength). I was testing
several videos and I got confused.
I edited the summary but I can't seem to edit the description.
The rest of the description is correct: lqtplay does not crash, Pd does.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3336856&group_…
Bugs item #3448076, was opened at 2011-12-02 01:27
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: rendering (e.g. display)
Group: any operating system
>Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [text3d]: problems with strings starting with newline
Initial Comment:
When sending [text3d] a 'string' message starting with a newline character (10), the Gem window shows an unexpected text, where every newline character (including the first one) is replaced by a character looking similar to [] (an empty box).
Example:
[string 10 97 97 10 98 98(
is rendered as:
[]aa[]bb
[string 97 97 10 98 98(
is (correctly) rendered as:
aa
bb
This is on / with:
- Gem 0.93.git cb1745f
- Pd 0.43.1test4
- Ubuntu 11.04
and:
- Pd-extended 0.42.6
- Mac OS X (10.6)
Credit for finding this bug goes to Michèle Graf and Selina Grüter
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2011-12-02 05:08
Message:
I can confirm it is fixed. Thanks
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-12-02 02:48
Message:
should be fixed with git.d5d0b83dc
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Bugs item #3448076, was opened at 2011-12-02 01:27
Message generated for change (Comment added) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: rendering (e.g. display)
Group: any operating system
Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [text3d]: problems with strings starting with newline
Initial Comment:
When sending [text3d] a 'string' message starting with a newline character (10), the Gem window shows an unexpected text, where every newline character (including the first one) is replaced by a character looking similar to [] (an empty box).
Example:
[string 10 97 97 10 98 98(
is rendered as:
[]aa[]bb
[string 97 97 10 98 98(
is (correctly) rendered as:
aa
bb
This is on / with:
- Gem 0.93.git cb1745f
- Pd 0.43.1test4
- Ubuntu 11.04
and:
- Pd-extended 0.42.6
- Mac OS X (10.6)
Credit for finding this bug goes to Michèle Graf and Selina Grüter
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2011-12-02 05:08
Message:
I can confirm it is fixed. Thanks
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-12-02 02:48
Message:
should be fixed with git.d5d0b83dc
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Bugs item #3448076, was opened at 2011-12-02 01:27
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: rendering (e.g. display)
Group: any operating system
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [text3d]: problems with strings starting with newline
Initial Comment:
When sending [text3d] a 'string' message starting with a newline character (10), the Gem window shows an unexpected text, where every newline character (including the first one) is replaced by a character looking similar to [] (an empty box).
Example:
[string 10 97 97 10 98 98(
is rendered as:
[]aa[]bb
[string 97 97 10 98 98(
is (correctly) rendered as:
aa
bb
This is on / with:
- Gem 0.93.git cb1745f
- Pd 0.43.1test4
- Ubuntu 11.04
and:
- Pd-extended 0.42.6
- Mac OS X (10.6)
Credit for finding this bug goes to Michèle Graf and Selina Grüter
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-12-02 02:48
Message:
should be fixed with git.d5d0b83dc
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Bugs item #3448076, was opened at 2011-12-02 01:27
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: rendering (e.g. display)
Group: any operating system
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [text3d]: problems with strings starting with newline
Initial Comment:
When sending [text3d] a 'string' message starting with a newline character (10), the Gem window shows an unexpected text, where every newline character (including the first one) is replaced by a character looking similar to [] (an empty box).
Example:
[string 10 97 97 10 98 98(
is rendered as:
[]aa[]bb
[string 97 97 10 98 98(
is (correctly) rendered as:
aa
bb
This is on / with:
- Gem 0.93.git cb1745f
- Pd 0.43.1test4
- Ubuntu 11.04
and:
- Pd-extended 0.42.6
- Mac OS X (10.6)
Credit for finding this bug goes to Michèle Graf and Selina Grüter
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3448076&group_…
Hello list,
I was wondering if the problem of the relative path of [pix_write] under
osx may be fixed soon. For reminder the actual behavior (gem compiled
this morning, used with pd-extended 0.42.5, osx.6.8) is:
- if you send no filename, you have in the terminal:
error: ERROR: -43 in GraphicsExportSetOutputFile()
error: GEM: Unable to save image to 'gem00000.tif'
- if you send a relative filename, eg. [file toto(, you have the same error:
error: ERROR: -43 in GraphicsExportSetOutputFile()
error: GEM: Unable to save image to 'toto00000.tif'
- if you send a filename including the "~" home variable, it gives the
same error.
It only works if you set pix_write to an absolute filename inside an
existing directory, eg. [file /Users/nix/snap_pd/test (.
From what i've seen in workshop, this is a major difficulty for learners.
They are not specially used to explicit a directory from root, and they
must not have spaces in any directory name used.
It makes also a patch containing pix_write on an osx computer non
directly usable on any another ...
Is there any possibility to have relative path in pix_write under osx,
or can we imagine some workaround?
it will be of great help
thanks,
n
--
http://nim.on.free.fr
Bugs item #3445962, was opened at 2011-11-30 03:15
Message generated for change (Comment added) made by nimon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_writer write rgba images - osx
Initial Comment:
I must insert a [pix_rgba] before [pix_writer] to have the good image written.
It seems [pix_writer] writes rgb images even if it receives yuv data.
osx.6.8
gem from current git
----------------------------------------------------------------------
>Comment By: Nicolas Montgermont (nimon)
Date: 2011-12-01 02:06
Message:
it works now.
thanks.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:52
Message:
should be fixed in git.736f0982
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 04:51
Message:
right sorry,
pix_snap converts to rgb, so forget about the last line of my last
comment.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-11-30 04:07
Message:
i think the expected behavior for pix_write is to convert yuv image to rgb
befor recording it to the disk.
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 03:55
Message:
Maybe I was not clear enough.
If I use [pix_writer] just after [pix_video] I get a totally distorted
image.
Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv]
and then [pix_writer].
It looks like [pix_writer] is not testing the format of the texture and
assume it's rgb even if it's not the case.
The expected behavior is to have the same result with
[pix_snap]+[pix_writer] and [pix_write]
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:46
Message:
what is the expected behaviour?
i don't think you can natively write YUV-images in TIF; JPEG uses their own
colorspace anyhow.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Bugs item #3445361, was opened at 2011-11-29 09:32
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_write quality not working - osx
Initial Comment:
pix_write create exactly the same jpg file when specifying type = 1 or type = 99
see attached captured file (from pix_image help file) for the two quality.
GEM: ver: 0.93.git 2687102
OSX 10.6.8
Image saving support: QT
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-11-30 07:49
Message:
time to build the gmerlin, etc. plugins for Mac OS X?
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 05:59
Message:
right...
a pity!
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 05:54
Message:
i checked again, and using an apple app like "Preview", and it behaves the
same.
go thank apple that their strive for happy customers does not allow you to
save a jpeg (using QuickTime) with "unacceptable" quality.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:52
Message:
what is the expected behaviour?
[pix_write] will request the backend to write between lossless
(quality=100) and "lowest possible quality" (0).
the operating system defines what "lowest" quality means. on OSX this would
be "codecMinQuality" (whatever that means).
[pix_write] currently does not really allow to set a quality=0 for jpeg
images (since "0" automatically means: lossless TIFF), so quality=1 should
be a "bit" better than "codecMinQuality".
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 00:45
Message:
I can now see a difference between type=1 and type=99 but it is still very
low.
The image with quality = 1 is still very clean and has a certain weight.
Writing the output of example/04.pix/01.image, it gives :
type = 1 : 6771 bytes
type = 99 : 12 928 bytes
The new result of pix_write for type = 1 is attached.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-29 10:39
Message:
thanks. should be fixed in git with rev.981527f2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Bugs item #3445962, was opened at 2011-11-30 03:15
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_writer write rgba images - osx
Initial Comment:
I must insert a [pix_rgba] before [pix_writer] to have the good image written.
It seems [pix_writer] writes rgb images even if it receives yuv data.
osx.6.8
gem from current git
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:52
Message:
should be fixed in git.736f0982
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 04:51
Message:
right sorry,
pix_snap converts to rgb, so forget about the last line of my last
comment.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-11-30 04:07
Message:
i think the expected behavior for pix_write is to convert yuv image to rgb
befor recording it to the disk.
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 03:55
Message:
Maybe I was not clear enough.
If I use [pix_writer] just after [pix_video] I get a totally distorted
image.
Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv]
and then [pix_writer].
It looks like [pix_writer] is not testing the format of the texture and
assume it's rgb even if it's not the case.
The expected behavior is to have the same result with
[pix_snap]+[pix_writer] and [pix_write]
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:46
Message:
what is the expected behaviour?
i don't think you can natively write YUV-images in TIF; JPEG uses their own
colorspace anyhow.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Bugs item #3445962, was opened at 2011-11-30 03:15
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_writer write rgba images - osx
Initial Comment:
I must insert a [pix_rgba] before [pix_writer] to have the good image written.
It seems [pix_writer] writes rgb images even if it receives yuv data.
osx.6.8
gem from current git
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:52
Message:
should be fixed in git.736f0982
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 04:51
Message:
right sorry,
pix_snap converts to rgb, so forget about the last line of my last
comment.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-11-30 04:07
Message:
i think the expected behavior for pix_write is to convert yuv image to rgb
befor recording it to the disk.
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 03:55
Message:
Maybe I was not clear enough.
If I use [pix_writer] just after [pix_video] I get a totally distorted
image.
Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv]
and then [pix_writer].
It looks like [pix_writer] is not testing the format of the texture and
assume it's rgb even if it's not the case.
The expected behavior is to have the same result with
[pix_snap]+[pix_writer] and [pix_write]
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:46
Message:
what is the expected behaviour?
i don't think you can natively write YUV-images in TIF; JPEG uses their own
colorspace anyhow.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Patches item #3445617, was opened at 2011-11-29 15:30
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: updated .gitgnore to ignore all build products
Initial Comment:
Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:23
Message:
config.h.in is generated;
but build/autoconf/Makefile is not, and that get's caught by the "Makefile"
clause
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-11-30 06:12
Message:
which of the files that are in their are not generated? config.h.in is
perhaps the only one I can think of, but the build modifies that file,
which is strange
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:03
Message:
unfortunately it also ignores some files that are not generated
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Patches item #3445617, was opened at 2011-11-29 15:30
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: updated .gitgnore to ignore all build products
Initial Comment:
Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:23
Message:
config.h.in is generated;
but build/autoconf/Makefile is not, and that get's caught by the "Makefile"
clause
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-11-30 06:12
Message:
which of the files that are in their are not generated? config.h.in is
perhaps the only one I can think of, but the build modifies that file,
which is strange
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:03
Message:
unfortunately it also ignores some files that are not generated
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Patches item #3445617, was opened at 2011-11-29 15:30
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: updated .gitgnore to ignore all build products
Initial Comment:
Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-11-30 06:12
Message:
which of the files that are in their are not generated? config.h.in is
perhaps the only one I can think of, but the build modifies that file,
which is strange
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:03
Message:
unfortunately it also ignores some files that are not generated
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Patches item #3445617, was opened at 2011-11-29 15:30
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: updated .gitgnore to ignore all build products
Initial Comment:
Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 06:03
Message:
unfortunately it also ignores some files that are not generated
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Bugs item #3445361, was opened at 2011-11-29 09:32
Message generated for change (Comment added) made by nimon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_write quality not working - osx
Initial Comment:
pix_write create exactly the same jpg file when specifying type = 1 or type = 99
see attached captured file (from pix_image help file) for the two quality.
GEM: ver: 0.93.git 2687102
OSX 10.6.8
Image saving support: QT
----------------------------------------------------------------------
>Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 05:59
Message:
right...
a pity!
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 05:54
Message:
i checked again, and using an apple app like "Preview", and it behaves the
same.
go thank apple that their strive for happy customers does not allow you to
save a jpeg (using QuickTime) with "unacceptable" quality.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:52
Message:
what is the expected behaviour?
[pix_write] will request the backend to write between lossless
(quality=100) and "lowest possible quality" (0).
the operating system defines what "lowest" quality means. on OSX this would
be "codecMinQuality" (whatever that means).
[pix_write] currently does not really allow to set a quality=0 for jpeg
images (since "0" automatically means: lossless TIFF), so quality=1 should
be a "bit" better than "codecMinQuality".
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 00:45
Message:
I can now see a difference between type=1 and type=99 but it is still very
low.
The image with quality = 1 is still very clean and has a certain weight.
Writing the output of example/04.pix/01.image, it gives :
type = 1 : 6771 bytes
type = 99 : 12 928 bytes
The new result of pix_write for type = 1 is attached.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-29 10:39
Message:
thanks. should be fixed in git with rev.981527f2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Bugs item #3445361, was opened at 2011-11-29 09:32
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
>Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_write quality not working - osx
Initial Comment:
pix_write create exactly the same jpg file when specifying type = 1 or type = 99
see attached captured file (from pix_image help file) for the two quality.
GEM: ver: 0.93.git 2687102
OSX 10.6.8
Image saving support: QT
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 05:54
Message:
i checked again, and using an apple app like "Preview", and it behaves the
same.
go thank apple that their strive for happy customers does not allow you to
save a jpeg (using QuickTime) with "unacceptable" quality.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:52
Message:
what is the expected behaviour?
[pix_write] will request the backend to write between lossless
(quality=100) and "lowest possible quality" (0).
the operating system defines what "lowest" quality means. on OSX this would
be "codecMinQuality" (whatever that means).
[pix_write] currently does not really allow to set a quality=0 for jpeg
images (since "0" automatically means: lossless TIFF), so quality=1 should
be a "bit" better than "codecMinQuality".
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 00:45
Message:
I can now see a difference between type=1 and type=99 but it is still very
low.
The image with quality = 1 is still very clean and has a certain weight.
Writing the output of example/04.pix/01.image, it gives :
type = 1 : 6771 bytes
type = 99 : 12 928 bytes
The new result of pix_write for type = 1 is attached.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-29 10:39
Message:
thanks. should be fixed in git with rev.981527f2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Bugs item #3445962, was opened at 2011-11-30 03:15
Message generated for change (Comment added) made by nimon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_writer write rgba images - osx
Initial Comment:
I must insert a [pix_rgba] before [pix_writer] to have the good image written.
It seems [pix_writer] writes rgb images even if it receives yuv data.
osx.6.8
gem from current git
----------------------------------------------------------------------
>Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 04:51
Message:
right sorry,
pix_snap converts to rgb, so forget about the last line of my last
comment.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-11-30 04:07
Message:
i think the expected behavior for pix_write is to convert yuv image to rgb
befor recording it to the disk.
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 03:55
Message:
Maybe I was not clear enough.
If I use [pix_writer] just after [pix_video] I get a totally distorted
image.
Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv]
and then [pix_writer].
It looks like [pix_writer] is not testing the format of the texture and
assume it's rgb even if it's not the case.
The expected behavior is to have the same result with
[pix_snap]+[pix_writer] and [pix_write]
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:46
Message:
what is the expected behaviour?
i don't think you can natively write YUV-images in TIF; JPEG uses their own
colorspace anyhow.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Bugs item #3445962, was opened at 2011-11-30 03:15
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_writer write rgba images - osx
Initial Comment:
I must insert a [pix_rgba] before [pix_writer] to have the good image written.
It seems [pix_writer] writes rgb images even if it receives yuv data.
osx.6.8
gem from current git
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-11-30 04:07
Message:
i think the expected behavior for pix_write is to convert yuv image to rgb
befor recording it to the disk.
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 03:55
Message:
Maybe I was not clear enough.
If I use [pix_writer] just after [pix_video] I get a totally distorted
image.
Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv]
and then [pix_writer].
It looks like [pix_writer] is not testing the format of the texture and
assume it's rgb even if it's not the case.
The expected behavior is to have the same result with
[pix_snap]+[pix_writer] and [pix_write]
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:46
Message:
what is the expected behaviour?
i don't think you can natively write YUV-images in TIF; JPEG uses their own
colorspace anyhow.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Bugs item #3445962, was opened at 2011-11-30 03:15
Message generated for change (Comment added) made by nimon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_writer write rgba images - osx
Initial Comment:
I must insert a [pix_rgba] before [pix_writer] to have the good image written.
It seems [pix_writer] writes rgb images even if it receives yuv data.
osx.6.8
gem from current git
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 03:55
Message:
Maybe I was not clear enough.
If I use [pix_writer] just after [pix_video] I get a totally distorted
image.
Exactly the same if I use [pix_image] on a rgb image, and then [pix_yuv]
and then [pix_writer].
It looks like [pix_writer] is not testing the format of the texture and
assume it's rgb even if it's not the case.
The expected behavior is to have the same result with
[pix_snap]+[pix_writer] and [pix_write]
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:46
Message:
what is the expected behaviour?
i don't think you can natively write YUV-images in TIF; JPEG uses their own
colorspace anyhow.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445962&group_…
Bugs item #3445361, was opened at 2011-11-29 09:32
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nicolas Montgermont (nimon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_write quality not working - osx
Initial Comment:
pix_write create exactly the same jpg file when specifying type = 1 or type = 99
see attached captured file (from pix_image help file) for the two quality.
GEM: ver: 0.93.git 2687102
OSX 10.6.8
Image saving support: QT
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-30 03:52
Message:
what is the expected behaviour?
[pix_write] will request the backend to write between lossless
(quality=100) and "lowest possible quality" (0).
the operating system defines what "lowest" quality means. on OSX this would
be "codecMinQuality" (whatever that means).
[pix_write] currently does not really allow to set a quality=0 for jpeg
images (since "0" automatically means: lossless TIFF), so quality=1 should
be a "bit" better than "codecMinQuality".
----------------------------------------------------------------------
Comment By: Nicolas Montgermont (nimon)
Date: 2011-11-30 00:45
Message:
I can now see a difference between type=1 and type=99 but it is still very
low.
The image with quality = 1 is still very clean and has a certain weight.
Writing the output of example/04.pix/01.image, it gives :
type = 1 : 6771 bytes
type = 99 : 12 928 bytes
The new result of pix_write for type = 1 is attached.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-29 10:39
Message:
thanks. should be fixed in git with rev.981527f2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3445361&group_…
Patches item #3445617, was opened at 2011-11-29 15:30
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: updated .gitgnore to ignore all build products
Initial Comment:
Attached is an updated .gitignore to ignore all build projects, including all the autotools stuff.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507081&aid=3445617&group_…