1
00:00:00,000 --> 00:00:02,700
[Powered by Google Translate] [Walkthrough - Problem Set 4]

2
00:00:02,700 --> 00:00:05,000
[Zamyla Chan - Harvard University]

3
00:00:05,000 --> 00:00:07,340
[Dette er CS50. - CS50.TV]

4
00:00:08,210 --> 00:00:11,670
Ok. Hej, alle sammen, og velkommen til Walkthrough 4.

5
00:00:11,670 --> 00:00:14,270
>> I dag er vores Pset er Forensics.

6
00:00:14,270 --> 00:00:18,080
Forensics er et virkelig sjovt Pset der involverer beskæftiger sig med bitmapfiler

7
00:00:18,080 --> 00:00:21,550
at opdage, der har begået en forbrydelse.

8
00:00:21,550 --> 00:00:24,200
Så vi kommer til at ændre størrelsen nogle bitmapfiler,

9
00:00:24,200 --> 00:00:27,780
så er vi også kommer til at beskæftige sig med en virkelig sjov del kaldet Recover,

10
00:00:27,780 --> 00:00:31,160
hvor vi dybest set udleveret et hukommelseskort

11
00:00:31,160 --> 00:00:34,350
hvor nogen har uheld slettet alle deres filer,

12
00:00:34,350 --> 00:00:38,860
og vi bliver bedt om at gendanne disse filer.

13
00:00:38,860 --> 00:00:42,910
>> Men først, før vi kommer ind i Pset, jeg virkelig bare ønsker at lykønske alle.

14
00:00:42,910 --> 00:00:45,230
Vi er ved i midtpunktet af dette kursus.

15
00:00:45,230 --> 00:00:50,070
Quiz 0 er bag os, og vi er ved pset4, så det væsentlige, vi er halvvejs.

16
00:00:50,070 --> 00:00:55,490
Vi er kommet en lang vej, hvis man ser tilbage på dine psets, pset0 og pset1,

17
00:00:55,490 --> 00:00:57,300
så lykønske dig selv om det,

18
00:00:57,300 --> 00:01:00,760
og vi vil komme ind i nogle rigtig sjove ting.

19
00:01:00,760 --> 00:01:07,070
>> Så vores værktøjskasse til denne Pset, igen, i stedet for at køre sudo yum-y update,

20
00:01:07,070 --> 00:01:13,890
vi er i stand til at bare køre update50 hvis du er i version 17,3 og derover af apparatet.

21
00:01:13,890 --> 00:01:17,380
Så sørg for at køre update50 - det er en hel del lettere, et par mindre bogstaver -

22
00:01:17,380 --> 00:01:20,640
at sikre, at du er på den nyeste version af apparatet.

23
00:01:20,640 --> 00:01:25,410
Især er det vigtigt at update50 når vi begynder at bruge CS50 Check.

24
00:01:25,410 --> 00:01:28,700
Så sørg for at du gør det.

25
00:01:28,700 --> 00:01:30,760
>> For alle sektionerne for denne Pset,

26
00:01:30,760 --> 00:01:34,350
vi kommer til at beskæftige sig med fil input og output, fil I / O.

27
00:01:34,350 --> 00:01:38,140
Vi vil være at gå over en masse programmer, der beskæftiger sig med arrays

28
00:01:38,140 --> 00:01:40,350
peger på filer og sådan noget,

29
00:01:40,350 --> 00:01:43,050
så vi ønsker at sikre, at vi er virkelig kender og behageligt

30
00:01:43,050 --> 00:01:47,990
beskæftiger sig med, hvordan man input og output til filer.

31
00:01:47,990 --> 00:01:52,080
>> I fordelingen kode for denne Pset er en fil, der hedder copy.c,

32
00:01:52,080 --> 00:01:55,280
og det er hvad vi vil finde vil være virkelig nyttige for os

33
00:01:55,280 --> 00:02:00,340
fordi vi kommer til at ende op faktisk kopiering af copy.c fil

34
00:02:00,340 --> 00:02:05,350
og blot ændre den lidt for at kunne nå de første 2 dele af problemet sæt.

35
00:02:05,350 --> 00:02:09,030
>> Og så derefter som jeg nævnte før, har vi at gøre med bitmaps samt JPEG.

36
00:02:09,030 --> 00:02:13,170
Så virkelig at forstå strukturen af, hvordan disse filer er organiseret,

37
00:02:13,170 --> 00:02:16,170
hvordan vi virkelig kan oversætte 0'er og 1-taller i struct

38
00:02:16,170 --> 00:02:19,040
og ting, som vi rent faktisk kan forstå og fortolke og redigere,

39
00:02:19,040 --> 00:02:21,000
der vil være virkelig vigtigt,

40
00:02:21,000 --> 00:02:25,970
så gå ind i JPEG og bitmap-filer og forstå strukturen af ​​dem.

41
00:02:25,970 --> 00:02:30,780
>> Pset4 som sædvanlig starter med et afsnit med spørgsmål.

42
00:02:30,780 --> 00:02:36,600
Dem vil beskæftige sig med file I / O og få dig vant til det.

43
00:02:36,600 --> 00:02:42,520
Så del 1 er krimi, hvor du får en bitmap-fil

44
00:02:42,520 --> 00:02:45,630
der ser lidt ligesom røde prikker over det hele.

45
00:02:45,630 --> 00:02:52,180
Og så dybest set, hvad vi vil gøre er at tage denne fil og bare redigere det lidt

46
00:02:52,180 --> 00:02:54,010
ind i en version, som vi kan læse.

47
00:02:54,010 --> 00:02:56,000
Væsentlige, når vi er færdig, vil vi have den samme fil,

48
00:02:56,000 --> 00:03:02,630
medmindre vi vil være i stand til at se det skjulte budskab skjult af alle de røde prikker.

49
00:03:02,630 --> 00:03:07,310
Så Resize er et program, der givet en fil

50
00:03:07,310 --> 00:03:11,490
og derefter givet navnet på den fil, det output og derefter givet et nummer så godt,

51
00:03:11,490 --> 00:03:16,850
rent faktisk vil ændre størrelsen at bitmap ved at heltalsværdi.

52
00:03:16,850 --> 00:03:19,240
Så endelig har vi Recover Pset.

53
00:03:19,240 --> 00:03:24,160
Vi får et hukommelseskort og derefter nødt til at inddrive alle de billeder

54
00:03:24,160 --> 00:03:25,920
der utilsigtet er blevet slettet,

55
00:03:25,920 --> 00:03:31,420
men, som vi vil lære, faktisk ikke slettet og fjernet fra filen;

56
00:03:31,420 --> 00:03:38,470
vi bare lidt tabt, hvor de var i filen, men vi vil komme det.

57
00:03:38,470 --> 00:03:44,950
>> Great. Så gå ind i fil I / O specifikt disse er en hel liste over funktioner, som du skal bruge.

58
00:03:44,950 --> 00:03:49,840
Du har allerede set en lille smule det grundlæggende i fopen, fread og fwrite,

59
00:03:49,840 --> 00:03:54,350
men vi vil se nærmere på nogle fil I / O-funktioner såsom fputc,

60
00:03:54,350 --> 00:03:56,930
hvor du bare skrive et tegn ad gangen,

61
00:03:56,930 --> 00:04:02,000
til fseek, hvor du slags flytte filen position indikator frem og tilbage,

62
00:04:02,000 --> 00:04:05,770
og derefter nogle andre. Men vi vil gå ind i det lidt senere under Pset.

63
00:04:08,050 --> 00:04:13,100
>> Så det første, at bare komme ind i fil I / O, inden vi går ind i Pset,

64
00:04:13,100 --> 00:04:19,860
at åbne en fil, for eksempel, er hvad du skal gøre rent faktisk sætte en pointer til den pågældende fil.

65
00:04:19,860 --> 00:04:22,710
Så vi har en FILE * pointer.

66
00:04:22,710 --> 00:04:27,140
I dette tilfælde, jeg kalder det en i pointer, fordi det kommer til at blive min infile.

67
00:04:27,140 --> 00:04:33,340
Og så jeg har tænkt mig at bruge funktionen fopen og derefter navnet på filen

68
00:04:33,340 --> 00:04:36,360
og derefter den tilstand, som jeg har tænkt mig at beskæftige sig med sagen.

69
00:04:36,360 --> 00:04:42,080
Så der er "r" i dette tilfælde for læsning, "w" til skrivning, og derefter "a" for at tilføje.

70
00:04:42,080 --> 00:04:44,270
For eksempel, du når at gøre med en infile

71
00:04:44,270 --> 00:04:47,310
og alt hvad du ønsker at gøre, er at læse de bits og bytes gemt der,

72
00:04:47,310 --> 00:04:50,420
så er du sikkert lyst til at bruge "r" som din tilstand.

73
00:04:50,420 --> 00:04:54,520
Når du ønsker at faktisk skrive, slags lave en ny fil,

74
00:04:54,520 --> 00:04:57,220
så hvad vi vil gøre, er at vi vil komme til at åbne den nye fil

75
00:04:57,220 --> 00:05:02,410
og bruge "w" mode for at skrive.

76
00:05:02,410 --> 00:05:07,540
>> Så når du rent faktisk læser i de filer, strukturen er som følger.

77
00:05:07,540 --> 00:05:14,930
Først skal du inkludere markøren til struct, der indeholder de bytes, du læser.

78
00:05:14,930 --> 00:05:19,830
Så det vil være enden placeringen af ​​de bytes, du læser.

79
00:05:19,830 --> 00:05:23,360
Du derefter gå til at angive størrelsen, gerne dybest set hvor mange bytes

80
00:05:23,360 --> 00:05:30,100
Deres program er at læse i til filen, størrelsen dybest set et element er,

81
00:05:30,100 --> 00:05:32,620
og så du kommer til at angive, hvor mange elementer, du vil læse.

82
00:05:32,620 --> 00:05:34,980
Og så til sidst, er du nødt til at vide, hvor du læser fra,

83
00:05:34,980 --> 00:05:37,580
så der kommer til at være din i pointer.

84
00:05:37,580 --> 00:05:41,780
Jeg farvekodet disse, fordi fread er også meget lig fwrite,

85
00:05:41,780 --> 00:05:47,050
medmindre du vil være sikker på, at du bruger den rigtige rækkefølge,

86
00:05:47,050 --> 00:05:51,960
sørg for, at du rent faktisk er at skrive til eller læse fra den rigtige fil.

87
00:05:54,910 --> 00:05:58,610
>> Så derefter som før, hvis vi har størrelsen af ​​elementet samt antallet af elementer,

88
00:05:58,610 --> 00:06:00,600
så vi kan spille rundt her en lille smule.

89
00:06:00,600 --> 00:06:06,810
Sige, at jeg har en hund struct og så derefter jeg vil læse to hunde ad gangen.

90
00:06:06,810 --> 00:06:12,450
Hvad jeg kunne gøre, er at sige størrelsen på et element vil være på størrelse med en hund

91
00:06:12,450 --> 00:06:14,770
og jeg har tænkt mig at rent faktisk at læse to af dem.

92
00:06:14,770 --> 00:06:18,290
Alternativt hvad jeg kunne gøre sige jeg bare at læse et element

93
00:06:18,290 --> 00:06:21,340
og at et element vil være på størrelse med to hunde.

94
00:06:21,340 --> 00:06:24,320
Så det er analog, hvordan du kan slags leg rundt med størrelse og antal

95
00:06:24,320 --> 00:06:28,250
afhængigt af, hvad der er mere intuitivt for dig.

96
00:06:28,250 --> 00:06:30,810
>> Ok. Så nu får vi at skrive filer.

97
00:06:30,810 --> 00:06:36,880
Når du ønsker at skrive en fil, det første argument er faktisk hvor du læser fra.

98
00:06:36,880 --> 00:06:42,050
Så det er dybest set de data, du vil skrive i filen,

99
00:06:42,050 --> 00:06:44,490
som er ud pointer i slutningen.

100
00:06:44,490 --> 00:06:47,670
Så når du har at gøre med Pset, så sørg for at du ikke bliver forvirrede.

101
00:06:47,670 --> 00:06:50,480
Måske har definitionerne side om side.

102
00:06:50,480 --> 00:06:58,090
Man kan trække definitionerne i manualen ved at skrive mennesker og derefter fwrite for eksempel

103
00:06:58,090 --> 00:06:59,950
i terminalen, eller du kan henvise tilbage til dette dias

104
00:06:59,950 --> 00:07:03,570
og sørg for, at du bruger den rigtige.

105
00:07:03,570 --> 00:07:08,700
Så igen, for fwrite, når du har en fil, som du vil skrive i,

106
00:07:08,700 --> 00:07:14,290
der kommer til at være den sidste argument og det kommer til at være en pegepind til denne fil.

107
00:07:14,290 --> 00:07:18,670
Så det er, hvordan vi behandler skrive måske flere bytes ad gangen,

108
00:07:18,670 --> 00:07:21,820
men siger du bare lyst til at skrive på blot en enkelt karakter.

109
00:07:21,820 --> 00:07:25,940
Som vi vil se senere i dette eksempel, i de bitmaps vi bliver nødt til at bruge den.

110
00:07:25,940 --> 00:07:32,180
Det er, når vi kan bruge fputc, hovedsagelig bare at sætte et tegn ad gangen, chr,

111
00:07:32,180 --> 00:07:37,050
i filen pointer, og det er vores ud pointer der.

112
00:07:38,700 --> 00:07:41,560
Så når vi søge eller skrive i en fil,

113
00:07:41,560 --> 00:07:44,690
filen er at holde styr på, hvor vi er.

114
00:07:44,690 --> 00:07:47,810
Så det er en slags markør, filen position indikator.

115
00:07:47,810 --> 00:07:54,330
Og så når vi skriver eller læser igen ind i en fil,

116
00:07:54,330 --> 00:07:56,760
filen faktisk husker, hvor det er,

117
00:07:56,760 --> 00:07:59,270
og så det fortsætter fra hvor markøren er.

118
00:07:59,270 --> 00:08:03,970
Dette kan være en fordel, når du vil, sige, læse i et bestemt beløb til at gøre noget

119
00:08:03,970 --> 00:08:06,160
og derefter læse i følgende beløb,

120
00:08:06,160 --> 00:08:10,700
men nogle gange er vi måske ønsker at gå tilbage eller faktisk starter fra en bestemt referenceværdi.

121
00:08:10,700 --> 00:08:16,870
Altsaa fseek funktionen, hvad det gør, er giver os mulighed for at flytte markøren i en bestemt fil

122
00:08:16,870 --> 00:08:19,680
et vist antal bytes.

123
00:08:19,680 --> 00:08:24,260
Og så, hvad vi skal gøre, er angive, hvor referenceværdien er.

124
00:08:24,260 --> 00:08:31,520
Så enten det bevæger sig frem eller tilbage fra hvor markøren i øjeblikket er,

125
00:08:31,520 --> 00:08:35,750
eller vi kan angive, at det bare skal bevæge sig ind fra begyndelsen af ​​filen

126
00:08:35,750 --> 00:08:37,090
eller fra slutningen af ​​filen.

127
00:08:37,090 --> 00:08:41,230
Og så du kan passere i negative eller positive værdier til beløb,

128
00:08:41,230 --> 00:08:44,960
og det vil slags flytte markøren enten fremad eller bagud.

129
00:08:46,170 --> 00:08:51,920
>> Før vi kommer ind i de andre psets, spørgsmål om fil I / O?

130
00:08:53,860 --> 00:08:59,990
Okay. Da vi kommer ind flere eksempler, er du velkommen til at stoppe mig for spørgsmål.

131
00:08:59,990 --> 00:09:06,930
>> Så i krimi, er du udleveret en bitmap-fil ligner denne rød ligger på rutschebanen,

132
00:09:06,930 --> 00:09:14,510
og det ser sådan her ud - en flok røde prikker - og du ikke rigtig ved hvad der er skrevet.

133
00:09:14,510 --> 00:09:23,310
Hvis du squint, kan du være i stand til at se en svag blålig farve inde i midten.

134
00:09:23,310 --> 00:09:26,270
Væsentlige, det er, hvor teksten er gemt.

135
00:09:26,270 --> 00:09:30,270
Der var et mord, der er sket, og vi er nødt til at finde ud af, hvem der gjorde det.

136
00:09:30,270 --> 00:09:36,760
For at gøre det, vi er nødt til at slags konvertere dette billede til et læsbart format.

137
00:09:36,760 --> 00:09:42,740
Hvis du fyre nogensinde er stødt på, nogle gange ville der være lidt kits

138
00:09:42,740 --> 00:09:48,510
hvor du ville have en lup med en rød film. Anyone? Yeah.

139
00:09:48,510 --> 00:09:52,770
Så du ville være handed noget som dette, ville du have en lup

140
00:09:52,770 --> 00:09:58,130
med den røde film over det, ville du sætte den over billedet,

141
00:09:58,130 --> 00:10:03,410
og du ville være i stand til at se den besked skjult deri.

142
00:10:03,410 --> 00:10:07,080
Vi har ikke et forstørrelsesglas med rød film, så i stedet vil vi slags skabe vores egen

143
00:10:07,080 --> 00:10:09,060
i dette Pset.

144
00:10:09,060 --> 00:10:15,760
Og så brugeren kommer til input krimi, så fingerpeg. Bmp,

145
00:10:15,760 --> 00:10:18,800
så det er den infile, det er den røde prik besked,

146
00:10:18,800 --> 00:10:23,550
og så de siger verdict.bmp bliver vores outfile.

147
00:10:23,550 --> 00:10:27,900
Så det kommer til at skabe et nyt bitmap billede ligner den fjerneste anelse

148
00:10:27,900 --> 00:10:32,600
undtagen i et læsbart format, hvor vi kan se den skjulte budskab.

149
00:10:32,600 --> 00:10:37,550
>> Da vi kommer til at beskæftige sig med redigering og manipulere bitmaps af en slags,

150
00:10:37,550 --> 00:10:42,400
vi kommer til at slags dyk i ind strukturen af ​​disse bitmap-filer.

151
00:10:42,400 --> 00:10:48,130
Vi gik over disse lidt i foredrag, men lad os se på dem nogle flere.

152
00:10:48,130 --> 00:10:51,740
Bitmaps er i det væsentlige blot et arrangement af bytes

153
00:10:51,740 --> 00:10:55,790
hvor vi har angivet hvilke bytes betyder hvad.

154
00:10:55,790 --> 00:11:00,540
Så her er lidt ligesom et kort over bitmapbilledet

155
00:11:00,540 --> 00:11:08,550
siger, at det starter med nogle header-filer, starter med nogle oplysninger derinde.

156
00:11:08,550 --> 00:11:16,540
Du ser, at ved ca byte nummer 14 størrelsen er angivet af den bitmapbillede,

157
00:11:16,540 --> 00:11:18,520
og det fortsætter på.

158
00:11:18,520 --> 00:11:23,810
Men hvad vi virkelig er interesseret i her begynder omkring byte nummer 54.

159
00:11:23,810 --> 00:11:26,060
Vi har disse RGB tripler.

160
00:11:26,060 --> 00:11:30,760
Hvad der kommer til at gøre, er at indeholde de faktiske pixels, farveværdierne.

161
00:11:30,760 --> 00:11:35,950
Alt over det i headeren er nogle oplysninger

162
00:11:35,950 --> 00:11:41,240
svarende til størrelsen af ​​billedet, bredden af ​​billedet, og højden.

163
00:11:41,240 --> 00:11:44,930
Når vi går ind i polstring senere, vil vi se, hvorfor størrelsen på billedet

164
00:11:44,930 --> 00:11:48,670
kan være anderledes end bredden eller højden.

165
00:11:48,670 --> 00:11:54,240
Så derefter at repræsentere disse - disse bitmapbilleder er sekvenser af byte -

166
00:11:54,240 --> 00:11:59,370
hvad vi kunne gøre, er at sige okay, jeg skal huske, at på indeks 14,

167
00:11:59,370 --> 00:12:03,380
det er hvor størrelsen er for eksempel, men i stedet hvad vi vil gøre for at gøre det lettere

168
00:12:03,380 --> 00:12:06,020
er indkapsle det i en struct.

169
00:12:06,020 --> 00:12:08,880
Og så har vi to struct lavet for os, en BITMAPFILEHEADER

170
00:12:08,880 --> 00:12:10,440
og en BITMAPINFOHEADER,

171
00:12:10,440 --> 00:12:14,840
og så når vi læser i denne fil, som standard, det vil være at gå i orden,

172
00:12:14,840 --> 00:12:22,360
og så for det er også vil udfylde i variabler såsom biWidth og biSize.

173
00:12:25,270 --> 00:12:31,230
Og så til sidst, er hver pixel repræsenteres af tre bytes.

174
00:12:31,230 --> 00:12:35,500
Den første er mængden af ​​blå i pixel, det andet er mængden af ​​grønt,

175
00:12:35,500 --> 00:12:41,120
og endelig den mængde af rødt, hvor 0 er væsentlige ingen blå eller ingen grønne eller ingen rød

176
00:12:41,120 --> 00:12:43,720
og derefter ff er den maksimale værdi.

177
00:12:43,720 --> 00:12:46,800
Disse er hexadecimale værdier.

178
00:12:46,800 --> 00:12:53,870
Så hvis vi har ff0000, så det svarer til den maksimale mængde blå

179
00:12:53,870 --> 00:12:58,890
og så er ingen grøn og ingen rød, ja så der ville give os en blå pixel.

180
00:12:58,890 --> 00:13:04,190
Så hvis vi har ff all over hele linjen, så det betyder, at vi har en hvid pixel.

181
00:13:04,190 --> 00:13:11,370
Det er en slags modsat typisk når vi siger RGB. Det er faktisk går BGR.

182
00:13:12,750 --> 00:13:18,990
>> Så hvis vi rent faktisk se på et eksempel på et bitmapbillede - lad mig trække en op her.

183
00:13:31,560 --> 00:13:33,830
Det er lidt lille.

184
00:13:39,890 --> 00:13:47,840
Jeg zoomer ind, og vi kan se det er pixeleret. Det ligner farvede blokke.

185
00:13:47,840 --> 00:13:50,110
Du har hvide blokke og derefter røde blokke.

186
00:13:50,110 --> 00:13:53,700
Hvis du spiller i Microsoft Paint, for eksempel, kunne du lave sådan noget

187
00:13:53,700 --> 00:13:58,960
ved egentlig bare male bestemte kvadrater i en bestemt rækkefølge.

188
00:13:58,960 --> 00:14:08,060
Så hvad dette omsættes til i bitmap er som følger.

189
00:14:08,060 --> 00:14:15,710
Her har vi første hvide pixels, at alle 6 er f er, og så har vi røde pixels,

190
00:14:15,710 --> 00:14:19,910
angivet med 0000FF.

191
00:14:19,910 --> 00:14:27,940
Og så sekvens af bytes, som vi har viser, hvordan bitmapbilledet kommer til at se ud.

192
00:14:27,940 --> 00:14:32,230
Så hvad jeg har gjort her, er lige skrevet ud af alle disse bytes, og derefter farvet i rød

193
00:14:32,230 --> 00:14:37,550
så du kan slags se, hvis du skele lidt, hvordan den slags indikerer et smilende ansigt.

194
00:14:40,180 --> 00:14:46,390
>> Den måde, at bitmap billeder arbejde er jeg forestiller det dybest set som et gitter.

195
00:14:46,390 --> 00:14:54,940
Og så som standard, har hver række i gitteret til at være et multiplum af 4 byte.

196
00:15:00,520 --> 00:15:07,060
Hvis vi ser på et bitmapbillede, du udfylder hver værdi.

197
00:15:07,060 --> 00:15:17,370
For eksempel kan du have en rød her, en grøn her, en blå her,

198
00:15:17,370 --> 00:15:24,950
men du skal sørge for, at billedet er udfyldt med et multiplum af fire bytes.

199
00:15:24,950 --> 00:15:32,200
Så hvis jeg vil have mit billede til at være tre blokke bred, så ville jeg nødt til at sætte en tom værdi

200
00:15:32,200 --> 00:15:35,640
i den sidste til at gøre det til et multiplum af fire.

201
00:15:35,640 --> 00:15:39,530
Så da jeg ville tilføje i noget, som vi kalder polstring.

202
00:15:39,530 --> 00:15:43,750
Jeg skal bare til at indikere, at der med en x.

203
00:15:44,920 --> 00:15:54,160
Nu siger vi ønsker et billede, som er 7 pixels lang, for eksempel.

204
00:15:54,160 --> 00:15:59,550
Vi har 1, 2, 3, 4, 5, 6, 7,

205
00:16:04,750 --> 00:16:07,000
og alt dette udfyldes med farve.

206
00:16:07,000 --> 00:16:10,620
Den måde, at bitmapbilleder arbejde er, at vi har brug for en 8..

207
00:16:10,620 --> 00:16:12,460
Lige nu har vi 1, 2, 3, 4, 5, 6, 7.

208
00:16:12,460 --> 00:16:19,360
Vi har brug for 8 pladser til bitmapbilledet at læse korrekt.

209
00:16:19,360 --> 00:16:25,600
Så hvad vi skal gøre er at tilføje i blot en smule polstring

210
00:16:25,600 --> 00:16:29,430
at sikre, at alle bredder er ensartet

211
00:16:29,430 --> 00:16:34,260
og at alle bredder er et multiplum af fire.

212
00:16:42,110 --> 00:16:47,310
Og så jeg tidligere angivet, polstring som en x eller en bølgede linje,

213
00:16:47,310 --> 00:16:53,880
men i selve bitmapbilleder polstringen er angivet med en hexadecimal 0.

214
00:16:53,880 --> 00:16:57,340
Så det ville være et enkelt tegn, 0.

215
00:16:58,980 --> 00:17:06,329
Hvad kan komme i handy er den XXD kommando.

216
00:17:06,329 --> 00:17:11,220
Hvad det gør, er faktisk viser dig, som svarer til, hvad jeg gjorde før med smiley

217
00:17:11,220 --> 00:17:15,630
når jeg faktisk printet ud, hvad hver farve ville være for pixel

218
00:17:15,630 --> 00:17:21,800
og derefter farvekodet det, når du kører XXD med følgende kommandoer,

219
00:17:21,800 --> 00:17:28,670
så vil det rent faktisk udskrive hvad farverne er for de pixels.

220
00:17:28,670 --> 00:17:33,810
Hvad du skal gøre er herovre jeg oplyse, ligesom-s 54

221
00:17:33,810 --> 00:17:36,530
siger, at jeg har tænkt mig at starte på den 54. byte

222
00:17:36,530 --> 00:17:40,820
fordi før at huske, hvis vi ser tilbage til kortet over de bitmaps,

223
00:17:40,820 --> 00:17:42,690
det er alt header information og sådan noget.

224
00:17:42,690 --> 00:17:46,280
Men hvad vi virkelig bekymrer sig om, er de faktiske pixels, der angiver farven.

225
00:17:46,280 --> 00:17:52,700
Så ved at tilføje i denne flag,-s 54, så vi er i stand til at se farveværdierne.

226
00:17:52,700 --> 00:17:56,020
Og du behøver ikke bekymre dig om de komplicerede flag og den slags.

227
00:17:56,020 --> 00:18:05,020
I det problem indstillede spec, har du anvisninger på, hvordan man bruger XXD at vise pixels.

228
00:18:07,070 --> 00:18:15,590
Så hvis du ser her, den slags ligner en grøn boks, denne lille ting.

229
00:18:15,590 --> 00:18:23,610
Jeg har farvekodet den 00ff00 som dybest set sige nej blå, en masse grønt, og ingen røde.

230
00:18:23,610 --> 00:18:26,370
Så det svarer til grøn.

231
00:18:26,370 --> 00:18:31,920
Som du kan se her, ser vi en grøn firkant.

232
00:18:31,920 --> 00:18:36,660
Denne grønne rektangel er kun 3 pixels bred, så derefter hvad vi skal gøre

233
00:18:36,660 --> 00:18:44,350
at sikre, at billedet er et multiplum af 4 bred, er at tilføje i ekstra polstring.

234
00:18:44,350 --> 00:18:49,460
Og så så det er sådan du ser disse 0'er her.

235
00:18:49,460 --> 00:18:54,510
Det vil faktisk være resultatet af din Resize Pset,

236
00:18:54,510 --> 00:19:01,350
væsentligt under den lille bitmap og derefter udvider det med 4.

237
00:19:01,350 --> 00:19:09,380
Og så det, vi ser, er, at der faktisk dette billede er 12 pixels bred, men 12 er et multiplum af 4,

238
00:19:09,380 --> 00:19:12,940
og så vi faktisk ikke se nogen 0'er i slutningen, fordi vi ikke behøver at tilføje nogen

239
00:19:12,940 --> 00:19:19,070
fordi den fuldstændigt er polstret. Det har ikke noget mere plads.

240
00:19:20,720 --> 00:19:23,470
>> Okay. Eventuelle spørgsmål om polstring?

241
00:19:25,150 --> 00:19:27,460
Okay. Cool.

242
00:19:27,460 --> 00:19:32,520
>> Som jeg nævnte før, de bitmaps er blot en sekvens af bytes.

243
00:19:32,520 --> 00:19:39,170
Og så hvad vi har, er i stedet for at skulle holde styr på præcis hvilke antal byte

244
00:19:39,170 --> 00:19:47,050
svarer til et bestemt element, vi faktisk har skabt en struct til at repræsentere det.

245
00:19:47,050 --> 00:19:50,930
Så hvad vi har, er en RGBTRIPLE struct.

246
00:19:50,930 --> 00:19:54,590
Når du har en forekomst af et RGB triple,

247
00:19:54,590 --> 00:20:00,970
fordi det er en type definere struct, så du kan få adgang til rgbtBlue variabel,

248
00:20:00,970 --> 00:20:09,520
tilsvarende er de grønne og røde variabler, som vil indikere, hvor meget blå, grøn og rød,

249
00:20:09,520 --> 00:20:11,580
henholdsvis du har.

250
00:20:11,580 --> 00:20:16,800
>> Så hvis vi har den blå variabel sat til 0, den grønne sæt til ff,

251
00:20:16,800 --> 00:20:22,060
som er den maksimale værdi, du kan få, og derefter det røde variablen sat til 0,

252
00:20:22,060 --> 00:20:27,870
så hvad farve ville denne særlige RGB triple repræsentere? >> [Studerende] Green.

253
00:20:27,870 --> 00:20:29,150
Grøn. Præcis.

254
00:20:29,150 --> 00:20:34,480
Det kommer til at være nyttigt at vide, at når du har en forekomst af et RGB triple,

255
00:20:34,480 --> 00:20:41,340
du kan faktisk få adgang til mængden af ​​farve - blå, grøn og rød - hver for sig.

256
00:20:43,350 --> 00:20:54,900
>> Nu, hvor vi har talt om strukturen af ​​det, så lad os tage et kig på BMP-fil.

257
00:20:54,900 --> 00:20:57,870
Disse er struct lavet til dig.

258
00:20:57,870 --> 00:21:01,820
Her har vi en BITMAPFILEHEADER struct.

259
00:21:01,820 --> 00:21:07,610
Af interesse er størrelsen.

260
00:21:07,610 --> 00:21:12,660
Senere har vi info header, som har et par flere ting, som er interessant for os,

261
00:21:12,660 --> 00:21:15,480
nemlig størrelse, bredden og højden.

262
00:21:15,480 --> 00:21:19,170
Som vi vil gå ind senere, når du læser i til filen,

263
00:21:19,170 --> 00:21:25,500
den automatisk læser i, fordi vi har indstillet for at være den samme.

264
00:21:25,500 --> 00:21:31,990
Så biSize vil indeholde de rette bytes, der svarer til den faktiske størrelse af billedet.

265
00:21:34,700 --> 00:21:40,500
Og så her til sidst, da vi har talt om, har vi RGBTRIPLE typedef struct.

266
00:21:40,500 --> 00:21:46,840
Vi har en rgbtBlue, Grøn og Rød forbundet med det.

267
00:21:48,210 --> 00:21:49,340
>> Great. Okay.

268
00:21:49,340 --> 00:21:56,360
Nu, hvor vi forstår bitmaps en lille smule, forstå, at vi har en fil header

269
00:21:56,360 --> 00:22:00,790
og en info header forbundet med det, og så efter det, vi har interessante ting

270
00:22:00,790 --> 00:22:05,110
af farverne, og disse farver er repræsenteret ved RGBTRIPLE struct,

271
00:22:05,110 --> 00:22:12,710
og dem, til gengæld har tre værdier forbundet til den blå, den grønne og den røde.

272
00:22:12,710 --> 00:22:17,270
>> Så nu kan vi slags tænke på Recover en smule.

273
00:22:17,270 --> 00:22:20,130
Undskyld. Tænk krimi.

274
00:22:20,130 --> 00:22:25,750
Når vi har vores clue fil, så hvad vi ønsker at gøre, er at læse i den pixel for pixel

275
00:22:25,750 --> 00:22:33,860
og derefter en eller anden måde ændre de pixels, så vi kan udlæse det til et læsbart format.

276
00:22:33,860 --> 00:22:41,020
Og så at udskrive det, vi kommer til at skrive pixel for pixel i verdict.bmp fil.

277
00:22:41,020 --> 00:22:45,120
Det er lidt meget at gøre. Vi indser, at.

278
00:22:45,120 --> 00:22:49,860
Så hvad vi har gjort, er at vi har faktisk givet dig copy.c.

279
00:22:49,860 --> 00:22:57,610
Hvad copy.c gør, er bare gør en nøjagtig kopi af en given bitmap-fil og derefter sender det ud.

280
00:22:57,610 --> 00:23:01,900
Så dette allerede åbner filen for dig, lyder i pixel for pixel,

281
00:23:01,900 --> 00:23:04,510
og derefter skriver det i ind i en output-fil.

282
00:23:04,510 --> 00:23:07,080
>> Lad os tage et kig på det.

283
00:23:13,390 --> 00:23:18,290
Dette er at sikre korrekt anvendelse,

284
00:23:18,290 --> 00:23:22,640
få filnavnene her.

285
00:23:22,640 --> 00:23:29,940
Hvad dette betyder er det sætter inddatafilen at være, hvad vi har gået i i infile her,

286
00:23:29,940 --> 00:23:34,750
som er vores anden kommando-line argument.

287
00:23:34,750 --> 00:23:37,640
Kontrol for at sikre, at vi kan åbne filen.

288
00:23:38,960 --> 00:23:44,860
Kontrol for at sikre, at vi kan lave en ny outfile her.

289
00:23:45,630 --> 00:23:53,270
Så hvad dette betyder her, det bare dybest set begynder at læse i den bitmap-fil fra begyndelsen.

290
00:23:53,270 --> 00:23:56,700
Begyndelsen, som vi ved, indeholder BITMAPFILEHEADER,

291
00:23:56,700 --> 00:24:03,200
og så disse sekvenser af bits vil direkte udfylde BITMAPFILEHEADER.

292
00:24:03,200 --> 00:24:07,940
Så hvad vi har her siger, at BITMAPFILEHEADER bf -

293
00:24:07,940 --> 00:24:13,150
Det er vores nye variabel af typen BITMAPFILEHEADER -

294
00:24:13,150 --> 00:24:22,560
vi kommer til at sætte inde bf hvad vi læser fra i pointer, som er vores infile.

295
00:24:22,560 --> 00:24:23,970
Hvor meget skal vi læse?

296
00:24:23,970 --> 00:24:32,160
Vi læser i hvor mange bytes vi nødt til at indeholde hele BITMAPFILEHEADER.

297
00:24:32,160 --> 00:24:34,660
Ligeledes, det er hvad vi gør for info header.

298
00:24:34,660 --> 00:24:39,010
Så vi fortsætter langs vores fil i infile,

299
00:24:39,010 --> 00:24:44,360
og vi læser disse bits og bytes, og vi tilslutte dem direkte i

300
00:24:44,360 --> 00:24:47,880
i disse tilfælde af de variabler, som vi gør.

301
00:24:49,370 --> 00:24:53,800
Her er vi bare at gøre sikker på, at bitmap er en bitmap.

302
00:24:57,670 --> 00:25:01,030
>> Nu har vi en outfile, right?

303
00:25:01,030 --> 00:25:04,420
Så som det står når vi skaber det, det er det væsentlige tom.

304
00:25:04,420 --> 00:25:07,710
Så vi er nødt til at dybest set oprette en ny bitmap fra bunden.

305
00:25:07,710 --> 00:25:12,280
Hvad vi gør, er vi nødt til at sørge for, at vi kopierer i filens header

306
00:25:12,280 --> 00:25:16,850
og info header ligesom infile har.

307
00:25:16,850 --> 00:25:22,850
Hvad vi gør, er vi skriver - og husk, at bf er den variable

308
00:25:22,850 --> 00:25:29,300
af typen BITMAPFILEHEADER, så hvad vi gør, er vi bare bruge det indhold

309
00:25:29,300 --> 00:25:34,980
at skrive ind i outfile.

310
00:25:36,550 --> 00:25:38,510
Her husker vi talte om polstring,

311
00:25:38,510 --> 00:25:47,820
hvordan er det vigtigt at sørge for, at mængden af ​​pixels, som vi har, er et multiplum af 4.

312
00:25:47,820 --> 00:25:52,790
Dette er en smuk nyttig formel til at beregne, hvor meget polstring du har

313
00:25:52,790 --> 00:25:57,670
givet bredden af ​​din fil.

314
00:25:57,670 --> 00:26:04,120
Jeg vil have jer til at huske, at i copy.c har vi en formel for beregning polstring.

315
00:26:04,120 --> 00:26:07,970
Okay? Så alle huske. Great.

316
00:26:07,970 --> 00:26:14,050
Så hvad copy.c gør næste er det gentager over alle de scanlines.

317
00:26:14,050 --> 00:26:23,730
Det går gennem rækkerne først og derefter lagrer hver tredobbelt at den læser

318
00:26:23,730 --> 00:26:26,920
og skriver den i outfile.

319
00:26:26,920 --> 00:26:33,120
Så her er vi læser kun én RGB triple ad gangen

320
00:26:33,120 --> 00:26:39,860
og derefter sætte den samme tredobbelt i outfile.

321
00:26:41,120 --> 00:26:48,340
Den vanskelige del er, at polstringen ikke er et RGB-triple,

322
00:26:48,340 --> 00:26:55,200
og så vi kan ikke bare læse, at polstring mængden af ​​RGB tripler.

323
00:26:55,200 --> 00:27:01,460
Hvad vi skal gøre, er faktisk bare flytte vores fil position indikator, flytte vores markøren,

324
00:27:01,460 --> 00:27:06,840
at slags springe over alle padding, så vi er på den næste række.

325
00:27:06,840 --> 00:27:12,990
Og så, hvad dette gør, er at kopiere viser dig, hvordan du måske ønsker at tilføje polstring.

326
00:27:12,990 --> 00:27:14,990
Så vi har beregnet, hvor meget polstring vi har brug for,

327
00:27:14,990 --> 00:27:18,220
så det betyder, at vi har brug for polstring antal 0'er.

328
00:27:18,220 --> 00:27:24,510
Hvad dette gør, er en for-løkke, der sætter polstring antallet af 0s ind i vores outfile.

329
00:27:24,510 --> 00:27:31,170
Og så til sidst, du lukker begge filer. Du lukker infile samt outfile.

330
00:27:31,170 --> 00:27:34,870
>> Så det er sådan copy.c værker,

331
00:27:34,870 --> 00:27:37,430
og det kommer til at være temmelig nyttig.

332
00:27:39,720 --> 00:27:43,750
I stedet for bare faktisk direkte kopiere og indsætte det

333
00:27:43,750 --> 00:27:46,800
eller bare at kigge på det og skrive i, hvad du ønsker,

334
00:27:46,800 --> 00:27:49,440
du måske bare ønsker at udføre denne kommando i terminalen,

335
00:27:49,440 --> 00:27:54,520
cp copy.c whodunit.c, som vil oprette en ny fil, whodunit.c,

336
00:27:54,520 --> 00:27:58,330
, der indeholder præcis samme indhold som kopi gør.

337
00:27:58,330 --> 00:28:03,880
Så hvad vi kan gøre, er at bruge det som en ramme, som man kan opbygge og redigere

338
00:28:03,880 --> 00:28:06,900
for vores whodunit fil.

339
00:28:08,500 --> 00:28:14,670
>> Disse er vores gøremål at gøre for krimi, men hvad copy.c gør

340
00:28:14,670 --> 00:28:16,730
er faktisk tager sig af de fleste af dem for os.

341
00:28:16,730 --> 00:28:21,900
Så alt vi skal gøre næste er at ændre pixels efter behov

342
00:28:21,900 --> 00:28:25,920
til rent faktisk at gøre filen læsbar.

343
00:28:25,920 --> 00:28:32,960
Husk, at for en givet pixel tredobbelt, således for en given variabel af typen RGBTRIPLE,

344
00:28:32,960 --> 00:28:35,990
du kan få adgang til de blå, grønne og røde værdier.

345
00:28:35,990 --> 00:28:38,670
Det kommer til at komme i praktisk, fordi hvis du har adgang til dem,

346
00:28:38,670 --> 00:28:41,770
det betyder, at du også kan tjekke dem,

347
00:28:41,770 --> 00:28:45,430
og det betyder, at du også kan ændre dem.

348
00:28:45,430 --> 00:28:49,430
>> Så når vi gik tilbage til vores røde forstørrelsesglas eksempel,

349
00:28:49,430 --> 00:28:53,390
dybest set, blev der fungerer som en slags filter for os.

350
00:28:53,390 --> 00:28:58,160
Så hvad vi ønsker at gøre, er at vi ønsker at filtrere alle de tripler, der kommer i.

351
00:28:58,160 --> 00:29:01,240
Der er flere forskellige måder at gøre dette.

352
00:29:01,240 --> 00:29:07,100
Dybest set, kan du få uanset hvilken type filter, du ønsker.

353
00:29:07,100 --> 00:29:09,890
Måske du ønsker at ændre alle røde pixels

354
00:29:09,890 --> 00:29:13,570
eller måske du ønsker at ændre en anden farve pixel til en anden farve.

355
00:29:13,570 --> 00:29:15,400
Det er op til dig.

356
00:29:15,400 --> 00:29:19,580
Husk at du kan tjekke, hvad farve pixel er

357
00:29:19,580 --> 00:29:23,000
og så kan du også ændre det som du går igennem.

358
00:29:24,410 --> 00:29:26,420
>> Okay. Så det er krimi.

359
00:29:26,420 --> 00:29:32,760
Når du kører krimi, vil du vide, hvem synderen af ​​forbrydelsen var.

360
00:29:32,760 --> 00:29:35,540
>> Nu vil vi gå for at ændre størrelse.

361
00:29:35,540 --> 00:29:37,990
Vi vil stadig beskæftiger sig med bitmaps.

362
00:29:37,990 --> 00:29:40,750
Hvad vi vil gøre, er at vi vil have et input bitmap

363
00:29:40,750 --> 00:29:45,890
og så vi kommer til at passere i et nummer og derefter få en outfile bitmap

364
00:29:45,890 --> 00:29:51,380
hvor det er dybest set vores infile skaleret med n..

365
00:29:54,670 --> 00:30:01,450
Sig min fil var blot én pixel stort.

366
00:30:01,450 --> 00:30:09,100
Så hvis min n var 3, skalering med 3, så vil jeg gentage, at pixel n antal gange,

367
00:30:09,100 --> 00:30:14,410
så 3 gange, og derefter også skalere den ned 3 gange så godt.

368
00:30:14,410 --> 00:30:17,840
Så du ser, jeg skalere den lodret såvel som vandret.

369
00:30:17,840 --> 00:30:19,680
>> Og så her er et eksempel.

370
00:30:19,680 --> 00:30:27,590
Hvis du har n = 2, kan du se, at den første blå pixel der gentages to gange

371
00:30:27,590 --> 00:30:30,930
vandret samt to gange lodret.

372
00:30:30,930 --> 00:30:38,040
Og så det fortsætter på, og så har du en direkte skalering af dit oprindelige billede med to.

373
00:30:40,920 --> 00:30:47,600
>> Så hvis vi skulle detalje pseudokoden for dette, vi ønsker at åbne filen.

374
00:30:47,600 --> 00:30:49,880
Og så at vide, at hvis vi går tilbage her,

375
00:30:49,880 --> 00:30:54,540
vi se, at bredden for outfile vil være anderledes end bredden for infile.

376
00:30:54,540 --> 00:30:56,130
Hvad betyder det?

377
00:30:56,130 --> 00:31:01,230
Det betyder, at vores header information kommer til at ændre sig.

378
00:31:01,230 --> 00:31:03,790
Og så, hvad vi skal gøre, er at opdatere header info,

379
00:31:03,790 --> 00:31:11,820
vel vidende, at når vi læser i de filer, hvis du opererer på copy.c rammer,

380
00:31:11,820 --> 00:31:17,570
vi allerede har en variabel, der angiver, hvad størrelsen er og sådan noget.

381
00:31:17,570 --> 00:31:24,060
Så når du har det, hvad du måske ønsker at gøre, er at ændre disse særlige variabler.

382
00:31:24,060 --> 00:31:29,380
Husk, hvis du har en struct, hvordan du får adgang til variable inden det.

383
00:31:29,380 --> 00:31:32,080
Du bruger dot operatør, right?

384
00:31:32,080 --> 00:31:36,420
Så derefter bruge det, du ved, at du bliver nødt til at ændre overskriften info.

385
00:31:36,480 --> 00:31:41,030
Så her er bare en liste over de konkrete elementer, der vil være ved at ændre i din fil.

386
00:31:41,030 --> 00:31:45,180
Filstørrelsen vil ændre sig og billedet, såvel som bredden og højden.

387
00:31:45,180 --> 00:31:50,080
Så derefter gå tilbage til kortet over de bitmaps,

388
00:31:50,080 --> 00:31:57,730
se på, om det er den fil header eller info header, der indeholder disse oplysninger

389
00:31:57,730 --> 00:32:00,920
og derefter ændre efter behov.

390
00:32:05,010 --> 00:32:12,470
Igen siger cp copy.c resize.c.

391
00:32:12,470 --> 00:32:19,270
Det betyder, at resize.c nu indeholder alt, hvad der er indeholdt inde kopi

392
00:32:19,270 --> 00:32:24,490
fordi kopi giver os en metode til at læse i hver scanlinie pixel for pixel.

393
00:32:24,490 --> 00:32:29,860
Undtagen nu, i stedet for bare at ændre de værdier, som vi gjorde i krimi

394
00:32:29,860 --> 00:32:37,980
hvad vi ønsker at gøre, er at vi ønsker at skrive i flere pixels

395
00:32:37,980 --> 00:32:43,580
så længe vores n er større end 1.

396
00:32:43,580 --> 00:32:47,110
>> Så hvad vi ønsker at gøre, er at vi ønsker at strække det vandret ved n,

397
00:32:47,110 --> 00:32:50,490
og strække det lodret ved n.

398
00:32:50,490 --> 00:32:52,710
Hvordan kan vi gøre det?

399
00:32:52,710 --> 00:32:56,890
Sig din n er 2 og du har dette givet infile.

400
00:32:56,890 --> 00:32:58,730
Markøren kommer til at starte på den første,

401
00:32:58,730 --> 00:33:03,530
og hvad du ønsker at gøre, hvis n er 2, du ønsker at udskrive i 2 af dem.

402
00:33:03,530 --> 00:33:05,490
Så du udskrive i 2 af dem.

403
00:33:05,490 --> 00:33:10,830
Så din cursor vil flytte til den næste pixel, som er den røde,

404
00:33:10,830 --> 00:33:18,400
og det kommer til at udskrive 2 i disse røde, tilføjende det på, hvad det er gjort før.

405
00:33:18,400 --> 00:33:26,280
Så markøren vil flytte sig til næste pixel og trække i 2 af dem.

406
00:33:26,280 --> 00:33:37,180
Hvis man ser tilbage til den copy.c ramme, hvad dette betyder lige her

407
00:33:37,180 --> 00:33:42,830
er det skaber en ny instans af en RGB-triple, en ny variabel kaldet triple.

408
00:33:42,830 --> 00:33:50,500
Og her når den læser ind i det, der læses fra infile 1 RGBTRIPLE

409
00:33:50,500 --> 00:33:53,470
og gemmer det inde i det tredobbelte variabel.

410
00:33:53,470 --> 00:33:57,590
Så du rent faktisk har en variabel, der repræsenterer den pågældende pixel.

411
00:33:57,590 --> 00:34:05,290
Så når du skriver, hvad du måske ønsker at gøre, er indramme fwrite erklæring i en for-løkke

412
00:34:05,290 --> 00:34:11,080
der skriver det ind i din outfile så mange gange som nødvendigt.

413
00:34:17,449 --> 00:34:20,100
Det er simpelt nok.

414
00:34:20,200 --> 00:34:27,590
Bare dybest set gentage skriveprocessen n antal gange for at skalere den vandret.

415
00:34:27,590 --> 00:34:32,969
>> Men så skal vi huske, at vores polstring kommer til at ændre.

416
00:34:47,350 --> 00:34:53,020
Tidligere sige, vi havde noget af længde 3.

417
00:34:53,020 --> 00:35:00,130
Så ville vi bare tilføje i hvor meget polstring? Blot én mere for at gøre det til en multipel på 4.

418
00:35:00,130 --> 00:35:10,480
Men siger, at vi skalere dette bestemt billede ved n = 2.

419
00:35:10,480 --> 00:35:16,300
Så hvor mange blå pixels ville vi have i slutningen? Vi ville have 6.

420
00:35:16,300 --> 00:35:21,470
1, 2, 3, 4, 5, 6. Ok.

421
00:35:21,470 --> 00:35:26,580
6 er ikke et multiplum af fire. Hvad er det nærmeste multiplum af 4? Det kommer til at være 8.

422
00:35:26,580 --> 00:35:33,200
Så vi faktisk kommer til at have 2 tegn i polstring der.

423
00:35:33,200 --> 00:35:38,720
>> Er der nogen huske, hvis vi har en formel til at beregne polstring

424
00:35:38,720 --> 00:35:41,350
og hvor det kunne være?

425
00:35:41,350 --> 00:35:45,160
[Uhørlig student svar] >> Yeah, copy.c. Right.

426
00:35:45,160 --> 00:35:49,800
Der er en formel i copy.c at beregne, hvor meget polstring du har

427
00:35:49,800 --> 00:35:53,810
givet en bestemt bredde af bitmapbillede.

428
00:35:53,810 --> 00:36:02,950
Så der kommer til at være nyttigt, når du har brug for at tilføje en vis mængde af polstring

429
00:36:02,950 --> 00:36:06,160
til rent faktisk at regne ud hvor meget polstring skal du tilføje.

430
00:36:10,820 --> 00:36:15,850
Men en note, er dog, at du vil være sikker på, at du bruger den rigtige størrelse.

431
00:36:15,850 --> 00:36:21,410
Bare vær forsigtig, fordi du dybest set kommer til at beskæftige sig med to bitmapbilleder.

432
00:36:21,410 --> 00:36:23,410
Du vil være sikker på, at du bruger den rigtige.

433
00:36:23,410 --> 00:36:26,820
Når du beregne polstring for outfile, du ønsker at bruge bredden af ​​outfile

434
00:36:26,820 --> 00:36:29,860
og ikke over bredden af ​​den foregående.

435
00:36:29,860 --> 00:36:37,240
>> Great. Den slags tager sig af at strække en hel bitmapbillede vandret.

436
00:36:37,240 --> 00:36:41,290
Men hvad vi ønsker at gøre, er faktisk strække det lodret så godt.

437
00:36:41,290 --> 00:36:48,760
Dette vil være en lille smule tricky, fordi når vi er færdige med at kopiere en række

438
00:36:48,760 --> 00:36:51,580
og skrive den pågældende række, er vores markør vil være i slutningen.

439
00:36:51,580 --> 00:36:56,210
Så hvis vi læser igen, så er det bare at læse i til den næste linje.

440
00:36:56,210 --> 00:37:03,660
Så hvad vi ønsker at gøre, er at slags finde en måde at kopiere disse rækker igen

441
00:37:03,660 --> 00:37:12,500
eller bare lidt at tage den pågældende række og derefter omskrivning det igen.

442
00:37:14,380 --> 00:37:17,940
Som jeg slags hentydet til, er der flere forskellige måder at gøre dette.

443
00:37:17,940 --> 00:37:23,040
Hvad du kan gøre, er da du går igennem og læsning gennem det særlige scanlinie

444
00:37:23,040 --> 00:37:28,560
og ændre det efter behov, og derefter slags lager alle disse pixels i et array.

445
00:37:28,560 --> 00:37:36,350
Så senere på du ved, at du bliver nødt til at udskrive denne opstilling igen,

446
00:37:36,350 --> 00:37:39,830
og så kan du bare bruge den opstilling til at gøre det.

447
00:37:39,830 --> 00:37:44,500
En anden måde at gøre det er du kunne kopiere ned én række,

448
00:37:44,500 --> 00:37:47,950
forstå, at du er nødt til at kopiere det igen, så faktisk flytte markøren,

449
00:37:47,950 --> 00:37:50,950
og det kommer til at bruge den metode fseek.

450
00:37:50,950 --> 00:37:56,410
Du kan flytte markøren helt tilbage og derefter gentage kopien processen igen.

451
00:37:56,410 --> 00:38:03,960
>> Så hvis vores skalering nummer er n, så hvor mange gange ville vi nødt til at gå tilbage

452
00:38:03,960 --> 00:38:10,500
og omskrive en linje? >> [Studerende] n - 1. >> Ja, perfekt. n - 1.

453
00:38:10,500 --> 00:38:14,390
Vi har gjort det en gang allerede, så så vil vi gerne gentage gå tilbage proces

454
00:38:14,390 --> 00:38:17,460
n - 1 antal gange.

455
00:38:22,730 --> 00:38:25,860
Okay. Så der har du din resize funktion.

456
00:38:25,860 --> 00:38:34,360
>> Nu kan vi komme til en rigtig sjov del, min favorit Pset, der er Recover.

457
00:38:34,360 --> 00:38:39,580
I stedet for bitmaps, denne gang vi har at gøre med JPEG.

458
00:38:39,580 --> 00:38:43,370
Vi er faktisk ikke givet en fil, blot af JPEG,

459
00:38:43,370 --> 00:38:46,600
vi er givet dybest set en rå hukommelseskort format.

460
00:38:46,600 --> 00:38:51,790
Og så denne indeholder en smule af info og skrald værdier i begyndelsen,

461
00:38:51,790 --> 00:38:57,240
og så det begynder, og det har en masse JPEG-filer.

462
00:38:57,240 --> 00:39:03,430
Men vi udleveret et kort, hvor vi har slettet billederne;

463
00:39:03,430 --> 00:39:08,300
væsentlige, har vi glemt, hvor billederne er placeret i kortet.

464
00:39:08,300 --> 00:39:12,770
Så vores opgave i Recover er at gå gennem dette kort format

465
00:39:12,770 --> 00:39:16,500
og finde de billeder igen.

466
00:39:16,500 --> 00:39:23,990
>> Heldigvis er strukturen af ​​JPEG-filer og kortets fil er lidt hjælpsom.

467
00:39:23,990 --> 00:39:28,850
Det absolut kunne have været en smule mere tricky hvis ikke det var i dette særlige format.

468
00:39:28,850 --> 00:39:40,160
Hver JPEG-fil faktisk starter med to mulige sekvenser, nævnt ovenfor.

469
00:39:40,160 --> 00:39:42,970
Dybest set, når du har en ny JPEG-fil,

470
00:39:42,970 --> 00:39:52,720
det starter med enten sekvensen ffd8 ffe0 eller den anden, ffd8 ffe1.

471
00:39:52,720 --> 00:39:59,530
En anden nyttig ting at vide er, at JPEG gemmes tilstødende.

472
00:39:59,530 --> 00:40:03,380
Så hver gang en JPEG fil ender, den anden starter.

473
00:40:03,380 --> 00:40:07,070
Så der er ikke nogen form for i-mellem værdier der.

474
00:40:07,070 --> 00:40:15,510
Når du rammer starten på en JPEG, hvis du allerede har læst en JPEG,

475
00:40:15,510 --> 00:40:21,800
du ved, at du har ramt enden af ​​den foregående og begyndelsen af ​​det næste.

476
00:40:21,800 --> 00:40:25,890
>> Til slags visualisere dette, gjorde jeg en skematisk.

477
00:40:25,890 --> 00:40:36,910
En anden ting om JPEG er, at vi kan læse dem i sekvenser af 512 byte ad gangen,

478
00:40:36,910 --> 00:40:39,380
ligeledes med begyndelsen af ​​kortet.

479
00:40:39,380 --> 00:40:43,370
Vi behøver ikke at være kontrol hver enkelt byte, fordi det ville sutte.

480
00:40:43,370 --> 00:40:48,200
Så i stedet, hvad vi kan gøre, er faktisk lige læst i 512 byte ad gangen

481
00:40:48,200 --> 00:40:54,700
og derefter, i stedet for at checke ind mellem dem i disse bitte små skiver,

482
00:40:54,700 --> 00:40:58,640
Vi kan bare se begyndelsen af ​​512 byte.

483
00:40:58,640 --> 00:41:02,570
Væsentlige, i dette billede, er hvad du ser i begyndelsen af ​​kortet,

484
00:41:02,570 --> 00:41:08,700
du har værdier, der ikke rigtig relevant for de faktiske JPEG selv.

485
00:41:08,700 --> 00:41:15,830
Men hvad jeg har, er en stjerne at angive et af de to startende sekvenser for en JPEG.

486
00:41:15,830 --> 00:41:19,910
Så når du ser en stjerne, du ved, at du har en JPEG-fil.

487
00:41:19,910 --> 00:41:25,030
Og derefter hver JPEG-fil vil være nogle flere på 512 bytes

488
00:41:25,030 --> 00:41:27,880
men ikke nødvendigvis de samme multiple.

489
00:41:27,880 --> 00:41:32,050
Den måde, du ved, at du har ramt en anden JPEG er, hvis du rammer en anden stjerne,

490
00:41:32,050 --> 00:41:39,090
anden start sekvens af bytes.

491
00:41:39,090 --> 00:41:43,330
Så hvad har du her er du har den røde JPEG-fil fortsætter, indtil du rammer en stjerne,

492
00:41:43,330 --> 00:41:45,150
som er angivet med en ny farve.

493
00:41:45,150 --> 00:41:48,510
Du fortsætter og så du rammer en anden stjerne, du rammer en anden JPEG,

494
00:41:48,510 --> 00:41:50,590
du fortsætte hele vejen indtil slutningen.

495
00:41:50,590 --> 00:41:53,180
Du er på det sidste billede her, den lyserøde.

496
00:41:53,180 --> 00:41:58,220
Du gå til enden, indtil du rammer slutningen af ​​filen karakter.

497
00:41:58,220 --> 00:42:00,820
Dette vil være virkelig nyttige.

498
00:42:00,820 --> 00:42:03,170
>> Et par vigtige grillbarer her:

499
00:42:03,170 --> 00:42:06,670
Kortet Filen starter ikke med en JPEG,

500
00:42:06,670 --> 00:42:13,350
men når en JPEG starter, er alle de JPEG lagrede side om side med hinanden.

501
00:42:17,520 --> 00:42:20,420
>> Nogle pseudokoden for Recover.

502
00:42:20,420 --> 00:42:22,570
Først vil vi åbne vores kartotek,

503
00:42:22,570 --> 00:42:27,500
og det kommer til at bruge vores fil I / O-funktioner.

504
00:42:27,500 --> 00:42:32,430
Vi kommer til at gentage følgende proces, indtil vi har nået slutningen af ​​filen.

505
00:42:32,430 --> 00:42:36,450
Vi kommer til at læse 512 bytes ad gangen.

506
00:42:36,450 --> 00:42:39,180
Og det, jeg sagde her er vi vil gemme det i en buffer,

507
00:42:39,180 --> 00:42:46,230
så dybest set holde på de 512 byte, indtil vi ved præcis, hvad de skal gøre med dem.

508
00:42:46,230 --> 00:42:50,300
Så hvad vi ønsker at gøre, er at vi ønsker at tjekke, om vi har ramt en stjerne eller ej.

509
00:42:50,300 --> 00:42:57,960
Hvis vi har ramt en stjerne, hvis vi har ramt en af ​​de startende sekvenser,

510
00:42:57,960 --> 00:42:59,980
så ved vi, at vi har ramt en ny JPEG-fil.

511
00:42:59,980 --> 00:43:08,860
Hvad vil vi gerne vil gøre, er at vi vil ønsker at oprette en ny fil i vores pset4 bibliotek

512
00:43:08,860 --> 00:43:14,480
at fortsætte med at foretage den pågældende fil.

513
00:43:14,480 --> 00:43:18,220
Men også, hvis vi allerede har lavet en JPEG før,

514
00:43:18,220 --> 00:43:25,620
så ønsker vi at afslutte denne fil og skubbe det til pset4 mappe,

515
00:43:25,620 --> 00:43:29,780
hvor vi vil få denne fil er gemt, fordi hvis vi ikke specificere, at vi er endt som JPEG-fil,

516
00:43:29,780 --> 00:43:37,290
så vil vi stort set har et ubestemt beløb. De JPEG vil aldrig ende.

517
00:43:37,290 --> 00:43:40,840
Så vi ønsker at sikre, at når vi læser ind på en JPEG-fil og skrive det,

518
00:43:40,840 --> 00:43:46,590
vi specifikt vil lukke, at for at åbne den næste.

519
00:43:46,590 --> 00:43:48,430
Vi ønsker at kontrollere flere ting.

520
00:43:48,430 --> 00:43:52,880
Vi ønsker at undersøge, om vi er i starten af ​​en ny JPEG med vores buffer

521
00:43:52,880 --> 00:43:56,780
og også hvis vi allerede har fundet en JPEG før

522
00:43:56,780 --> 00:44:03,930
fordi der vil ændre dit proces lidt.

523
00:44:03,930 --> 00:44:07,880
Så efter du er gået igennem hele vejen og du rammer slutningen af ​​filen,

524
00:44:07,880 --> 00:44:11,570
så hvad du ønsker at gøre, er du ønsker at lukke alle de filer, der er åbne.

525
00:44:11,570 --> 00:44:14,100
Det vil sandsynligvis være den sidste JPEG-fil, du har,

526
00:44:14,100 --> 00:44:18,930
samt det kort fil, du har med at gøre.

527
00:44:21,940 --> 00:44:28,670
>> Den sidste forhindring, som vi er nødt til at tackle, er, hvordan man faktisk gøre en JPEG-fil

528
00:44:28,670 --> 00:44:31,950
og hvordan man rent faktisk skubbe det til mappen.

529
00:44:33,650 --> 00:44:39,850
Det Pset kræver, at alle JPEG, at du finder være i følgende format,

530
00:44:39,850 --> 00:44:43,990
hvor du har nummeret. jpg.

531
00:44:43,990 --> 00:44:50,750
Antallet, selv om det er 0, kalder vi det 000.jpg.

532
00:44:50,750 --> 00:44:55,730
Når du finder en JPEG i dit program,

533
00:44:55,730 --> 00:44:58,040
du vil ønsker at navngive det i den rækkefølge, det er fundet.

534
00:44:58,040 --> 00:44:59,700
Hvad betyder dette?

535
00:44:59,700 --> 00:45:03,530
Vi er nødt til at slags holde styr på hvor mange vi har fundet

536
00:45:03,530 --> 00:45:08,680
og hvilken antallet af hvert JPEG bør være.

537
00:45:08,680 --> 00:45:13,800
Her vil vi drage fordel af den sprintf funktion.

538
00:45:13,800 --> 00:45:17,480
Svarende til printf, som bare lidt udskriver en værdi ud i terminalen,

539
00:45:17,480 --> 00:45:23,910
sprintf udskriver filen ud i mappen.

540
00:45:23,910 --> 00:45:30,870
Og så, hvad dette ville gøre, hvis jeg havde sprintf, titel og derefter strengen der,

541
00:45:30,870 --> 00:45:36,660
det ville udskrive 2.jpg.

542
00:45:36,660 --> 00:45:41,020
Antages det, at jeg har lukket mine filer korrekt,

543
00:45:41,020 --> 00:45:47,210
der ville indeholde den fil, jeg havde skrevet ud.

544
00:45:47,210 --> 00:45:50,320
Men én ting er, at den kode, jeg har her

545
00:45:50,320 --> 00:45:53,360
ikke helt opfylder hvad Pset kræver.

546
00:45:53,360 --> 00:46:02,410
Det Pset kræver, at den anden JPEG-fil skal navngives 002 i stedet for bare 2.

547
00:46:02,410 --> 00:46:09,160
Så når du udskriver navnet, så måske du måske ønsker at ændre pladsholderen lidt.

548
00:46:09,160 --> 00:46:18,140
>> Er der nogen huske, hvordan vi gør det muligt ekstra mellemrum, når vi udskriver noget?

549
00:46:18,140 --> 00:46:22,530
Yeah. >> [Studerende] Du sætter en 3 mellem procenttegn og 2. >> Ja, perfekt.

550
00:46:22,530 --> 00:46:25,610
Du vil sætte en 3 i dette tilfælde, fordi vi ønsker plads til 3.

551
00:46:25,610 --> 00:46:32,590
% 3d ville sandsynligvis give dig 002.jpg stedet for 2.

552
00:46:32,590 --> 00:46:40,120
Det første argument i sprintf funktion er faktisk en char array,

553
00:46:40,120 --> 00:46:42,520
som vi tidligere kendte som strenge.

554
00:46:42,520 --> 00:46:50,700
Dem vilje, slags mere som en midlertidig opbevaring, bare gemme den resulterende streng.

555
00:46:50,700 --> 00:46:54,950
Du vil ikke rigtig beskæftige sig med dette, men du er nødt til at inkludere den.

556
00:46:54,950 --> 00:47:00,710
>> Vel vidende, at hver fil navn har det antal, som fylder tre tegn,

557
00:47:00,710 --> 00:47:06,770
og derefter. jpg, hvor langt skal dette array være?

558
00:47:09,070 --> 00:47:14,310
Smid et nummer. Hvor mange tegn i titlen, i navnet?

559
00:47:18,090 --> 00:47:26,320
Så der er 3 hashtags, periode, jpg. >> [Studerende] 7. >> 7. Ikke helt.

560
00:47:26,320 --> 00:47:32,000
Vi kommer til at have 8, fordi vi ønsker at give mulighed for null terminator så godt.

561
00:47:45,340 --> 00:47:49,730
>> Endelig bare trække ud den proces, du skal gøre for Recover,

562
00:47:49,730 --> 00:47:55,420
du har nogle begyndelsen information.

563
00:47:55,420 --> 00:48:02,460
Du fortsætter indtil du finder starten på en JPEG-fil,

564
00:48:02,460 --> 00:48:07,900
og det kan være en af ​​de to udgangsmaterialer sekvenser.

565
00:48:07,900 --> 00:48:12,510
Du holder på at læse. Hver skråstreg her repræsenterer 512 bytes.

566
00:48:12,510 --> 00:48:22,630
Man holde på læsning, holde på læsning, indtil du møder en anden startsekvens.

567
00:48:22,630 --> 00:48:29,790
Når du har det, du ender den aktuelle JPEG - i dette tilfælde er det den røde,

568
00:48:29,790 --> 00:48:31,030
så du ønsker at ende det.

569
00:48:31,030 --> 00:48:35,540
Du ønsker at sprintf navnet på det i din pset4 mappe,

570
00:48:35,540 --> 00:48:41,580
så du ønsker at åbne en ny JPEG og derefter fortsætte med at læse

571
00:48:41,580 --> 00:48:46,370
indtil du støder den næste.

572
00:48:46,370 --> 00:48:49,040
Hold på læsning, holde på læsning,

573
00:48:49,040 --> 00:48:56,290
og så endelig til sidst, er du nødt til at nå slutningen af ​​filen,

574
00:48:56,290 --> 00:49:00,360
og så vil du ønsker at lukke den sidste JPEG som du arbejdede med,

575
00:49:00,360 --> 00:49:08,380
sprintf at i din pset4 mappe, og derefter se på alle de billeder, som du har fået.

576
00:49:08,380 --> 00:49:12,050
Disse billeder er faktisk billeder af CS50 medarbejdere,

577
00:49:12,050 --> 00:49:16,430
og så er det her den bonus sjove del af Pset kommer i

578
00:49:16,430 --> 00:49:26,310
er, at du konkurrerer i dine afsnit for at finde de TF'er på billederne

579
00:49:26,310 --> 00:49:34,610
og tage billeder med dem for at bevise, at du har gjort det Pset

580
00:49:34,610 --> 00:49:37,030
og så du kan se, hvilke medarbejdere er i billederne.

581
00:49:37,030 --> 00:49:41,510
Så du tager billeder med personalet. Nogle gange vil du nødt til at jage dem ned.

582
00:49:41,510 --> 00:49:44,680
Sandsynligvis nogle af dem vil forsøge at løbe væk fra dig.

583
00:49:44,680 --> 00:49:47,320
Du tager billeder med dem.

584
00:49:47,320 --> 00:49:51,190
Dette er igangværende. Det er ikke på grund af, når Pset skyldes.

585
00:49:51,190 --> 00:49:53,340
Fristen vil blive annonceret i spec.

586
00:49:53,340 --> 00:49:58,060
Så sammen med din afdeling, alt efter hvilken sektion tager de fleste billeder

587
00:49:58,060 --> 00:50:04,430
med flest ansatte vil vinde en temmelig awesome præmie.

588
00:50:04,430 --> 00:50:08,890
Det er lidt incitament til at få din pset4 færdig så hurtigt som muligt

589
00:50:08,890 --> 00:50:10,820
fordi så kan du komme ned til erhvervslivet

590
00:50:10,820 --> 00:50:14,570
jage alle de forskellige CS50 ansatte.

591
00:50:14,570 --> 00:50:17,500
Det er ikke obligatorisk, men så når du får billederne,

592
00:50:17,500 --> 00:50:20,310
så du er færdig med pset4.

593
00:50:20,310 --> 00:50:23,970
>> Og jeg er færdig med Walkthrough 4, så tak alle for at komme.

594
00:50:23,970 --> 00:50:29,330
Held og lykke med Forensics. [Bifald]

595
00:50:29,330 --> 00:50:31,000
[CS50.TV]