High speed (burst) shooting with EDSDK - edsdk

I'm trying to do high speed shooting with the EOS 40D. When hand-operated with drive mode set to "high speed continuous" in the UI, this camera sustains about 6 fps.
How can I replicate this using the EDSDK?
The code below selects "high speed continuous" drive mode (0x4) and sends kEdsCameraCommand_TakePicture as fast as possible. After each shot the camera remains "busy" for around 1 second. This is the same speed as single-frame shooting. I tested every available drive mode and while some are slower, none are faster than 1 fps.
Note that the EOS 40D does not support kEdsCameraCommand_PressShutterButton. Using it gives EDS_ERR_INVALID_PARAMETER. The EDSDK document says: "This command is supported by the EOS 50D or EOS 5D Mark II or later cameras" so 40D is too old.
printf("============= Testing drive mode %08X\n", drive_mode);
result = EdsSetPropertyData(m_CameraRef, kEdsPropID_DriveMode, 0, sizeof(EdsUInt32), &drive_mode);
assert(result == EDS_ERR_OK);
EdsUInt32 new_drive_mode;
result = EdsGetPropertyData(m_CameraRef, kEdsPropID_DriveMode, 0, sizeof(EdsUInt32), &new_drive_mode);
assert(result == EDS_ERR_OK);
assert(new_drive_mode == drive_mode);
int n_captured = 0;
for (int i = 0; i < count; i++)
{
do
{
result = EdsSendCommand(m_CameraRef, kEdsCameraCommand_TakePicture, 3);
printf(" %d", result);
Wait(1); // Process Windows messages for a few ms
} while (result == EDS_ERR_DEVICE_BUSY);
printf("\n");
if (result == EDS_ERR_OK)
n_captured++;
else
printf(" Burst capture error code for frame %d: %d!\n", i, result);
}
printf(" Burst capture end!\n");
Typical output looks like:
============= Testing drive mode 00000004
0
129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129
129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129
129 129 129 129 129 129 129 129 129 129 0
129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129
129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129
129 129 129 129 129 129 129 129 129 129 129 0
Burst capture end!
Code 129 is EDS_ERR_DEVICE_BUSY.

It's not possible with a 40D because, as you already noted, the PressShutterButton command is not supported.
You may be able to speed it up a little bit with the TakePicture command by setting SaveTo to Host and take a photo as soon as you get the DownloadReady object event.
You need to save the pointers from that event and when you are done, download all images.
Beware that the buffer size is limited though and depending on image quality (jpg/raw, large/small size) may only fit three or four images.
Alternatively, use a faster CF card so when you save the images on the camera, it's ready again sooner.

Related

When I import a PDF file inside Overleaf the math mode characters turns "bold" (shadow)

I used the website diagrams.net to create a figure with some mathematical expressions. Of course, I can export it how PNG and import it to my Overleaf, but I want to retain the vectorization of the expressions. Because of that, I am trying to import it how PDF inside my Overleaf document.
When I use:
\begin{figure}[tbp!]
\centering
\includegraphics[width=\linewidth]{images/math_structure.pdf}
\caption{My figure description.}
\label{fig:math_structure}
\end{figure}
My figure is shown normally, aparently, but when I zoom in the mathematical expressions I have it:
Another interesting thing I noted is that when I download the PDF from Overleaf and open it using MUPDF the "bold" disappears, but when I open it using Google Chrome or Firefox the "bold" is there yet.
This is a pretty strange thing because I guess it was a problem of embedding font inside the PDF, but my file opens normally in MUPDF. Does anyone know what is happening and how can I resolve it?
I am sharing the math_structure in order to reproduce the problem in the following link: PDF
As an addendum to K J's answer:
looking at each letter there are two objects so although I can not see the shadow within the editor but accept it is there so it must be placed by the text outline generator? here I have moved and coloured some glyphs so the second edge is deliberate but most viewers would not show them as a "GLOW"
Indeed, all those items with a glow are drawn twice in the content stream, once for filling the defining path, once for stroking. E.g. the capital S of "State":
.111484379 0 0 -.111468516 140.764496 314.20746 cm
/G3 gs
55 507 m
55 562.33331 74 609 112 647 c
150 685 193.66666 704 243 704 c
257 704 l
313.66666 704 363 683 405 641 c
426 672 l
429.33334 676.66669 432.66666 681.66669 436 687 c
439.33334 692.33331 442.66666 696.66669 446 700 c
449 704 l
449.66666 704 451 704 453 704 c
455 704 457 704.33331 459 705 c
463 705 l
465 705 468 703 472 699 c
472 462 l
466 456 l
448 456 l
440.66666 456 436.33334 457 435 459 c
433.66666 461 432 467.66666 430 479 c
418.66666 563 385 618.66669 329 646 c
304.33334 656.66669 279.33334 662 254 662 c
218.66666 662 190 650 168 626 c
146 602 135 574 135 542 c
135 519.33331 140.666672 498.66666 152 480 c
163.333328 461.33334 179.33333 446.33334 200 435 c
206.66667 432.33334 235.33333 424.66666 286 412 c
336.66666 399.33334 364.66666 391.66666 370 389 c
408 374.33334 439 349.33334 463 314 c
487 278.66666 499.33334 237.66667 500 191 c
500 137 482.66666 88.333336 448 45 c
413.33334 1.66666412 364.33334 -20.333334 301 -21 c
263.66666 -21 230.33333 -15.333334 201 -4 c
171.66667 7.333334 151.333328 17.666666 140 27 c
122 41 l
119.333336 37.666668 114.333336 31 107 21 c
99.666664 11 93 1.66666698 87 -7 c
81 -15.666667 78 -20.333334 78 -21 c
76.666664 -21.666666 73.333336 -22 68 -22 c
64 -22 l
62 -22 59 -20 55 -16 c
55 101 l
55 180.33334 55.333332 220.66667 56 222 c
57.333332 225.33333 64 227 76 227 c
89 227 l
93 223 95 218.66667 95 214 c
95 192.66667 98.333336 171.66667 105 151 c
111.666664 130.333328 123 110 139 90 c
155 70 177 54 205 42 c
233 30 266.33334 24 305 24 c
336.33334 24 363.33334 36.666664 386 62 c
408.66666 87.333336 420 118.333328 420 155 c
420 183.66667 412.66666 209.66667 398 233 c
383.33334 256.33334 364 272.33334 340 281 c
302.66666 290.33334 278 296.66666 266 300 c
262.66666 300.66666 253.66667 302.66666 239 306 c
224.33333 309.33334 213.33333 312 206 314 c
198.66667 316 188 319.66666 174 325 c
160 330.33334 149 336.33334 141 343 c
133 349.66666 123.333336 357.66666 112 367 c
100.666664 376.33334 91.666664 388 85 402 c
65 434.66666 55 469.66666 55 507 c
h
f
/G7 gs
55 507 m
55 562.33331 74 609 112 647 c
150 685 193.66666 704 243 704 c
257 704 l
313.66666 704 363 683 405 641 c
426 672 l
429.33334 676.66669 432.66666 681.66669 436 687 c
439.33334 692.33331 442.66666 696.66669 446 700 c
449 704 l
449.66666 704 451 704 453 704 c
455 704 457 704.33331 459 705 c
463 705 l
465 705 468 703 472 699 c
472 462 l
466 456 l
448 456 l
440.66666 456 436.33334 457 435 459 c
433.66666 461 432 467.66666 430 479 c
418.66666 563 385 618.66669 329 646 c
304.33334 656.66669 279.33334 662 254 662 c
218.66666 662 190 650 168 626 c
146 602 135 574 135 542 c
135 519.33331 140.666672 498.66666 152 480 c
163.333328 461.33334 179.33333 446.33334 200 435 c
206.66667 432.33334 235.33333 424.66666 286 412 c
336.66666 399.33334 364.66666 391.66666 370 389 c
408 374.33334 439 349.33334 463 314 c
487 278.66666 499.33334 237.66667 500 191 c
500 137 482.66666 88.333336 448 45 c
413.33334 1.66666412 364.33334 -20.333334 301 -21 c
263.66666 -21 230.33333 -15.333334 201 -4 c
171.66667 7.333334 151.333328 17.666666 140 27 c
122 41 l
119.333336 37.666668 114.333336 31 107 21 c
99.666664 11 93 1.66666698 87 -7 c
81 -15.666667 78 -20.333334 78 -21 c
76.666664 -21.666666 73.333336 -22 68 -22 c
64 -22 l
62 -22 59 -20 55 -16 c
55 101 l
55 180.33334 55.333332 220.66667 56 222 c
57.333332 225.33333 64 227 76 227 c
89 227 l
93 223 95 218.66667 95 214 c
95 192.66667 98.333336 171.66667 105 151 c
111.666664 130.333328 123 110 139 90 c
155 70 177 54 205 42 c
233 30 266.33334 24 305 24 c
336.33334 24 363.33334 36.666664 386 62 c
408.66666 87.333336 420 118.333328 420 155 c
420 183.66667 412.66666 209.66667 398 233 c
383.33334 256.33334 364 272.33334 340 281 c
302.66666 290.33334 278 296.66666 266 300 c
262.66666 300.66666 253.66667 302.66666 239 306 c
224.33333 309.33334 213.33333 312 206 314 c
198.66667 316 188 319.66666 174 325 c
160 330.33334 149 336.33334 141 343 c
133 349.66666 123.333336 357.66666 112 367 c
100.666664 376.33334 91.666664 388 85 402 c
65 434.66666 55 469.66666 55 507 c
h
S
The filled version is drawn with the extended graphics state G3, the stroked version is drawn with the extended graphics state G7.
G3 fills in an opaque manner:
<</BM/Normal/ca 1>
but G7 strokes very transparently (opacity .1098) and sets some other parameters:
<</BM/Normal/CA .1098/LC 0/LJ 0/LW 0/ML 4/SA true/ca .1098>>
But in particular G7 also sets the line width to 0 (the thinnest line that can be rendered at device resolution: 1 device pixel wide).
The OP mentions that they see the shadows when they zoom in. Thus, maybe those viewers in which you see a broad shadow/glow after zooming do simply zoom by drawing everything magnified by the zoom factor, i.e. the shadow/glow becomes zoom factor * 1 pixel wide; and those viewers in which you don't see a broad shadow/glow draw the outlines even after zooming with a 1 pixel width.
It does not appear to be the difference is in the font style since the weighting between standard 24 and bold 24 is shown below on the right. Which is not evident in your two samples.
However, what is noticeable in your sample is the "shadows" around each of those letter on the left giving the impression of extra thickness.
Initially I would expect that could be caused by the difference between jpeg (haloed lettering) and png (crisp anti-alias outlines). But then the shadow is too regular i.e. not uneven like it would normally be in a jpeg.
At this stage it looks like there may be some other reason for such fuzzy fonts.
Without a sample I would have to guess the PDF has potentially a font with an alpha component but could be way off in such a wild assumption.
Later Edit
Thanks for your link but the mystery deepens, since that linked PDF in Chromium Edge even enlarged shows no evidence of any shadows, but then again the maths looks like vector outlines only the middle Tahoma appears to be font and the one embedded, as generated by Skia/PDF thus built by chrome?.
I have to agree there is some other influence somewhere down the line but the browser should not affect the PDF unless it adds or respects some overlay based on an extra component, and looking at each letter there are two objects so although I can not see the shadow within the editor but accept it is there so it must be placed by the text outline generator?
here I have moved and coloured some glyphs so the second edge is deliberate but most viewers would not show them as a "GLOW"
You mentioned "diagrams.net" which does have many shadow options but I never experienced any other than deliberately set to right and down. Perhaps look for a rogue setting there.
In summary the file is declared as compatible with version 1.4 (may have transparency) and clearly some transparent objects have been included around each letter! but not in a fashion expected by all viewers. As a result of #mkl 's observation I retested the pdf in many viewers with the settings that could have an effect such as vector line thickening in acrobat, However NONE I tested showed the extra thick outlines, thus the PDF seems valid but some PDF viewer(apps) methods you are using seem to thicken the anti-alias much more than should be expected for a single pixel boundary.

To find avg in pig and sort it in ascending order

have a schema with 9 fields and i want to take only two fields(6,7 i.e $5,$6) and i want to calculate the average of $5 and i want to sort the $6 in ascending order so how to do this task can some one help me.
Input Data:
N368SW 188 170 175 17 -1 MCO MHT 1142
N360SW 100 115 87 -10 5 MCO MSY 550
N626SW 114 115 90 13 14 MCO MSY 550
N252WN 107 115 84 -10 -2 MCO MSY 550
N355SW 104 115 85 -1 10 MCO MSY 550
N405WN 113 110 96 14 11 MCO ORF 655
N456WN 110 110 92 24 24 MCO ORF 655
N743SW 144 155 124 7 18 MCO PHL 861
N276WN 142 150 129 -2 6 MCO PHL 861
N369SW 153 145 134 30 22 MCO PHL 861
N363SW 151 145 137 5 -1 MCO PHL 861
N346SW 141 150 128 51 60 MCO PHL 861
N785SW 131 145 118 -15 -1 MCO PHL 861
N635SW 144 155 127 -6 5 MCO PHL 861
N242WN 298 300 276 68 70 MCO PHX 1848
N439WN 130 140 111 -4 6 MCO PIT 834
N348SW 140 135 124 7 2 MCO PIT 834
N672SW 136 135 122 9 8 MCO PIT 834
N493WN 151 160 136 -9 0 MCO PVD 1073
N380SW 170 155 155 13 -2 MCO PVD 1073
N705SW 164 160 147 6 2 MCO PVD 1073
N233LV 157 160 143 1 4 MCO PVD 1073
N786SW 156 160 139 6 10 MCO PVD 1073
N280WN 160 160 146 1 1 MCO PVD 1073
N282WN 104 95 81 10 1 MCO RDU 534
N694SW 89 100 77 3 14 MCO RDU 534
N266WN 94 95 82 9 10 MCO RDU 534
N218WN 98 100 77 12 14 MCO RDU 534
N355SW 47 50 35 15 18 MCO RSW 133
N388SW 44 45 30 37 38 MCO RSW 133
N786SW 46 50 31 4 8 MCO RSW 133
N707SA 52 50 33 10 8 MCO RSW 133
N795SW 176 185 153 -9 0 MCO SAT 1040
N402WN 176 185 161 4 13 MCO SAT 1040
N690SW 123 130 107 -1 6 MCO SDF 718
N457WN 135 130 105 20 15 MCO SDF 718
N720WN 144 155 131 13 24 MCO STL 880
N775SW 147 160 135 -6 7 MCO STL 880
N291WN 136 155 122 96 115 MCO STL 880
N247WN 144 155 127 43 54 MCO STL 880
N748SW 179 185 159 -4 2 MDW ABQ 1121
N709SW 176 190 158 21 35 MDW ABQ 1121
N325SW 110 105 97 36 31 MDW ALB 717
N305SW 116 110 90 107 101 MDW ALB 717
N403WN 145 165 128 -6 14 MDW AUS 972
N767SW 136 165 125 59 88 MDW AUS 972
N730SW 118 120 100 28 30 MDW BDL 777
i have written the code like this but it is not working properly:
a = load '/path/to/file' using PigStorage('\t');
b = foreach a generate (int)$5 as field_a:int,(chararray)$6 as field_b:chararray;
c = group b all;
d = foreach c generate b.field_b,AVG(b.field_a);
e = order d by field_b ASC;
dump e;
I am facing error at order by:
grunt> a = load '/user/horton/sample_pig_data.txt' using PigStorage('\t');
grunt> b = foreach a generate (int)$5 as fielda:int,(chararray)$6 as fieldb:chararray;
grunt> describe #;
b: {fielda: int,fieldb: chararray}
grunt> c = group b all;
grunt> describe #;
c: {group: chararray,b: {(fielda: int,fieldb: chararray)}}
grunt> d = foreach c generate b.fieldb,AVG(b.fielda);
grunt> e = order d by fieldb ;
2017-01-05 15:51:29,623 [main] ERROR org.apache.pig.tools.grunt.Grunt - ERROR 1025:
<line 6, column 15> Invalid field projection. Projected field [fieldb] does not exist in schema: :bag{:tuple(fieldb:chararray)},:double.
Details at logfile: /root/pig_1483631021021.log
I want output like(not related to input data):
(({(Bharathi),(Komal),(Archana),(Trupthi),(Preethi),(Rajesh),(siddarth),(Rajiv) },
{ (72) , (83) , (87) , (75) , (93) , (90) , (78) , (89) }),83.375)
If you have found the answer, best practice is to post it so that others referring to this can have a better understanding.

Implementing SCRAM-SHA1 client, getting it wrong somewhere

Note: I've already read the very good answer to this question, but it doesn't answer my issues.
I'm attempting to implement SCRAM-SHA1 authentication standard, as specified by RFC 5802, in Common Lisp. I am running into issues when it comes to generating the client final response message.
This is the code of the function (the rest of the functions are available here) -- this is an attempt to implement the algorithm as described on page 7 of the RFC:
(defun gen-client-final-message
(&key password client-nonce client-initial-message server-response)
(check-type client-nonce string)
(check-type client-initial-message string)
(check-type server-response string)
(check-type password string)
"Takes a password, the initial client nonce, the initial client message & the server response.
Generates the final client message, and returns it along with the server signature."
(progn
(if (eq nil (parse-server-nonce :nonce client-nonce :response server-response)) NIL)
(let* ((final-message-bare (format nil "c=biws,r=~a" (parse-server-nonce :nonce client-nonce
:response server-response)))
(salted-password (ironclad:pbkdf2-hash-password
(ironclad:ascii-string-to-byte-array password)
:salt (ironclad:ascii-string-to-byte-array
(parse-server-salt :response server-response))
:digest :sha1
:iterations (parse-server-iterations :response server-response)))
(client-key (gen-hmac-digest :key salted-password
:message (ironclad:ascii-string-to-byte-array "Client Key")))
(stored-key (gen-sha1-digest :key client-key))
(auth-message (format nil "~a,~a,~a"
client-initial-message
server-response
final-message-bare))
(client-signature (gen-hmac-digest :key stored-key
:message (ironclad:ascii-string-to-byte-array auth-message)))
(client-proof (integer->bit-vector (logxor (ironclad:octets-to-integer client-key)
(ironclad:octets-to-integer client-signature))))
(server-key (gen-hmac-digest :key salted-password
:message (ironclad:ascii-string-to-byte-array "Server Key")))
(server-signature (gen-hmac-digest :key server-key
:message (ironclad:ascii-string-to-byte-array auth-message)))
(final-message (format nil "~a,p=~a"
final-message-bare
(base64-encode (write-to-string client-proof)))))
(pairlis '(final-message
final-message-bare
salted-password
client-key
stored-key
auth-message
client-signature
client-proof
server-key
server-signature)
(list final-message
final-message-bare
salted-password
client-key
stored-key
auth-message
client-signature
client-proof
server-key
server-signature)))))
The example conversation in the RFC uses the username user and the password pencil:
C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Taking the same server response (r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096) and feeding it into my function, I get:
* (cl-scram:gen-client-final-message :password "pencil" :client-nonce "fyko+d2lbbFgONRv9qkxdawL" :client-initial-message "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL" :server-response "r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096")
((CL-SCRAM::SERVER-SIGNATURE
. #(33 115 21 228 67 190 35 238 223 122 117 125 222 242 209 136 175 228 67
151))
(CL-SCRAM::SERVER-KEY
. #(15 224 146 88 179 172 133 43 165 2 204 98 186 144 62 170 205 191 125 49))
(CL-SCRAM::CLIENT-PROOF
. #*1100100111101011000000111010100000010101011001000101011100110001111100001100100010001101001000110101001010101010001011111000100011100001001110100001001110000)
(CL-SCRAM::CLIENT-SIGNATURE
. #(251 9 164 14 244 111 236 112 227 116 148 143 243 255 231 75 58 114 21
88))
(CL-SCRAM::AUTH-MESSAGE
. "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j")
(CL-SCRAM::STORED-KEY
. #(233 217 70 96 195 157 101 195 143 186 217 28 53 143 20 218 14 239 43
214))
(CL-SCRAM::CLIENT-KEY
. #(226 52 196 123 246 195 102 150 221 109 133 43 153 170 162 186 38 85 87
40))
(CL-SCRAM::SALTED-PASSWORD
. #(29 150 238 58 82 155 90 95 158 71 192 31 34 154 44 184 166 225 95 125))
(CL-SCRAM::FINAL-MESSAGE-BARE
. "c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j")
(CL-SCRAM::FINAL-MESSAGE
. "c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=IyoxMTAwMTAwMTExMTAxMDExMDAwMDAwMTExMDEwMTAwMDAwMDEwMTAxMDExMDAxMDAwMTAxMDExMTAwMTEwMDAxMTExMTAwMDAxMTAwMTAwMDEwMDAxMTAxMDAxMDAwMTEwMTAxMDAxMDEwMTAxMDEwMDAxMDExMTExMDAwMTAwMDExMTAwMDAxMDAxMTEwMTAwMDAxMDAxMTEwMDAw"))
As you can see, my client-proof (the p= part of the final-message) is wildly different to the one in the example.
I added all of the intermediate variables to the return in case anyone here can see what's going wrong. Unfortunately, there are no examples which show the intermediate variable values, so I can't compare what I'm getting to the alternatives.
The intermediate values for the sample in the RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms are on the bottom of this answer.
Your p value is way too long; you are probably encoding the bits as string instead of bytes. You should loop over the byte blocks and XOR each unsigned byte separately. Converting to integer, then to bit string, then back to octet string is going to fail because it will probably remove the most significant zero bits. Once you've got the XOR'ed octet string you can base 64 encode it.
Furthermore, you need to remove n,, from the start of your AuthMessage, as specified in the RFC.
For future developers, without further ado, the intermediate values:
In base 64:
SaltedPassword: HZbuOlKbWl+eR8AfIposuKbhX30=
ClientKey: 4jTEe/bDZpbdbYUrmaqiuiZVVyg=
StoredKey: 6dlGYMOdZcOPutkcNY8U2g7vK9Y=
AuthMessage: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
ClientSignature: XXE4xIawv6vfSePi2ovW5cedthM=
ClientProof: v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
Using decimal arrays:
SaltedPassword: 29 150 238 58 82 155 90 95 158 71 192 31 34 154 44 184 166 225 95 125
ClientKey: 226 52 196 123 246 195 102 150 221 109 133 43 153 170 162 186 38 85 87 40
StoredKey: 233 217 70 96 195 157 101 195 143 186 217 28 53 143 20 218 14 239 43 214
AuthMessage: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
ClientSignature: 93 113 56 196 134 176 191 171 223 73 227 226 218 139 214 229 199 157 182 19
ClientProof: 191 69 252 191 112 115 217 61 2 36 102 201 67 33 116 95 225 200 225 59

Compare two files according to first column and print whole line

I will ask my question with an example. I have 2 files:
File1-
TR100013|c0_g1
TR100013|c0_g2
TR10009|c0_g1
TR10009|c0_g2
File2-
TR100013|c0_g1 AT1G01360.1 78.79 165 35 0 301 795 19 183 2E-089 272
TR100013|c0_g2 AT1G01360.1 78.79 165 35 0 301 795 19 183 2E-089 272
TR10009|c0_g1 AT1G16240.3 77.42 62 14 0 261 76 113 174 4E-025 95.9
TR10009|c0_g2 AT1G16240.2 69.17 120 37 0 1007 648 113 232 2E-050 171
TR29295|c0_g1 AT1G22540.1 69.19 172 53 2 6 521 34 200 2E-053 180
TR49005|c5_g1 AT5G24530.1 69.21 302 90 1 909 13 39 340 5E-157 446
Expected Output :
TR100013|c0_g1 AT1G01360.1 78.79 165 35 0 301 795 19 183 2E-089 272
TR100013|c0_g2 AT1G01360.1 78.79 165 35 0 301 795 19 183 2E-089 272
TR10009|c0_g1 AT1G16240.3 77.42 62 14 0 261 76 113 174 4E-025 95.9
TR10009|c0_g2 AT1G16240.2 69.17 120 37 0 1007 648 113 232 2E-050 171
I want to compare two files. If the first column is same in both files, then print the whole line of second file which is common in both files.
Using awk:
awk 'NR==FNR{a[$1]++;next};a[$1]' file1 file2
grep can do the same:
grep -wf file1 file2
-w is to match whole word only.
-f specifies the file with the pattern.

Marshal public key into OpenSSH format for display

I have an rsa.PublicKey object (retrieved from an rsa.PrivateKey). And I'm trying to export it into the OpenSSH format, to display it in a web page.
I've noticed the go.crypto/ssh library, which seems to be doing this.
And there's the discussion about it's implementation (it's actually exactly what I need to do)
Unfortunately, I'm getting a bit stuck, as the byte array returned is in an unknown encoding and I can't just transform it to a string to display it.
func PublicKey(rsaKey rsa.PublicKey) string {
key, _ := ssh.NewPublicKey(&rsaKey)
marshalled := ssh.MarshalPublicKey(key)
return string(marshalled)
}
This seems to work as it adds the ssh-rsa at the beginning of the string. However, most characters aren't recognized.
Here's the bytes array I'm retrieving for a lambda public key:
[0 0 0 7 115 115 104 45 114 115 97 0 0 0 3 1 0 1 0 0 0 65 0 178 153 15 73 196 125 250 140 212 0 174 106 77 27 138 59 106 19 100 43 35 242 139 0 59 251 151 121 10 222 154 76 200 43 139 42 129 116 125 222 192 139 98 150 229 58 8 195 49 104 126 242 92 75 244 147 107 161 192 230 4 30 157 21]
Any hint on properly displaying this bytes array as a string?
Marshaling a key is for the wire format. You just need to base64 encode the bytes:
base64.StdEncoding.EncodeToString(marshalled) + "\n"