Did anyone try to benchmark the loss of CPU cycles and FPS on BGR → RGB conversion compared to dealing with direct frame stream?
Direct frame stream is some memory region where BGR values for a single frame are written. I guess that takes one RAM cycle. And then to convert to RGB, one need to go over all pixels and swap their value one by one, loosing one CPU cycle and two RAM cycles per pixel.
this sounds like “much ado about nothing”.
do you have an actual use-case ?
this sounds like “much ado about nothing”.
I don’t get it. Can you rephrase?
do you have an actual use-case ?
Dozens. From designing hard real-time control systems to non-lagging zoom backgrounds, but I am afraid that will derail the topic. Right now I would like to hear from people who know the low level details.
I suspect you might get more traction if you provided some details about what you are doing, what kind of hardware you are running on, and what kind of performance hit you are currently taking.
I think the “much ado about nothing” comment comes from the fact that BGR->RGB conversion is just byte reordering (as opposed to colorspace conversions which require more work), so it’s pretty fast and in most applications is not a significant performance consideration. (Have you benchmarked it on your platform?)
Maybe in your application the conversion is problematic - if so I bet you’d get more interest if you presented some details. For example “I’m already saturating my memory bus because XYZ, so I really can’t afford the extra 5% it takes to do the conversion.”
There could be several ways to speed up the conversion - maybe you are already doing a memcpy of the data and you could implement a version of memcpy that swaps the bytes as part of the process. Maybe you are loading it into texture memory for use in a 3D graphics context and can get the conversion done “for free” based on how you load/use the texture. Maybe you can configure the device that generates the frames to provide the data in RGB format. And maybe none of those things are necessary because the conversion happens fast enough that it’s not worth worrying about. Or maybe you’d be better optimizing other parts of your code. Without details it’s hard to know.
I just want to know more about different technologies before making any decisions. No specific hardware at this point. In the past we’ve been using Arduino and RPi for interactive A/V installations. In our setup the lag was significant and we couldn’t overcome it, because nobody knows enough about what is going on the lowest level.
Understanding how just byte reordering affects performance is a good starting point.
(Have you benchmarked it on your platform?)
That’s the question I asked in the first post. Google didn’t show any results, and it is hard to believe that nobody did any benchmarking.
there are performance tests for this. run those on your hardware and you know.
that said, bgr to rgb conversion is a very rare thing in opencv, you’ll only need it when interfacing with other libraries with a different pixel order convention (e.g. blitting images in qt gui)
i think, your question is far too abstract.
there are performance tests for this. run those on your hardware and you know.
Thanks for the pointer. I probably shouldn’t choose C++ forum, because I don’t know C++, but it seemed to be the most appropriate place for a low level discussion.
that said, bgr to rgb conversion is a very rare thing in opencv,
My feeling is that this operation is quite popular, and a simple search on GitHub alone for it gives 250k results Code search results · GitHub
that is all beside the point.
you need to get more specific. you need to come up with performance numbers (since that’s what you want to discuss, performance). you need to present some basis for discussion. so far it’s been “I’m worried, what if”.
you criticized some byte reordering, yet what you said in the first post (“direct”, “stream”, “memory region”, “a cycle”) sounds too… vague to be useful. I’m inclined to wonder how much meaning you see in those words. yes, obviously that reordering costs something, whenever it’s needed. that’s a tiresome point to make.
remember, we’re all autists here. we can smell bullshit and some of us don’t have the social graces to bite our tongues or to defer judgment until the evidence is overwhelming.
all day people show up (here, stack overflow, anywhere) with nothing but a cry for help, and then people like us are expected to read minds, use crystal balls, whatever, to figure out what might be the issue. we’re skilled at keyhole surgery. we won’t just hold an entire lecture presenting some topic that’s already got plenty of exposition everywhere else (books, actual lectures, …). nor do we enjoy imagining all possible questions someone could have intended to ask, and answering them all preemptively. we’d rather ask for clarification.
if you want a conversation, it can’t be about the weather or about opinions. it has to have substance. once you’ve put some meat on the table, the weather discussion happens on its own.
as for the “arduino and raspi” bit… can you visualize me facepalming? arduinos don’t do video too well. sure, game of life on a dot matrix display, but not video. and raspis… hm well, moderately powerful CPU, and the GPU has been near unusable for a long time (thanks, drivers!). even today you can’t use OpenCL for any acceleration on that thing.
what I mean to say: “raspberry pi is slow” is obvious and allows no conclusion about OpenCV’s suitability for whatever you’re trying to do.
you hinted at “art installations”. OpenCV is for computer vision. it’s not OpenGL, it’s not made for drawing things. it’s not a GUI library either. it’s not a lot of things, but it comes with a bunch of rudimentary convenience facilities. nobody’s gonna stop you if you want to use OpenCV, for intended or unintended purposes.
but if you show up with criticism, expect to argue your own position before you ask anyone else to argue their position.
I better leave. Have a nice day.
I don’t want to drive you away. I am honestly interested in a discussion, if there’s something to discuss. I am sorry for the effect of these harsh words on you but I feel they needed to be said.
