matplotlib-devel Mailing List for matplotlib

I just committed Ariel's csd changes to the 99 branch, and when I
attempted to merge I first got a failure and now the branch is not
showing up in the available branches. Any ideas? The branch was
listed on a 'svnmerge.py merge' command *before* the failure.
jdhunter@uqbar:mpl> svnmerge.py merge
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
svnmerge: multiple sources found. Explicit source argument
(-S/--source) required.
The merge sources available are:
 /branches/v0_99_maint
 /branches/mathtex
jdhunter@uqbar:mpl> svnmerge.py merge -Sv0_99_maint
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
property 'svnmerge-integrated' set on '.'
svnmerge: command execution failed (exit code: 1)
svn --non-interactive propdel "svnmerge-blocked" "."
svn: Attempting to delete nonexistent property 'svnmerge-blocked'
jdhunter@uqbar:mpl> svnmerge.py merge -Sv0_99_maint
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous
substring of a repository path, nor a working directory
jdhunter@uqbar:mpl> svnmerge.py merge
/home/jdhunter/dev/bin/svnmerge.py:71: DeprecationWarning: The popen2
module is deprecated. Use the subprocess module.
 import sys, os, getopt, re, types, tempfile, time, popen2, locale
svnmerge: multiple sources found. Explicit source argument
(-S/--source) required.
The merge sources available are:
 /branches/v0_91_maint
 /branches/mathtex
 /branches/v0_98_5_maint

Hi -
the maximal difference in this case is of about 6 (units?), which is an
approximately 50% difference. This is in one point in the spectrum which has
a relatively small value - the maximal peaks in the spectra are on the order
of 1200, so in the grand scheme of things, not that horrible. Other large
differences are on the order of 4, which is approximately 5% or less of
those points.
Thanks - Ariel
PS for some reason, matplotlib-devel will not get your email unless you hit
"reply all", so they have been getting my emails, but not yours. I am not
sure whether that is what you intended, so I thought I would mention it.
On Mon, Feb 8, 2010 at 1:24 AM, Ludwig Schwardt
<lud...@gm...>wrote:
> Hi,
>
> On Mon, Feb 8, 2010 at 5:25 AM, Ariel Rokem <ar...@be...> wrote:
> > I don't think that the cause of the discrepancy is because of the
> > hamming/hanning window difference. I do set the window in the matlab part
> to
> > also be a hanning window of length nfft.
>
> I suspected you gave the same window to both, but I was just
> checking... :-) To find those smaller discrepancies might be a bit
> harder then, requiring a careful comparison of the various steps
> involved. Just for interest's sake, how big are the differences we are
> talking about?
>
> Regards,
> Ludwig
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Agg backends (in addition to the ps backend) now support
affine-transformed image.
Regards,
-JJ
On Thu, Dec 17, 2009 at 7:05 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Thu, Dec 17, 2009 at 5:03 PM, Andrew Straw <str...@as...> wrote:
>> It's not clear to me if this proposal lets one specify any arbitrary affine
>> transformation. Does it?
>
> I believe it does. 3 coordinates will define 6 equations where we have
> 6 unknowns of the affine matrix.
> The question is how user want to specify the transform.
> The extended extent keyword would be useful for the cases like the
> pseudo-perspective projection that you mentioned. But, it will not be
> very convenient for the cases like simple rotation.
>
>
>>
>> In general -- very nice. Thanks.
>>
>> In specific, I think the way you have already implemented things is
>> sufficient. I think if a user can write a little helper function (as in your
>> demo) to avoid a dumbed-down API being part of MPL, that would be best.
>> Anyone specifying their own affine transform is probably going to want a
>> pretty precise level of control, anyway. (Of course if your extent keyword
>> proposal is already a general purpose API, then please ignore this comment.)
>
> I, personally, don't like the idea that user needs to define his/her
> own transform to rotate/skew the image. Rotation and skew seems more
> like properties of the image, rather than the transform.
>
> Anyhow, unless others step in, I may leave it as is (partially because
> I don't have much use case for rotated/skewed images for now). And, I
> hope someone implement similar affine transform for other backends.
> For the backends that requires resampling (agg, etc.), it might be
> better if the affine transform is taken care during the resampling
> (i.e., in the Image.draw method) rather than to be delegated to the
> backends.
>
> Regards,
>
> -JJ
>
>>
>> -Andrew
>>
>

Thanks for reporting this. I wasn't aware of the issue.
Since I don't have a libpng-1.4 to verify the fix with, are you able to checkout from SVN trunk and test it?
Mike

Hi Ludwig (responding also to list),
I don't think that the cause of the discrepancy is because of the
hamming/hanning window difference. I do set the window in the matlab part to
also be a hanning window of length nfft.
Cheers,
Ariel
On Sun, Feb 7, 2010 at 7:45 AM, Ludwig Schwardt
<lud...@gm...>wrote:
> Hi,
>
> On Sun, Feb 7, 2010 at 12:46 AM, Ariel Rokem <ar...@be...> wrote:
> > I don't think that a major reworking of the logic of the function is
> needed.
> > Simply replacing the line you mentioned with:
> >
> > Pxy *= 1 / (np.abs(windowVals)**2).sum()
> > Pxy[1:-1] *= scaling_factor
> > if scale_by_freq:
> > Pxy[[0,-1]] /= Fs
>
> I agree. I was hoping the first two lines above would be sufficient.
> Then I saw scaling_factor also included Fs if scaling by frequency,
> and Pxy is of shape (numFreqs,n), i.e. not a straightforward 1-D
> array, which caused me to reserve my judgment a little bit... :-)
>
> > What does become more apparent when I do that is that in frequency bands
> in
> > which the power is rather small, the ratio discrepancies between the mlab
> > result and the matlab result can be rather large, on the order of a
> factor
> > of 2-2.5, even when the differences are tiny. Similarly, when the power
> is
> > rather large, there can be non-negligible differences between the two
> > results. Is there anything to do about that?
>
> Could this be because Matlab uses a Hamming window by default, while
> mlab uses a *Hanning* window by default? Very similar-sounding names,
> and also very similar windows numerically (but not exactly the
> same)...
>
> Ludwig
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel