问题标签 [accelerate-framework]

我正在寻找一种最快/最简单的解决方案来计算存储在数组中的一堆双点的回归。
我试图在 Accelerate 框架或教程中找到合适的功能，但没有运气。

有人做过吗？

我正在使用 Accelerate 框架来解决线性方程组的欠定/超定系统。我正在使用的例程是 dgelsd_，最初来自 LAPACK。

这在模拟器中运行良好，在提供矩阵 a_t 和 b 时，结果在 b 中正确返回。但是，当我在设备上尝试此操作时，结果全为零。

我哪里会出错？我已根据需要为例程分配了一定数量的工作内存，但我使用分析器进行了检查，内存似乎不是问题。

有没有人让 LAPACK 例程在 iPhone 设备上正常工作？谢谢。

编辑：iPhone SDK 4.2 版，设备 iPhone 4

大厅，

我是图像处理的新手，我需要使用 iphone4 进行一些图像处理。仅支持 Iphone 4 kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange/kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange/kCVPixelFormatType_420YpCbCr8BiPlanarfullRange 。

但我需要 YUV420、rgb24 和其他一些。我计划使用Accelerate Framework VimageConversion 库进行转换。但是框架使用 Planar8, PlanarF, ARGB8888, ARGBFFFF, RGBA8888, and RGBAFFFFFormat 进行了所有处理。如何将此格式与 Iphone 支持的格式相关联。我无法得到有关 Planar8, PlanarF, ARGB8888, ARGBFFFF, RGBA8888, and RGBAFFFF格式的任何解释。

谁能解释一下 Planar8、PlanarF、ARGB8888、ARGBFFFF、RGBA8888 和 RGBAFFFF——？

与 Accelerate Framework 的 vU256 相比，使用 OpenSSL 的 BIGNUM 有什么好处，反之亦然？

After watching the WWDC video on the accelerate framework, I saw that it had two packages called BLAS and LAPACK. When they talked about BLAS, it sounded like that wasn't what I wanted however, LAPACK, which they caption "Linear algebra package", sounds like it does what I want to do.

Could you use the second of these two frameworks, LAPACK, to perform functions such as solving equations, factorising, and other basic algebraic operations? - What puzzled me is when I looked in the apple docs, they have very little reference to LAPACK.

As you can see here, they have docs on BLAS and not LAPACK

I would be grateful if someone who knows about the accelerate framework could enlighten me on the topic because I know nothing about it!

我刚刚开始使用 vecLib 框架来制作一个在 Mac OS X 10.7 上进行密集矩阵向量乘法的程序。我做了一个这样的简单程序；将矩阵 a 与向量 x 相乘并将结果添加到向量 y 上。

我在控制台上编译并运行了程序

但结果是这样的；操作没有发生，结果向量仍然是空的。

我是否缺少一些初始化以在 vecLib 框架中运行矩阵和向量函数？

我需要得到方程组的解。为此，我使用函数 sgesv_()。

一切都很好，它返回了解决方案的正确结果。

但我收到一个奇怪的警告。

警告：从不兼容的指针类型传递“sgesv_”的参数 3

我正在使用该功能，因为 Apple 在 WWDC 视频中使用它。

我究竟做错了什么？

a1,a2,b1,b2,c1,c2 是浮点数

我正在使用 Accelerate 框架来提高我在 iPhone 上运行的一段代码的性能。我需要来自 Accelerate 的两个标头，它们是 vdsp 和 vfp。vDSP 工作得很好，但是当我使用来自 vfp 的函数时，我得到了“使用未声明的标识符”。

奇怪的是：当我在模拟器上运行时，我的代码运行良好（即使编辑器仍然指向错误），并且我期望从 vfp 中使用的函数得到的结果也在那里。但是当我尝试在设备上运行时，我得到了错误。

这意味着我的文件链接正确。由于该函数有效，但 XCode 很困惑，因为它仍然说未声明的函数。还是iOS不支持vfp？即使他们应该使用矢量处理器。请帮忙 ：）

我正在开发 iOS 应用程序，用户可以在其中应用一组特定的照片过滤器。每个滤镜基本上都是一组带有特定参数的 Photoshop 动作。这些行动是：

• 水平调整
• 亮度/对比度
• 色相饱和度
• 单一和多重叠加

我已经在我的代码中重复了所有这些操作，使用算术表达式循环遍历图像中的所有像素。但是当我在 iPhone 4 上运行我的应用程序时，每个过滤器需要大约 3-4 秒才能应用，这对于用户来说是相当长的等待时间。图像大小为 640 x 640 像素，这是我的视图大小的 2 倍，因为它显示在 Retina 显示屏上。我发现我的主要问题是每次需要调整伽玛时都会调用 pow() C 函数的级别修改。当然，我使用的是浮点数而不是双精度数，因为 ARMv6 和 ARMv7 使用双精度数很慢。尝试启用和禁用 Thumb 并得到相同的结果。

我的应用程序中最简单的过滤器示例，它运行得非常快（2 秒）。其他过滤器包括更多的表达式和 pow() 调用，从而使它们变慢。

https://gist.github.com/1156760

我见过一些使用 Accelerate Framework vDSP 矩阵转换来快速修改图像的解决方案。我还看到了 OpenGL ES 解决方案。我不确定他们是否能够满足我的需求。但可能只是将我的一组更改转换为一些好的卷积矩阵？

任何意见将是有益的。

谢谢，
安德烈。

I have implemented Demetri's Pitch Detector project for the iPhone and hitting up against two problems. 1) any sort of background noise sends the frequency reading bananas and 2) lower frequency sounds aren't being pitched correctly. I tried to tune my guitar and while the higher strings worked - the tuner could not correctly discern the low E.

The Pitch Detection code is located in RIOInterface.mm and goes something like this ...

Demetri then goes on to determine the 'dominant' frequency as follows:

To start with, I believe I need to apply a LOW PASS FILTER ... but I'm not an FFT expert and not sure exactly where or how to do that against the data returned from the vDSP functions. I'm also not sure how to improve the accuracy of the code in the lower frequencies. There seem to be other algorithms to determine the dominant frequency - but again, looking for a kick in the right direction when using the data returned by Apple's Accelerate framework.

UPDATE:

The accelerate framework actually has some windowing functions. I setup a basic window like this

which I then apply by inserting

before the vDSP_ctoz function. I then change the rest of the code to use 'transferBuffer' instead of outputBuffer ... but so far, haven't noticed any dramatic changes in the final pitch guess.