Hello. We have a camera that grabs data as color separated jpeg images. Therefor for each color I have a grayscale jpeg file. I’ve been trying to get the jpeg_decode working on the Xavier. The provided NvJpegDecode failed to decode the images with both options (–decode-fd and --decode-buffer). I have applied one of the patches found on the forum https://devtalk.nvidia.com/default/topic/1043325/jetson-tx2/nvjpeg-die-on-decoding-picture/ and I can now decdoe to buffer.
jpeg_decode num_files 1 ./1.jpg ./1.raw --decode-buffer
Image Resolution - 1232 x 1024
App run was successful
However the option --decode-fd still does not work.
jpeg_decode num_files 1 ./1.jpg ./1.raw --decode-fd
Failed to query video capabilities: Inappropriate ioctl for device
Unsupported color conversion request
I would like to have both options working, especially since decode to fd is supposed to be faster. Any help in getting it working is highly appreciated.
Is there any way to get this working? I need to decode 24 of these jpegs at 30 fps ? The best I can obtain now is 100 fps per image ( ~4 fps for all) using decode-buffer.
Thanks for the information. I am not sure whether it will help. My camera is an USB camera, but the data format is proprietary. The 24 jpgs are all a subpart of the buffer.
For completeness I have attached one of the jpg files. I hope that GRAY jpegs will be fully supported in the next release(s).
I’m on r34.5 and I ran in an issue with a grayscale JPEG. It would load, but block for a while and come out reddish with the buffers not adjusted in RGB (two rectangles at the top, probably Y on one side and UV on the other—this looked like an internal buffer format).
I added some red to the image, saved it back, tried to load with the JPEG HW and now it works.
Note that the image here is said to be 1232 in width which is a multiple of 16 (× 77) so that shouldn’t have been the issue. Pure grayscale JPEGs only have the Y component (luminance) and it looks like it’s not supported.
How could that not still be an issue if the hardware is the same?! It doesn’t support 4:4:4, that’s it. Only I think that the library should react with an error such as “unsupported format” rather than try to load the image anyway and fail dramatically. But you probably already know that.
Now that I make sure to use 4:2:0 images, it works like a charm.