Page 1 of 2

support for raw 16-bit RGB565

Posted: 2019-05-22T10:30:58-07:00
by HoraK-FDF
Hi,

I've tried all day to get ImageMagick output a raw image in 16-bit RGB565 format at the end I surrendered and found that ffmpeg can do this but it would be awesome if ImageMagick can do this also. maybe a new format like rgb565:file.raw or a better -depth option like -depth 5,6,5 would be nice.

... greetings HoraK-FDF

Re: support for raw 16-bit RGB565

Posted: 2019-05-22T13:21:50-07:00
by fmw42
I do not know if this will help, but you can write that structure to BMP. See -define bmp:subtype at https://imagemagick.org/script/command- ... php#define

Re: support for raw 16-bit RGB565

Posted: 2019-05-22T13:53:12-07:00
by HoraK-FDF
Thanks for the reply I've tried this:

Code: Select all

magick convert -size 800x600+0 -define bmp:subtype=RGB565 rgb:"Loading Default.2rawdata" "Loading Default.bmp"
but I get an unexpected end of file error.

I think its in a wrong order or something is missing?

Re: support for raw 16-bit RGB565

Posted: 2019-05-22T16:13:16-07:00
by snibgo
What is the format of "Loading Default.2rawdata"? Perhaps it is 8 bits/channel/pixel, so you need "-depth 8" before reading it.

Re: support for raw 16-bit RGB565

Posted: 2019-05-23T12:45:58-07:00
by HoraK-FDF
It's 16bit rgb565, -depth 8 brings nothing because it takes 8 bits for every channel and that produces three small gray pictures horizontally and below them all black.

Re: support for raw 16-bit RGB565

Posted: 2019-05-25T13:06:31-07:00
by HoraK-FDF
as it seems it does not work can someone please implement it?

Re: support for raw 16-bit RGB565

Posted: 2019-05-25T13:20:53-07:00
by magick
Post a link to your Loading Default.2rawdata image file. We need to reproduce the problem before we can comment.

Re: support for raw 16-bit RGB565

Posted: 2019-06-02T16:55:45-07:00
by HoraK-FDF

Re: support for raw 16-bit RGB565

Posted: 2019-06-02T18:06:16-07:00
by magick
Assume 8-bits per pixel, so -depth 8 is required. Even so, with a width of 800 pixels (e.g. -size 800x600), thats 2400 bytes of RGB per scanline. With a file length of 960000, the pixels are consumed after 400 rows, although you are asking for 600-- thus an exception is thrown. How many rows and columns are expected on this image?

Re: support for raw 16-bit RGB565

Posted: 2019-06-03T06:39:07-07:00
by HoraK-FDF
800x600x(16bit/2byte)=960000bytes, the 16bit are in the format 5bit for red, 6bit for green and 5bit for blue (rgb565). So depth 8 will fail because it takes 8bit for red, 8bit for green and 8bit for blue. It seems that this picture is impossible to load with the current imagemagick only a better depth option or something like that can fix that. When it would be more variable tons of other raw data formats could be processed, here some examples what I mean:
-depth 5,6,5
-depth r5,g6,b5
-depth b5,g6,r5
-depth r5,g5,b5,a1
-depth r4,g4,b4,a4
-depth a4,r4,g4,b4

Re: support for raw 16-bit RGB565

Posted: 2019-06-03T07:53:56-07:00
by HoraK-FDF
or an enhancement for the rgb format like it is for bmp:
-define rgb:subtype=RGB565

Re: support for raw 16-bit RGB565

Posted: 2019-06-03T08:39:21-07:00
by snibgo
That file can be successfully read by IM, but the method is awkward.

Each pixel has 16 bits, arranged thus: RRRRRGGG GGGBBBBB. So we can read it as a 16-bit grayscale image, then clone for each channel, shuffling bits around, like this (Windows syntax, assuming IM is Q16):

Code: Select all

%IMG7%magick ^
  -size 800x600 -depth 16 ^
  "GRAY:Loading Default.2rawdata" ^
  ( -clone 0 -evaluate RightShift 11 -evaluate And 31 -evaluate LeftShift 11 ) ^
  ( -clone 0 -evaluate RightShift 5 -evaluate And 63 -evaluate LeftShift 10 ) ^
  ( -clone 0 -evaluate And 31 -evaluate LeftShift 11 ) ^
  -delete 0 ^
  -combine ^
  from_565_out.png
The evaluates can be simplified slightly.
Image

Re: support for raw 16-bit RGB565

Posted: 2019-06-03T11:36:34-07:00
by HoraK-FDF
snibgo wrote:
2019-06-03T08:39:21-07:00
That file can be successfully read by IM, but the method is awkward.

Each pixel has 16 bits, arranged thus: RRRRRGGG GGGBBBBB. So we can read it as a 16-bit grayscale image, then clone for each channel, shuffling bits around, like this (Windows syntax):

Code: Select all

%IMG7%magick ^
  -size 800x600 -depth 16 ^
  "GRAY:Loading Default.2rawdata" ^
  ( -clone 0 -evaluate RightShift 11 -evaluate And 31 -evaluate LeftShift 11 ) ^
  ( -clone 0 -evaluate RightShift 5 -evaluate And 63 -evaluate LeftShift 10 ) ^
  ( -clone 0 -evaluate And 31 -evaluate LeftShift 11 ) ^
  -delete 0 ^
  -combine ^
  from_565_out.png
The evaluates can be simplified slightly.
Thanks that's nice that really helped a lot!

Is this also possible to do this with -fx or -format "%fx.."?

Does that "-evaluate And" mean that ImageMagick internally does rotating instead of shifting? Because everywhere I shifted in assembler or so zeros came in.

I have another question the Loading Default.2rawdata comes from a file that has a 36byte header followed by the picture (800x600x2bytes) and another 2400 bytes after the picture but when I try the above on the source file with:
-size 800x600+36 I get an unexpected end of file error
if I use:
-size 800x600+2436 it does it without complaining but the picture is wrong because the starting offset was wrong
Is this a bug in ImageMagick or must I specify something else?

Re: support for raw 16-bit RGB565

Posted: 2019-06-03T12:25:27-07:00
by snibgo
Yes it could be done with "-fx", but that would be much slower. The 8 evaluates can simplify to 5.

"-evaluate And" sets each bit in the output only where the both input bits are "1". 31 is binary 0001 1111, so "-evaluate And 31" sets all bits to 0 except for the bottom 5 bits.

Can you link to your 36+picture+2400 file?

IM has no mechanism to ignore the first or last N bytes in a raw file. Doubtless some Unix filter can do that; possibly "head" and "tail".

Re: support for raw 16-bit RGB565

Posted: 2019-06-03T13:37:17-07:00
by HoraK-FDF
yes that with the And is clear but when shifted on all other languages I know on one side zeroes come in an this would make the And unnecessary so does ImageMagick rotate interanlly meaning the bits leaving on one side come in on the other?

I saw other that said that -size XxY+offset (offset is bytes) works, I also just tested it myself I stripped the tailing 2400bytes and -size 800x600+36 works

here is the link to the file: http://horak-fdf.myartsonline.com/Loadi ... ault.frm16