jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20695
Joined: Sat Jul 30, 2011 7:41 pm

Re: Annotate, any hope for future changes?

Fri Feb 13, 2015 9:29 am

towolf wrote:If I remove --irefresh I get 5-6 frames of latency on the network stream. I thought the effect would be opposite?
Intrarefresh options smooth out the bandwidth as the I-frames are spread over a larger number of frames, so you don't get the bump of a complete I-frame spread amongst the P-frames. I'd not expect much latency improvement. There's also a slight decrease in quality at the same bitrate.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Fri Feb 13, 2015 11:11 am

I know the options are there for intra-refresh, but do they actually do something? I haven't checked the code, but I thought there were a fair few limitations within the hardware - happy to be wrong!
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20695
Joined: Sat Jul 30, 2011 7:41 pm

Re: Annotate, any hope for future changes?

Fri Feb 13, 2015 11:49 am

cyclicrows certainly does something, don't know about the others.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

rahlquist
Posts: 149
Joined: Tue Jan 21, 2014 1:02 pm

Re: Annotate, any hope for future changes?

Fri Feb 13, 2015 7:13 pm

6by9 wrote: Whole image shifting is odd. What resolutions are you running at? I'll have a go at recreating as there should be no shift at all.
Did a bit more testing. It only happens when the image is rotated 90 or 270 deg. 0 or 180 do not do this.

As for resolution, from my raspimjpeg config file.

Code: Select all

# fps_preview = video_fps (below) / divider
#
width 512
quality 25
divider 1

#
# Video Options
#
video_width 1920
video_height 1080

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Fri Feb 13, 2015 8:40 pm

rahlquist wrote:Did a bit more testing. It only happens when the image is rotated 90 or 270 deg. 0 or 180 do not do this.
Transpose - bum! The configuration changes significantly when we add transpose into the mix, and I'm afraid it's not something I'm going to play with as the permutations are vast.
rahlquist wrote:As for resolution, from my raspimjpeg config file.
1920x1080. Throwing transpose into the mix isn't going to be that great a prospect then, as the sensor is only producing 1920x1080, so to rotate 90 or 270 it'll be cropped to 607x1080 and then upscaled to 1920x1080. That 607(.5) may be the culprit - odd numbers are always troublesome, particularly with chroma subsampling and the like.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

rahlquist
Posts: 149
Joined: Tue Jan 21, 2014 1:02 pm

Re: Annotate, any hope for future changes?

Fri Feb 13, 2015 9:34 pm

6by9 wrote: Transpose - bum! The configuration changes significantly when we add transpose into the mix, and I'm afraid it's not something I'm going to play with as the permutations are vast.
And that explains it all. I just need to make sure I get my pi camera facing the right direction (so few camera case options).

Thanks!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Sat Feb 21, 2015 3:24 pm

Changes are mainly working. New config structure is currently

Code: Select all

#define MMAL_CAMERA_ANNOTATE_MAX_TEXT_LEN_V3 256
typedef struct MMAL_PARAMETER_CAMERA_ANNOTATE_V3_T
{
   MMAL_PARAMETER_HEADER_T hdr;

   MMAL_BOOL_T enable;
   MMAL_BOOL_T show_shutter;
   MMAL_BOOL_T show_analog_gain;
   MMAL_BOOL_T show_lens;
   MMAL_BOOL_T show_caf;
   MMAL_BOOL_T show_motion;
   MMAL_BOOL_T show_frame_num;
   MMAL_BOOL_T enable_text_background;
   MMAL_BOOL_T custom_background_colour;
   uint8_t     custom_background_Y;
   uint8_t     custom_background_U;
   uint8_t     custom_background_V;
   uint8_t     dummy1;
   MMAL_BOOL_T custom_text_colour;
   uint8_t     custom_text_Y;
   uint8_t     custom_text_U;
   uint8_t     custom_text_V;
   uint8_t     text_size;
   char text[MMAL_CAMERA_ANNOTATE_MAX_TEXT_LEN_V3];
} MMAL_PARAMETER_CAMERA_ANNOTATE_V3_T;
Custom background colour and text size are both doing the right thing. I've even done raspicam changes to test it out - those'll get pushed to my github later, along with a test firmware.
I haven't plumbed in custom text colour as only Y appears to be used - I'll probably still do the plumbing as you could then at least alter the Y for dimmer text overlay. Doing U&V will be more awkward due to the chroma subsampling.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

rahlquist
Posts: 149
Joined: Tue Jan 21, 2014 1:02 pm

Re: Annotate, any hope for future changes?

Sun Feb 22, 2015 6:02 pm

6by9 wrote: Custom background colour and text size are both doing the right thing. I've even done raspicam changes to test it out - those'll get pushed to my github later, along with a test firmware.
I haven't plumbed in custom text colour as only Y appears to be used - I'll probably still do the plumbing as you could then at least alter the Y for dimmer text overlay. Doing U&V will be more awkward due to the chroma subsampling.
Ok bear with me 6by9 as video is not my strong suit. So by what I am reading, it sounds as if the background may accept YUV changes but the text appears to only accept Y? If thats the case, would it be possible to implement a way to invert the whole lot? i.e. white background and black text?

Thanks for the work you are putting in.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Sun Feb 22, 2015 8:22 pm

rahlquist wrote:Ok bear with me 6by9 as video is not my strong suit. So by what I am reading, it sounds as if the background may accept YUV changes but the text appears to only accept Y? If thats the case, would it be possible to implement a way to invert the whole lot? i.e. white background and black text?
Black: Y=0, U=0x80, V=0x80
White: Y=0xFF, U=0x80, V=0x80
So yes, a background of 0x8080FF and text colour of 0x00 should give you black text on a white background (though I haven't tried it as yet)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Mon Feb 23, 2015 9:23 am

OK, Userland updated at https://github.com/6by9/userland/tree/master to include setting text size, colour, and background colour.
One extra parameter "-ae" or "--annotateex" that takes "<textsize>,<text_col>,<bg_col>"
eg " ./build/bin/raspivid -w 1920 -h 1080 -ae 32,0xff,0x808000 -a "Wibble gibber gibber" -a 1025" has been one of my test commands for black background with white text and size 32.
I've just tried it, and -ae 32,0x00,0x8080FF does give black text on a white background.
Size goes from 6 to 160, default is 32. Asking for an invalid size should give you the default.

For the time being you'll need a test firmware until I've sent the patches to Dom and he's released them. Firmware will be at https://github.com/6by9/RPiTest/tree/master/annotate once I've built and pushed it (about 15mins I'd guess).

Jamesh: I haven't looked yet at your query (down the pub) over whether inserting a carriage return in the text will actually throw a line for you, but there's nothing stopping you just trying it. I'll try to have a look tonight.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20695
Joined: Sat Jul 30, 2011 7:41 pm

Re: Annotate, any hope for future changes?

Mon Feb 23, 2015 9:29 am

6by9 wrote:OK, Userland updated at https://github.com/6by9/userland/tree/master to include setting text size, colour, and background colour.
One extra parameter "-ae" or "--annotateex" that takes "<textsize>,<text_col>,<bg_col>"
eg " ./build/bin/raspivid -w 1920 -h 1080 -ae 32,0xff,0x808000 -a "Wibble gibber gibber" -a 1025" has been one of my test commands for black background with white text and size 32.
I've just tried it, and -ae 32,0x00,0x8080FF does give black text on a white background.
Size goes from 6 to 160, default is 32. Asking for an invalid size should give you the default.

For the time being you'll need a test firmware until I've sent the patches to Dom and he's released them. Firmware will be at https://github.com/6by9/RPiTest/tree/master/annotate once I've built and pushed it (about 15mins I'd guess).

Jamesh: I haven't looked yet at your query (down the pub) over whether inserting a carriage return in the text will actually throw a line for you, but there's nothing stopping you just trying it. I'll try to have a look tonight.
Cool. Ta! If I have time today will give it a go.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Mon Feb 23, 2015 10:03 am

Firmware pushed.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Mon Feb 23, 2015 10:34 am

Just checked the firmware as I realised where the calc had to be. Nice comment on the appropriate function:

Code: Select all

 * Split the supplied text over the number of lines necessary to
 * fit them on the image. Does not attempt to split at word boundaries.
So no, it doesn't have any way of handling carriage return or other control char to break lines, but it would be easy to add. Care to nominate a suitable char? 0x13 isn't the best as it is tricky to add on a command line.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 540
Joined: Wed Oct 02, 2013 12:28 pm

Re: Annotate, any hope for future changes?

Mon Feb 23, 2015 10:44 am

I vote for "\n" in the string(like "echo -e" and others use...). You can replace it, with some special character while passing the argument to the annotate function.
Last edited by ethanol100 on Tue Feb 24, 2015 10:05 am, edited 2 times in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Mon Feb 23, 2015 11:52 am

ethanol100 wrote:I vote for "\n" in the string(like "echo -e" and others use...). You can replace it, with some special character while passing the argument to the annotate function.
That sounds like someone volunteering to write the userland code to do it :D
Currently it just does a strncpy from args to the structure. Shouldn't be too tricky to do it char by char using lines 199-250 of http://git.savannah.gnu.org/cgit/coreut ... src/echo.c to do the conversion. I'll be looking at the firmware side though rather than userland.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 540
Joined: Wed Oct 02, 2013 12:28 pm

Re: Annotate, any hope for future changes?

Tue Feb 24, 2015 10:01 am

6by9 wrote: That sounds like someone volunteering to write the userland code to do it :D
Currently it just does a strncpy from args to the structure. Shouldn't be too tricky to do it char by char using lines 199-250 of http://git.savannah.gnu.org/cgit/coreut ... src/echo.c to do the conversion. I'll be looking at the firmware side though rather than userland.
Sure, based on these lines it is easy... https://github.com/ethanol100/userland/ ... otatedText
Now I hope to get line breaks with "Line feed" (0x0A, 10 in decimal) from the firmware ;)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Tue Feb 24, 2015 10:21 am

ethanol100 wrote:Sure, based on these lines it is easy... https://github.com/ethanol100/userland/ ... otatedText
Now I hope to get line breaks with "Line feed" (0x0A, 10 in decimal) from the firmware ;)
Touche! :D
I didn't get a chance last night as I got distracted by Openelec. I still haven't passed my other patches to Dom, so I will make the effort tonight to get both bits done.

I don't quite agree with your second patch.
if(strlen(arg2) < MMAL_CAMERA_ANNOTATE_MAX_TEXT_LEN_V2)
means that the escaped text has to be less than max_text_len, which means you lose 1 char for each escape you add. Not a big deal, but an observation.
I'll also check tonight to see how complete the character set is - there may be merit in extending the escape sequences that are supported if accented chars are available.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 540
Joined: Wed Oct 02, 2013 12:28 pm

Re: Annotate, any hope for future changes?

Tue Feb 24, 2015 11:04 am

6by9 wrote: I don't quite agree with your second patch.
if(strlen(arg2) < MMAL_CAMERA_ANNOTATE_MAX_TEXT_LEN_V2)
means that the escaped text has to be less than max_text_len, which means you lose 1 char for each escape you add. Not a big deal, but an observation.
Ok, you are right, changed my second commit... Now it will just copy until the annotation string is full.
I'll also check tonight to see how complete the character set is - there may be merit in extending the escape sequences that are supported if accented chars are available.
That would be nice. It will be easy to add some cases, if you can supply a list of supported characters.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Tue Feb 24, 2015 11:58 am

ethanol100 wrote:
I'll also check tonight to see how complete the character set is - there may be merit in extending the escape sequences that are supported if accented chars are available.
That would be nice. It will be easy to add some cases, if you can supply a list of supported characters.
I was thinking the \xFF or \077 formats for hex/octal input of any old control code, just as long as the firmware code does something sensible on an unsupported char. I'm not going to do tabs, bell, backspace, form feed, or any of the other control codes that are are \<char>
I'll see what I find tonight anyway.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 540
Joined: Wed Oct 02, 2013 12:28 pm

Re: Annotate, any hope for future changes?

Tue Feb 24, 2015 6:04 pm

6by9 wrote: I was thinking the \xFF or \077 formats for hex/octal input of any old control code, just as long as the firmware code does something sensible on an unsupported char. I'm not going to do tabs, bell, backspace, form feed, or any of the other control codes that are are \<char>
I'll see what I find tonight anyway.
OK, does the firmware right now filter unsupported chars? I just tried typing ö,ä,ü (german keyboard layout...) and they give "?". Only Ascii 32 to 126 (in dec) are displaying real characters all other result in "?". All these characters can be typed with the keyboard and I'm just wondering if adding \xXX and \0XX is needed.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Tue Feb 24, 2015 6:25 pm

ethanol100 wrote:OK, does the firmware right now filter unsupported chars? I just tried typing ö,ä,ü (german keyboard layout...) and they give "?". Only Ascii 32 to 126 (in dec) are displaying real characters all other result in "?". All these characters can be typed with the keyboard and I'm just wondering if adding \xXX and \0XX is needed.
Hence why I said I'd need to check the source to know for certain :)

Just found a nice comment in the source:
Only supports ASCII characters in the range 32 to 126.
So your empirical testing seems to have come up with the right answer anyway! No point in adding \xXX or\0XX.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Tue Feb 24, 2015 11:36 pm

Shiny goodness for people.
https://github.com/6by9/userland/# has merged both my changes and ethanol100's unescaping \n (had to recreate the patch to switch to the V3 structure, so you've lost the credit - sorry).
I've update the start_x.elf in https://github.com/6by9/RPiTest/tree/master/annotate to include handling carriage return. I even thought about the case where line 1 needed to wrap, but you'd added a CR in line 2 (too many edge cases!)

I'd appreciate it if those who expressed an interest in these features could give it a quick bash, but I will get the patch ready to send to Dom later tomorrow and doing a PR for the userland changes.

Adding ! to the string is a little tricky at the moment, so it might still be worth adding handling for \xXX. It's too late to think about that now though.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 540
Joined: Wed Oct 02, 2013 12:28 pm

Re: Annotate, any hope for future changes?

Wed Feb 25, 2015 11:22 am

6by9 wrote:Shiny goodness for people.
https://github.com/6by9/userland/# has merged both my changes and ethanol100's unescaping \n (had to recreate the patch to switch to the V3 structure, so you've lost the credit - sorry).
I've update the start_x.elf in https://github.com/6by9/RPiTest/tree/master/annotate to include handling carriage return. I even thought about the case where line 1 needed to wrap, but you'd added a CR in line 2 (too many edge cases!)
Works nicely! You can even use it with "-a 13". I.e., raspistill -a "Somewhere\n" -a 13. We are limited to 4 lines(3x'\n')?
I'd appreciate it if those who expressed an interest in these features could give it a quick bash, but I will get the patch ready to send to Dom later tomorrow and doing a PR for the userland changes.
I have not expressed my interest, but some remarks to to the annotate function...
  • The test if the -a "string" is a number does not work as expected, i.e. if I want to write -a "1. Camera" will not display anything.
  • The "Annotate bitmask" needs some documentation, at the moment I guess you would need to look into the source to find its definition. I think many new user will have some problems.
  • Setting colours as 0xVUY in hex is quite difficult. And got me really confused and you could mention in the help text, that you need to put the number in the format 0xFFEEDD. Not everyone knows how to write hex.
But everything seems to work as expected. Sometimes a border has not the right Y value( due to chroma sub-sampling?).

To calculate VUY values from RGB I have written a small script "RGB2VUY.sh":

Code: Select all

#!/bin/bash
unset LANG
awk -v R=$1 -v G=$2 -v B=$3 'BEGIN{
Y=0.299*R+0.587*G+0.114*B;
U=-0.168736*R-0.331264*G+0.5*B+128;
V=0.5*R-0.418688*G-0.0.81312*B+128;
if(Y<0)Y=0;
if(Y>255)Y=255;
if(U<0)U=0;
if(U>255)U=255;
if(V<0)V=0;
if(V>255)V=255;
printf("0x%02x%02x%02x",V,U,Y)
}'
with it I can test RGB colours("./bin/raspistill -t 0 -a 'Hello\nWorld' -ae 32,0xff,$(./RGB2YUV.sh 0 255 255) -a 1025").
Adding ! to the string is a little tricky at the moment, so it might still be worth adding handling for \xXX. It's too late to think about that now though.
I'm not exactly sure, what you mean by a little tricky. Do you mean the replacement by bash? We can put the string in single quotes '!Help!' should work without interfering with bash, like one usual do for "$" or "\\".

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5798
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Annotate, any hope for future changes?

Wed Feb 25, 2015 11:38 am

ethanol100 wrote:Works nicely! You can even use it with "-a 13". I.e., raspistill -a "Somewhere\n" -a 13. We are limited to 4 lines(3x'\n')?
Yes, max 4 lines. If you do much more then you're obliterating half your image.
ethanol100 wrote:
  • The test if the -a "string" is a number does not work as expected, i.e. if I want to write -a "1. Camera" will not display anything.
  • The "Annotate bitmask" needs some documentation, at the moment I guess you would need to look into the source to find its definition. I think many new user will have some problems.
  • Setting colours as 0xVUY in hex is quite difficult. And got me really confused and you could mention in the help text, that you need to put the number in the format 0xFFEEDD. Not everyone knows how to write hex.
But everything seems to work as expected. Sometimes a border has not the right Y value( due to chroma sub-sampling?).
1 - blame Jamesh as he wrote that code :) You're right though that it isn't the best. Probably better to separate it into 2 parameters.
2 - again, Jamesh's handiwork.
3 - As they underlying layers are using YUV, I don't want to change the MMAL API to have to do the conversion. It could be added into userland fairly easily if someone had the desire (I don't!)
4 - the background border? It should be uniform, but you do get some weird anomalies sometimes. There are options for where the chroma should be located within the 4 pixels that it is subsampled to. Most assume central, but you can have a number of locations which should all do subtly different things. I will have a quick look to make sure I'm not starting the background box on an odd pixel, as that certainly is a bad idea with subsampling.
To calculate VUY values from RGB I have written a small script "RGB2VUY.sh":
<snip>
Cool, and thank you again.
6by9 wrote:Adding ! to the string is a little tricky at the moment, so it might still be worth adding handling for \xXX. It's too late to think about that now though.
I'm not exactly sure, what you mean by a little tricky. Do you mean the replacement by bash? We can put the string in single quotes '!Help!' should work without interfering with bash, like one usual do for "$" or "\\".
I'd tried -a "Wibble!\nGibber" and got an error from bash of mismatched something or other. Doing -a "Wibble\!\nGibber" inserts both characters into the final string.
Also trying to insert a double quote becomes entertaining and needs escaping so bash does the right thing.
We could go on forever, but it probably isn't worth the effort, and I'm not a bash expert for escape sequences. Having to insert escape sequences in the first place is beyond many users.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 540
Joined: Wed Oct 02, 2013 12:28 pm

Re: Annotate, any hope for future changes?

Wed Feb 25, 2015 2:37 pm

6by9 wrote: Yes, max 4 lines. If you do much more then you're obliterating half your image.
not with font size 6 :)
But four lines and 256 characters are fine.
1 - blame Jamesh as he wrote that code :) You're right though that it isn't the best. Probably better to separate it into 2 parameters.
2 - again, Jamesh's handiwork.
I know, but it was the first time I tried the new annotation and just noticed these points.
3 - As they underlying layers are using YUV, I don't want to change the MMAL API to have to do the conversion. It could be added into userland fairly easily if someone had the desire (I don't!)
4 - the background border? It should be uniform, but you do get some weird anomalies sometimes. There are options for where the chroma should be located within the 4 pixels that it is subsampled to. Most assume central, but you can have a number of locations which should all do subtly different things. I will have a quick look to make sure I'm not starting the background box on an odd pixel, as that certainly is a bad idea with subsampling.
Everything is YUV...
And we can't do yellow background with white fonts or black fonts on blue "YUV 0,255,0". I will never get a feeling of colours in YUV space...(Why is the intensity zero for a bright color?! (RGB=0,47,225))

And one example of the subsampling:
Annotation.jpg
Annotation.jpg (40.8 KiB) Viewed 2415 times
The end of the first line has a darker blue line, the second one a almost white line. But it is really not important.
I'd tried -a "Wibble!\nGibber" and got an error from bash of mismatched something or other. Doing -a "Wibble\!\nGibber" inserts both characters into the final string.
Also trying to insert a double quote becomes entertaining and needs escaping so bash does the right thing.
We could go on forever, but it probably isn't worth the effort, and I'm not a bash expert for escape sequences. Having to insert escape sequences in the first place is beyond many users.
Ok, if we do not want any replacement from bash -a 'text with "" and !\' will work fine, only if we have some variables we want to place in it like "Place: $home" we need to use double quotes. It is really not worth the effort.

Return to “Camera board”