Hoe een paar bytes in een file te patchen...

[Verwijderd]

Goedemorgen/middag.avond/nacht *) Tweakers

Ik wil in een collectie files automatisch een paar bytes van waarde veranderen. Is er een standaard utility (onder Linux) die ik daar voor kan gebruiken?

Hope to hear Aad Slingeland

*) Doorhalen wat niet van toepassing is

[blaataaps]

Daar zijn ongeveer 100 programma's voor, het hangt nogal af van wat je wil doen. Zijn het bytes op een vaste offset? Zijn het bytes met een vaste waarde? Is het een binair bestand, of alleen tekst? Is het een bepaald type waarvan je de header wil veranderen, een plaatje of een filmpje? Altijd op dezelfde regel? Wat heb je zelf al gevonden?

[ Voor 15% gewijzigd door blaataaps op 10-10-2009 10:18 ]

[LPEspecial]

Voor de simpele dingen gewoon een editor met binaire mode zoals: Notepad++, UltraEdit, etc.

[Verwijderd]

blaataaps schreef op zaterdag 10 oktober 2009 @ 10:18:
Zijn het bytes op een vaste offset?
Zijn het bytes met een vaste waarde?
Is het een binair bestand, of alleen tekst?
Is het een bepaald type waarvan je de header wil veranderen, een plaatje of een filmpje?
Wat heb je zelf al gevonden?

Ok ik had best wat duidelijker kunnen zijn...

Het gaat om binaire files waarvan ik de waarden van byte 15, 16, 17 en 18 wil aanpassen naar een vaste waarde.

Even terug naar af...

Het gaat om (een grote verzameling) JPEG files waar van ik de resolutie op 92 x 92 wil zetten.

En ja... ik weet dat de resolutie (ik bedoel _niet_ de groote van de JPEG image in pixels) van weinig waarde is bij de uiteindelijke presentatie van een JPEG. Maar de waarde 92x92 is een museale standaard en ik maak gewoon een paar mensen weer blij (het stelt ze gerust) als de JPEGs deze waarde hebben.

De resolutie van een JPEG staat in de bytes 15 t/m 18 en het is een kleine moeite dat met UltaEdit o.i.d aan te passen. Maar nu nog voor die andere tweehondervijftigduizend files...

Aad Slingerland
Vrijwiller Liemers Museum


)

[Verwijderd]

LPEspecial schreef op zaterdag 10 oktober 2009 @ 10:21:
Voor de simpele dingen gewoon een editor met binaire mode zoals: Notepad++, UltraEdit, etc.

Yep... Ik heb met ultraedit een testje gedaan en dat levert precies op wat ik wil. Maar nu die andere 250.000 files nog die op een linux server staan. De patch moet uiteindelijk automatisch gedaan worden.

TX Aad

[Verwijderd]

[b][message=32714324,noline]
Wat heb je zelf al gevonden?

Oh ja...

diff (alleen voor text files)
patch. ik zit net hier te kijken: http://linux.die.net/man/1/patch

Aad

[blaataaps]

Ik weet niet of patch voor binaire bestanden werkt, maar als het altijd dezelfde bytes zijn, zou ik met perl een poging wagen, en het kan eventueel zelfs met dd, maar daar zou ik erg voorzichtig mee zijn (en het scriptje sowieso testen op een kopie van de echte data, ongeacht de software ).

[Freee!!]

Ik zou gewoon een klein C (niet C++) programmaatje schrijven met als parameter een bestandsnaam dat die 4 bytes gewoon overschrijft. Een shell scriptje eromheen dat gewoon alle bestanden in een directory (desnoods van slechts één type) aan het programmaatje voert en je bent klaar. Als je het goed doet, is er ook geen probleem als een bestand per ongeluk meer dan één keer gedaan wordt.

[Verwijderd]

blaataaps schreef op zaterdag 10 oktober 2009 @ 11:16:
Ik weet niet of patch voor binaire bestanden werkt, maar als het altijd dezelfde bytes zijn,

De site die ik net aan het bekijken was (patch) laat wel zien dat er een binary optie is:

--binary
Read and write all files in binary mode, except for standard output and /dev/tty.

Ik denk dat ik hier eerst maar eens mee verde ga...

Thanks Aad

[Icekiller2k6]

'ips' kun je eens bekijken ?

[Verwijderd]

Freee!! schreef op zaterdag 10 oktober 2009 @ 11:24:
Ik zou gewoon een klein C (niet C++) programmaatje schrijven met als parameter een bestandsnaam...

C? Ik dacht eigenlijk aan assembler

Mijn C kennis is welliswaar wat roestig maar daar zou ik ook wel uit komen.

TX Aad

[Henk007]

Als het specifiek over JPG bestanden gaat, is het dan geen idee om het te doen met een image converter, bijvoorbeeld NConvert, die is ook voor Linux beschikbaar.
Ik heb het even opgezocht, er zit een commando in om de DPI resolutie te wijzigen:

code:

nconvert  -dpi res_dpi filename

[ Voor 24% gewijzigd door Henk007 op 10-10-2009 11:48 ]

[Verwijderd]

Icekiller2k6 schreef op zaterdag 10 oktober 2009 @ 11:36:
'ips' kun je eens bekijken ?

IPS? Intrusion Protection System?

[Freee!!]

Verwijderd schreef op zaterdag 10 oktober 2009 @ 11:38:
[...]
C? Ik dacht eigenlijk aan assembler

Mijn C kennis is welliswaar wat roestig maar daar zou ik ook wel uit komen.

TX Aad

Misschien heb je iets aan een paar voorbeelden? Zoja, kijk dan eens hier. "Edit Thunderbird Forward" patcht een exe-file na het opzoeken van de juiste posities en een paar andere accepteren parameters. Er staat ook een link naar een gratis C-ontwikkelomgeving met compiler.

[Thralas]

Wat shell-fu is ook al voldoende. Uiteraard eerst even backuppen.

code:

find -name '*.jpg' -exec sh -c 'echo -ne \\x41\\x42\\x43\\x45 | dd of={} seek=14 bs=1 conv=notrunc' \;

In plaats van \\x41\\x42\\x43\\x45 even de juiste 4 bytes invullen. Het zijn (escaped) hexadecimale waardes, zie ook ASCII table. Dit voorbeeldje schrijft 'ABCD' naar offset 14 (de vijftiende byte).

Hoe de performance is weet ik niet, dat zul je even moeten testen. Hij roept wel per file sh + dd aan.

Iemand die het met alleen een shell nog efficienter kan? De escapes zitten me dwars

[GraveR]

En nog een in C voor de archieven:

code:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv) {

    FILE *file;
    static char patch[]={0x2C,0x00,0x2C,0x00};

    if (argc < 2) {
        printf("Usage: %s <filename>\n",argv[0]);
        return(EXIT_FAILURE);
    }

    if (file = fopen(argv[1],"r+")) {
        fseek(file,15,SEEK_SET);
        fwrite(patch, 1, sizeof(patch), file);
        fclose(file);
    } else {
        printf("Could not open %s\n",argv[1]);
        exit (EXIT_FAILURE);
    }

    return (EXIT_SUCCESS);
}

static char patch[] verander door de byte sequence die je wilt.

[ Voor 27% gewijzigd door GraveR op 10-10-2009 12:12 ]

[Confusion]

Freee!! schreef op zaterdag 10 oktober 2009 @ 11:24:
Ik zou gewoon een klein C (niet C++) programmaatje schrijven met als parameter een bestandsnaam dat die 4 bytes gewoon overschrijft.

Waarom C? Waarom niet Perl, Python, AWK of een andere taal die zeer waarschijnlijk beschikbaar is?

[CyBeR]

Confusion schreef op zaterdag 10 oktober 2009 @ 14:42:
[...]

Waarom C? Waarom niet Perl, Python, AWK of een andere taal die zeer waarschijnlijk beschikbaar is?

Omdat je voor veel files een belachelijke hoeveelheid onnodige overhead hebt als je heel python/perl/whatever in moet laden, en awk voor text is. Een paar bytes aanpassen is een paar regels C zonder libraries (afgezien van LibC).

[ Voor 9% gewijzigd door CyBeR op 10-10-2009 14:48 ]

[Verwijderd]

code:

nconvert  -dpi res_dpi filename

Thanks Henk! Dit is precies waar het mij om gaat. Handig om nconvert erbij te hebben. In mijn digitale gereedschapsdoos bedoel ik...

Aad

[Verwijderd]

Confusion schreef op zaterdag 10 oktober 2009 @ 14:42:
[...]
Waarom C? Waarom niet Perl, Python, AWK of een andere taal die zeer waarschijnlijk beschikbaar is?

C is (bij mij) wel beschikbaar hoor... Visual Studio 2008 voor windows en gcc in mijn linux omgeving.
Inmiddels heb ik de nconvert maar ingezet want doe doet gewoon dat laatste stukkie dat ik nog nodig had.

Wth Regards, Aad Slingerland

[Confusion]

CyBeR schreef op zaterdag 10 oktober 2009 @ 14:47:
Omdat je voor veel files een belachelijke hoeveelheid onnodige overhead hebt als je heel python/perl/whatever in moet laden

FUD. Stel je voor dat het een seconde per bestand duurt, in plaats van 0.8 seconde.

en awk voor text is

En het dan gebruiken voor een binair bestand heet 'hacken'

Een paar bytes aanpassen is een paar regels C zonder libraries (afgezien van LibC).

Ook een paar regels Python, zonder libraries (afgezien van delen van de standaard library).

Verwijderd schreef op zaterdag 10 oktober 2009 @ 14:55:
C is (bij mij) wel beschikbaar hoor...

Ik bedoelde ook beschikbaar.

[ Voor 13% gewijzigd door Confusion op 10-10-2009 15:00 ]

[Freee!!]

Confusion schreef op zaterdag 10 oktober 2009 @ 14:42:
[...]
Waarom C? Waarom niet Perl, Python, AWK of een andere taal die zeer waarschijnlijk beschikbaar is?

Ik noemde C omdat ik weet dat het daarin kan. Ik ken Perl, Python, AWK en dergelijke niet, van een aantal weet ik nog net hoe je de naam spelt en van nog een paar ken ik de naam niet eens.

Ik heb zelf een soortgelijk probleempje gehad en als programmeur (COBOL en RPG op AS/400) op zoek gegaan naar een gratis compiler voor mijn Windows PC. Ik kon geen bruikbare COBOL (of RPG) compiler vinden, dus heb ik maar even C geleerd.

Ik hoop dat ik je vraag hiermee afdoende beantwoord heb

[Freee!!]

Confusion schreef op zaterdag 10 oktober 2009 @ 14:58:
[...]
FUD. Stel je voor dat het een seconde per bestand duurt, in plaats van 0.8 seconde.

Ik schat zo in dat het met een goed C programmaatje minder dan 0,1 seconde duurt in plaats van die seconde per bestand.

[Confusion]

Freee!! schreef op zaterdag 10 oktober 2009 @ 15:36:
Ik noemde C omdat ik weet dat het daarin kan. Ik ken Perl, Python, AWK en dergelijke niet, van een aantal weet ik nog net hoe je de naam spelt en van nog een paar ken ik de naam niet eens.
[..]
Ik hoop dat ik je vraag hiermee afdoende beantwoord heb

Nou, mijn punt was eigenlijk alleen maar dat je antwoord suggereerde dat C de meest/enige geschikte taal is om zoiets in te doen. Als ik een systeembeheerder was met weinig programmeerkennis en ik kreeg dat als advies, dan zou ik misschien al snel denken 'pfft, C, laat maar'. Terwijl het net zo goed in een willekeurige andere taal kan; zoals Thralas laat zien, zelfs gewoon in de shell.

[Freee!!]

Confusion schreef op zaterdag 10 oktober 2009 @ 17:14:
[...]
Nou, mijn punt was eigenlijk alleen maar dat je antwoord suggereerde dat C de meest/enige geschikte taal is om zoiets in te doen.

Als jij dat erin gelezen hebt, is dat jammer maar dat was niet mijn bedoeling. Ik schreef alleen wat ik gedaan zou hebben.

Als ik een systeembeheerder was met weinig programmeerkennis en ik kreeg dat als advies, dan zou ik misschien al snel denken 'pfft, C, laat maar'.

Dat is aan die systeembeheerder.

Terwijl het net zo goed in een willekeurige andere taal kan; zoals Thralas laat zien, zelfs gewoon in de shell.

Ik weet dat programmeurs werk hebben omdat systeembeheerders tools nodig hebben. En de programmeertaal is deels een kwestie van wat de programmeur kent en deels van wat beschikbaar is.

[Confusion]

Freee!! schreef op zaterdag 10 oktober 2009 @ 17:33:
[...]
Als jij dat erin gelezen hebt, is dat jammer maar dat was niet mijn bedoeling.

Ik wist ook niet of het je bedoeling was, maar als ik het er in lees, dan zijn er vast anderen die het er in lezen en dan is een opmerking als 'Het kan ook in x, y en z' toch niet heel erg overbodig?

[hostname]

Confusion schreef op zaterdag 10 oktober 2009 @ 14:58:
FUD. Stel je voor dat het een seconde per bestand duurt, in plaats van 0.8 seconde.

Hij zegt dat het 250.000 files zijn, 0.2 seconde * 250.000 = 50.000 seconden extra. Komt neer op zo'n 13 uur, dus ik zou dat niet te makkelijk afdoen...

[CyBeR]

Confusion schreef op zaterdag 10 oktober 2009 @ 14:58:
[...]

FUD. Stel je voor dat het een seconde per bestand duurt, in plaats van 0.8 seconde.

Sorry, maar we hebben 't over een C programma dat dit in 0.005 seconden doet (op mijn systeem). Python launchen alleen al duurt 0.026 seconden, en dat is dan zonder iets te doen (python -c exit). Dus even alleen op basis van een C programma dat iets doet en een python programma dat niets doet, voor 250.000 files:

code:

250000 * 0.005
1250.000
250000 * 0.026
6500.000

5250 seconden extra, dus, om python alleen maar op te starten. Dat is overhead die nergens voor nodig is.

Om 't nog niet te hebben over dat de term 'FUD' gewoon niet van toepassing is hier.

En het dan gebruiken voor een binair bestand heet 'hacken'

Nee, dat heet dom bezig zijn en je tijd verdoen met nutteloze dingen.

[ Voor 6% gewijzigd door CyBeR op 10-10-2009 18:13 ]

[Confusion]

hostname schreef op zaterdag 10 oktober 2009 @ 17:50:
[...]

Hij zegt dat het 250.000 files zijn, 0.2 seconde * 250.000 = 50.000 seconden extra. Komt neer op zo'n 13 uur, dus ik zou dat niet te makkelijk afdoen...

Ik had een voorbeeld met realistischere waarden moeten geven. Nu durf ik niet meer te gokken, dus heb ik het maar even gebenched voor 10K bestanden. Met de C code van GraveR:

ivo@twen:~/tmp/tmp$ time (for i in `seq 1 10000`; do ./a.out foo$i; done)

real 0m58.423s
user 0m11.405s
sys 0m15.317s


Met equivalente python code:

ivo@twen:~/tmp/tmp$ time (for i in `seq 1 10000`; do ./changebytes.py foo$i; done)

real 5m5.408s
user 3m16.028s
sys 1m17.357s

een stuk langer, maar ook een onhandige manier van Python gebruiken. Ben je zo handig om de lus in het Python script te stoppen, dan is het
ivo@twen:~/tmp/tmp$ time ./changebytes.py

real 0m0.543s
user 0m0.252s
sys 0m0.284s

en ik betwijfel of de C code die hetzelfde doet veel sneller is dan dat. In ieder geval is het irrelevant.

CyBeR schreef op zaterdag 10 oktober 2009 @ 18:13:
Python launchen alleen al duurt 0.026 seconden, en dat is dan zonder iets te doen (python -c exit).

Dat is dan ook een onhandige manier van Python gebruiken. Je hebt dan juist geen shell wrapper meer nodig.

5250 seconden extra, dus, om python alleen maar op te starten. Dat is overhead die nergens voor nodig is.

Dat is een overhead die niets uitmaakt, als je wel Python kent en geen C.

[ Voor 10% gewijzigd door Confusion op 10-10-2009 18:37 ]

[Henk007]

Ik vermoed dat file I/O hier de bottleneck is en niet de compiler, CPU e.d.
Uiteraard afhankelijk van verdere parameters.

[CyBeR]

Confusion schreef op zaterdag 10 oktober 2009 @ 18:34:
[...]

Ik had een voorbeeld met realistischere waarden moeten geven. Nu durf ik niet meer te gokken, dus heb ik het maar even gebenched voor 10K bestanden. Met de C code van GraveR:

ivo@twen:~/tmp/tmp$ time (for i in `seq 1 10000`; do ./a.out foo$i; done)

real 0m58.423s
user 0m11.405s
sys 0m15.317s


Met equivalente python code:

ivo@twen:~/tmp/tmp$ time (for i in `seq 1 10000`; do ./changebytes.py foo$i; done)

real 5m5.408s
user 3m16.028s
sys 1m17.357s

een stuk langer, maar ook een onhandige manier van Python gebruiken. Ben je zo handig om de lus in het Python script te stoppen, dan is het
ivo@twen:~/tmp/tmp$ time ./changebytes.py

real 0m0.543s
user 0m0.252s
sys 0m0.284s

en ik betwijfel of de C code die hetzelfde doet veel sneller is dan dat. In ieder geval is het irrelevant.

Ten eerste lijkt 't me heel sterk dat je 10000 files weet te modificeren in een halve seconde. Ik heb de C versie aangepast en die doet er 9 seconden over.

Ten tweede: dat is heel relevant. Als python er langer over doet en je hebt honderd of wat files te doen, neem python als je dat makkelijker vindt. Heb je er 250.000 dan gaat elk beetje extra performance opeens heel veel uitmaken.

Dat is dan ook een onhandige manier van Python gebruiken. Je hebt dan juist geen shell wrapper meer nodig.

Huh? Want in C kun je geen directories doorlopen en in python wel?

Dat is een overhead die niets uitmaakt, als je wel Python kent en geen C.

Als je geen python kent maar wel perl ben je evengoed fucked met python of C. Talenkennis is een heel ander iets.

[Confusion]

CyBeR schreef op zaterdag 10 oktober 2009 @ 18:56:
Ten eerste lijkt 't me heel sterk dat je 10000 files weet te modificeren in een halve seconde. Ik heb de C versie aangepast en die doet er 9 seconden over.

Nou, ik heb hem nog een paar keer gedraaid, maar het varieert tussen de 0.5 en de 4 seconden op mijn oude bakkie; er wordt ook nog een torrent gedownload, dus het is niet zo stabiel.

code:

#!/usr/bin/python

for i in xrange(1,10000):
  f = open("foo"+str(i), 'r+b')
  f.seek(22)
  f.write("abcd")
  f.close()

Ten tweede: dat is heel relevant. Als python er langer over doet en je hebt honderd of wat files te doen, neem python als je dat makkelijker vindt. Heb je er 250.000 dan gaat elk beetje extra performance opeens heel veel uitmaken.

Nee, want we hebben het het nu over een verschil in de orde van seconden voor 250K bestanden. Dat boeit niet.

Huh? Want in C kun je geen directories doorlopen en in python wel?

Nou, ik heb net mijn best gedaan om de C code te modificeren, zodat'ie dat doet, maar ik spreek geen C en het is me vooralsnog alleen maar gelukt een segfaultend programma te krijgen . Anyway: natuurlijk kan het, maar 99 van de 100 mensen zullen het in Python makkelijker vinden.

Als je geen python kent maar wel perl ben je evengoed fucked met python of C. Talenkennis is een heel ander iets.

Ook in Perl of Php (of Java) is dit in korte tijd te implementeren en kan het in korte tijd gedraaid worden. Hier C voor aanbevelen als enige geschikte keuze is onzinnig en aangezien ik dacht dat Free!!!! dat deed, leek het me zinnig even toe te voegen dat het ook zonder problemen in andere talen kan.

[ Voor 3% gewijzigd door Confusion op 10-10-2009 19:09 ]

[CyBeR]

[quote]Confusion schreef op zaterdag 10 oktober 2009 @ 19:07:
[...]

Nou, ik heb hem nog een paar keer gedraaid, maar het varieert tussen de 0.5 en de 4 seconden op mijn oude bakkie; er wordt ook nog een torrent gedownload, dus het is niet zo stabiel.

code:

#!/usr/bin/python

for i in xrange(1,10000):
  f = open("foo"+str(i), 'r+b')
  f.seek(22)
  f.write("abcd")
  f.close()

Hm, dan is jouw bak veel sneller dan de mijne (Core 2 duo 2.66) want die doet er minimaal 8 seconden over, ongeacht of ik jouw python script draai of mij C programma Toegegeven op het moment dat je de loop in het programma zelf doet mis je de overhead en is er weinig tot geen performanceverschil in C versus python (versus perl versus java, etc.).

Nou, ik heb net mijn best gedaan om de C code te modificeren, zodat'ie dat doet, maar ik spreek geen C en het is me vooralsnog alleen maar gelukt een segfaultend programma te krijgen . Anyway: natuurlijk kan het, maar 99 van de 100 mensen zullen het in Python makkelijker vinden.

Ik zal die 100e wel zijn dan, want ik vind python over 't algemeen maar onbegrijpelijke meuk

Ook in Perl of Php (of Java) is dit in korte tijd te implementeren en kan het in korte tijd gedraaid worden. Hier C voor aanbevelen als enige geschikte keuze is onzinnig en aangezien ik dacht dat Free!!!! dat deed, leek het me zinnig even toe te voegen dat het ook zonder problemen in andere talen kan.

Niemand zei dat C de enige optie was. Zoiets simpels als een file modificeren kun je in brainfuck of shakespeare nog in betrekkelijk weinig tijd maken.

[Confusion]

CyBeR schreef op zaterdag 10 oktober 2009 @ 19:19:
Hm, dan is jouw bak veel sneller dan de mijne (Core 2 duo 2.66)

Vreemd, dit is een Athlon XP 2400 (2 GHz). Waarschijnlijk heb je ook een SATA schijf? Ik zit nog op ATA100 hier. Ik weet niet hoe groot jouw testbestanden zijn; ik heb ze 175kB per stuk gemaakt, misschien dat dat uitmaakt?

edit:
C implementatie deed er bij mij net (er maar eens een tutorial bijgezocht; ik kon het me echt niet meer goed herinneren ) de eerste keer 53 s. over, maar sindsdien telkens ~400ms. Iets met filesystem caching?

[ Voor 21% gewijzigd door Confusion op 11-10-2009 00:13 ]

[Freee!!]

CyBeR schreef op zaterdag 10 oktober 2009 @ 19:19:
Niemand zei dat C de enige optie was. Zoiets simpels als een file modificeren kun je in brainfuck of shakespeare nog in betrekkelijk weinig tijd maken.

Vind je het heel erg als ik even geen zin heb om Brainfuck te leren

Maar ondertussen raken we wel geheel off-topic. Niet dat dat zo erg is, volgens mij is de TS ondertussen klaar met het aanpassen van die bestanden

[MartinMeijerink]

In bash kan het heel simpel als volgt:

code:

echo '0e: 00 5c 00 5c' | xxd -r - plaatje.jpg

of als je de jpg's verdeeld over een heleboel mappen en submappen hebt, dan kun je vanaf de hoofdmap het volgende doen:

code:

find ./ -iname '*.jpg'|while read;do echo '0e: 00 5c 00 5c' | xxd -r - "$REPLY";done

Zo doe je alle jpg's in 1 keer!
En dit gaat ook heel snel, aangezien niet elke keer het complete jpg-bestand wordt geopend en opgeslagen, maar het verandert alleen die paar bytes die veranderd moeten worden!

[Wolfboy]

CyBeR schreef op zaterdag 10 oktober 2009 @ 19:19:
Ik zal die 100e wel zijn dan, want ik vind python over 't algemeen maar onbegrijpelijke meuk

Echt waar?

Python is bijna pseudocode, ik kan het in veel gevallen zelfs door volledige computern00bs laten lezen omdat het voor een groot gedeelte gewoon Engels is.


@MartinMeijerink: elke fatsoenlijke implementatie zal niet het hele bestand inlezen maar gewoon een open, seek, write, close doen

Maar dat is wel een zeer eenvoudige optie, die moet ik zeker onthouden voor het geval ik ooit zoiets heb.

[Verwijderd]

Freee!! schreef op zaterdag 10 oktober 2009 @ 15:38:
[...]
Ik schat zo in dat het met een goed C programmaatje minder dan 0,1 seconde duurt in plaats van die seconde per bestand.

Luitjes,

Ik heb de voorbeeldcode van GraveR inmiddels uitgewerkt met wat extra controles en zo. Het aanpassen van 250.000 files gaat als een speer.

Ik wil als laatste iedereen die aan de discussie meegedaan heeft bedanken voor hun input. Kom eens een keer langs als de nieuwe expositieruimte van het Liemers Museum klaar is

Zie ook: www.liemersmuseum.nl

THANKS Aad Slingerland

[Verwijderd]

Verwijderd schreef op zaterdag 10 oktober 2009 @ 23:36:
Ik heb de voorbeeldcode van GraveR inmiddels uitgewerkt met wat extra controles en zo

En hier is de source code

C:

/*
  setjpegres.c       Aad Slingerland, Zevenaar, The Netherlands, october 2009.

  A small utility to change the resolution of a JPEG file. The new resolution
  must be specified as the first parameter on the command line in the format
  horizontal*vertical. The second parameter is the file to act on.

  I implemented some checks to prevent non-JPEG files from beeing patched and
  also limited checks on the values specfied for horizontal and vertical. 

  A discussion on the forum of tweakers.net was the basis for this program. 
  See also http://gathering.tweakers.net/forum/list_messages/1372673

  Thanks to GraveR for supplying sample code to give my rusty C knowledge a
  quick restart.

  Compile for Windows with VS 2008:   cl setjpegres.c

  Compile for Linux with gcc:         gcc setjpegres.c -o setjpegres

  This code is donated to the community as is. No warrenties. No garanties.
*/  
#include <stdio.h>
#include <stdlib.h>

void Usage ()
{
  printf ("\nUsage  : setjpegres <horizontal*vertical> <filename>\n");
  printf ("Sample : setjpegres 92*92 this.jpg\n\n");
  exit (EXIT_FAILURE);
}

int main(int argc, char** argv)
{
  char  *argv_1_star;                    
  int   argv_1_length;
  char  *argv_1_horizontal;
  char  *argv_1_vertical;
  short horizontal;
  short vertical;
  char  signature[8];
  short *p;
  char  flipflop[2];
  char  patch[] = {0x01,0x00,0x5C,0x00,0x5C,0x00,0x00,0x00,0x00};
  FILE  *f;
  /*
    minimum argument count check.
  */
  if (argc < 3) Usage ();             
  /*
    minimum length of argv[1] check and argv[1] must contain a *.
  */
  argv_1_star   = strchr (argv[1], '*');
  argv_1_length = strlen (argv[1]);
  if (argv_1_star == 0 || argv_1_length < 3) Usage ();
  /*
    isolate the part before the * and after the *.
    both parts should contain something.
  */
  argv_1_horizontal = argv[1];
  argv_1_vertical   = argv_1_star + 1;
  *argv_1_star = 0;
  if (strlen (argv_1_horizontal) == 0 
  ||  strlen (argv_1_vertical)   == 0) Usage ();
  /*
    covert to ints and patch the patch array in rather clunky way because
    the in memory byte order of a short is the opposite of the byte order
    used in a JPEG header. 
  */
  horizontal = atoi (argv_1_horizontal);
  vertical   = atoi (argv_1_vertical);
  p = & flipflop;
  //
  *p = horizontal;
  patch[1] = flipflop[1];
  patch[2] = flipflop[0];
  //
  *p = vertical;
  patch[3] = flipflop[1];
  patch[4] = flipflop[0];
  /*
    open the file and check the JPEG signature.
  */
  if (f = fopen (argv[2], "r+"))
  {
    fseek (f, 6, SEEK_SET);
    fread (signature, 1, 5, f);
    if (strncmp (signature, "JFIF", 5))
    {
      fclose (f);
      printf("This is not a JPEG file: %s\n", argv[2]);
      exit (EXIT_FAILURE);
    }
    /*
      patch the file now...
    */
    fseek (f, 13, SEEK_SET);
    fwrite (patch, 1, 5, f);
    fclose (f);
  }
  else
  {
    printf("Could not open file: %s\n", argv[2]);
    exit (EXIT_FAILURE);
  }
  return (EXIT_SUCCESS);
}

[Freee!!]

Blij dat het je gelukt is.