swri-robotics / bag-database

A server that catalogs bag files and provides a web-based UI for accessing them.
Other
344 stars 71 forks source link

Adding support for BGRA8 encoding #141

Closed danthony06 closed 3 years ago

danthony06 commented 3 years ago

Adding support for BGRA8 images to address https://github.com/swri-robotics/bag-database/issues/139. @pjreed I'm not sure how to build or test the bag database, can you possibly look at this?

pjreed commented 3 years ago

I suspect that doing this will give you an image but that the red and blue channels will be swapped. You might need to manually swap those channels.

(I'm pretty swamped at the moment, but I can probably take a look at this and some of the other open issues this weekend)

danthony06 commented 3 years ago

You're right. I made a first cut at trying the channel swapping, using this: https://docs.opencv.org/master/javadoc/org/opencv/core/Core.html#mixChannels(java.util.List,java.util.List,org.opencv.core.MatOfInt)

pjreed commented 3 years ago

That almost works, I had to make a few other tweaks... but while testing it I realized that decoding rgba8 images is probably also broken right now due to a regression in Java's ImageIO between JVM versions 8 and 11. I'll see if I can fix that at the same time...

pjreed commented 3 years ago

This is almost working now, except the red and blue channels when playing back videos of CompressedImage topics still look reversed (see screenshot). I'm not actually sure what the best way to handle that would be... Screenshot from 2021-03-29 12-14-10

danthony06 commented 3 years ago

That's odd that it happens on compressed images. Is the decompression swapping channels already, and then we swap them back?

pjreed commented 3 years ago

There we go, I think this is working now.

For generating videos from uncompressed images, we don't have to manually swap the channels at all; ffmpeg supports bgr8 as an input format and we can send images directly it it. For compressed images, though, I think that when we use Java's ImageIO to decompress them, it's seeing the bgr byte order and swapping it to rgb under the hood, which means that when we tell ffmpeg that it's bgr, it swaps them back. I fixed that by watching for that situation and then manually switching the byte order we tell ffmpeg to rgb, and now it looks like everything's right.

phil333 commented 3 years ago

any update on this?

pjreed commented 3 years ago

I think this is all good now, I'll go ahead and merge it since there haven't been any other comments.