1
1
Fork
You've already forked asmOpenCV
0

Why doesn't cvMatToQImage's CV_8UC4 case swap red and blue channels? #1

Closed
opened 2018年03月09日 03:35:54 +01:00 by asmaloney · 1 comment

(Yuriy asked this in the post on my site.)

(Yuriy asked this in [the post on my site](https://asmaloney.com/2013/11/code/converting-between-cvmat-and-qimage-or-qpixmap/#comment-4797).)
Author
Owner
Copy link

This has to do with endianness.

Although not totally clear from the docs, some of QImage's formats we use here are endian-dependent. So, for example:

Little Endian

  • QImage::Format_ARGB32 the bytes are ordered: B G R A
  • QImage::Format_RGB32 the bytes are ordered: B G R (255)
  • QImage::Format_RGB888 the bytes are ordered: R G B

Big Endian

  • QImage::Format_ARGB32 the bytes are ordered: A R G B
  • QImage::Format_RGB32 the bytes are ordered: (255) R G B
  • QImage::Format_RGB888 the bytes are ordered: R G B

Notice that Format_RGB888 is the same regardless of endianness. Since OpenCV expects (B G R) we need to swap the channels for this format.

This is why some conversions here swap the red and blue channels and others do not.

This code assumes little endian. It would be possible to add conversions for big endian machines though. If you are using such a machine, please feel free to submit a pull request here.

I'll add some comments to the header to make this clear.

This has to do with [endianness](https://en.wikipedia.org/wiki/Endianness). Although not totally clear from the docs, some of[ QImage](https://doc.qt.io/qt-5/qimage.html#Format-enum)'s formats we use here are endian-dependent. So, for example: **Little Endian** - QImage::Format_ARGB32 the bytes are ordered: **B G R A** - QImage::Format_RGB32 the bytes are ordered: **B G R (255)** - QImage::Format_RGB888 the bytes are ordered: **R G B** **Big Endian** - QImage::Format_ARGB32 the bytes are ordered: **A R G B** - QImage::Format_RGB32 the bytes are ordered: **(255) R G B** - QImage::Format_RGB888 the bytes are ordered: **R G B** Notice that _Format_RGB888_ is the same regardless of endianness. Since OpenCV expects (**B G R**) we need to swap the channels for this format. This is why some conversions here swap the red and blue channels and others do not. _This code assumes little endian._ It would be possible to add conversions for big endian machines though. If you are using such a machine, please feel free to submit a pull request here. I'll add some comments to the header to make this clear.
Sign in to join this conversation.
No Branch/Tag specified
master
No results found.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
asmaloney/asmOpenCV#1
Reference in a new issue
asmaloney/asmOpenCV
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?