[Delphi] JPEG inlezen, alle regels inversen, terugschrijven

[Verwijderd]

Euj iedereen...

Ik heb misschien een wat ongewone vraag. Ik wil een JPG-bestand inlezen, elke regel omkeren (ReverseString) en dan weer terugschrijven. De volgende code heb ik getest op een gewoon tekstbestand met drie regels, en dat werkt. Maar als ik als input een JPG bestand geef, dan werkt het niet (het bestand wordt dan opeens 500kb --> 20 kb ofzo). De code:

code:

procedure edit_file(filename: string);
var
  F1, F2: TextFile;
  currentline: string;

begin
     if fileexists(filename) = true then begin
        AssignFile(F1,filename);
        Reset(F1);
        if fileexists(filename + '.bak') then
                 deletefile(filename + '.bak');

        AssignFile(F2,filename + '.bak');
        ReWrite(F2);

        while not Eof(F1) do begin
              readln(F1,currentline);
              currentline := reversestring(currentline);
              writeln(F2,currentline);
              currentline := '';
        end;
        CloseFile(F1);
        CloseFile(F2);
        DeleteFile(filename);
        renamefile(filename + '.bak',filename);
     end;
end;

Nogmaals, met een gewoon tekstbestand gaat het helemaal goed:

blaat
blaat
blaat

wordt:

taalb
taalb
taalb

Wat doe ik fout? Of kan dit makkelijker?

[Verwijderd]

ik weet niet of de functie readln wel correct werkt op een binairy file ??

[Verwijderd]

Wat zou een alternatief voor readln kunnen zijn?

[Verwijderd]

wat is eigenlijk de bedoeling, dat je de jpg achteraf nog kunt inlezen, of is het gewoon een manier om iets te coderen of zo. Want een jpg heeft ook een header ... om nog maar te zwijgen over de body, die niet een verzameling recht toe recht aan van kleuren is zoals een BMP.

Anders moet je het maar byte per byte in een buffer inlezen ( read(F1,aByte) )en deze achteraf dan omgekeerd wegschrijven. JPG is wel niet meer leesbaar als picture natuurlijk.

[ Voor 50% gewijzigd door Verwijderd op 28-01-2003 17:36 ]

[Verwijderd]

En dat is nou juist de bedoeling! Hij mag niet meer leesbaar zijn (ivm copyright). Ik zorg dat alleen mijn programma ze nog kan showen. Maargoed, kun je uitleggen hoe ik dat zij kunnen doen met read(F, aByte). Ik heb dat al eens geprobeerd, alleen hoe schrijf ik eht dan weer omgekeerd weg?

[DaCoTa]

Ik twijfel om je een betere methode uit te leggen of je te wijzen op de policy van dit board. Om eerst die tweede maar uit te proberen: is de copyright van jezelf en wil je die beschermen of gaat het om copyright van een ander wat eigenlijk niet gebruikt mag worden? In het eerste geval: als je ze alsnog op het scherm wilt zetten, moet je ook tegengaan dat mensen screenshots maken, anders is het voor niks...

Om je niet helemaal in donkere bos in te sturen: onderzoek eens iets met een encrypted archive library, zoals ZIP oid. Als je daar een lang genoeg password voor kiest, kun je het ze vrij lastig maken. Dan hoef je alleen nog maar een manier te verzinnen om het password encrypted ergens in je applicatie op te slaan...

[Coltrui]

Het type String kan - als ik me niet vergis - maximum 255 karakters bevatten. Kijk eens of er lijnen zijn die langer zijn in notepad?
(Zet wel automatische terugloop af...)

[Verwijderd]

Het zijn foto's door mij gemaakt, en ze worden op een CD-tje per 200 foto's verspreidt. Een screenshot maken mag (200 screenshots maken is toch niet aantrekkelijk), het is zelfs zo dat ze foto's kunnen opslaan. Het gaat mij er echter om dat er niet een jochie mijn CD koopt voor drie euro, en 'm daarna voor twee gaat kopieren! Er zit al een copyprotection op (niet ingewikkeld, maar moeilijk zat voor de doorsnee gebruiker) maar ik wil voorkomen dat ze alsnog de foto's gaan kopieren en plakken.
Een encrypted archive library kan, maar ik dacht dat dat een stuk ingewikkelder zou worden. Het hoeft niet 100% waterdicht te zijn, een file 'omdraaien' vind ik al genoeg. Zou je me dat alsnog uit kunnen leggen?

[FendtVario]

Wezen schreef op 28 January 2003 @ 18:14:
Het type String kan - als ik me niet vergis - maximum 255 karakters bevatten. Kijk eens of er lijnen zijn die langer zijn in notepad?
(Zet wel automatische terugloop af...)

mag het misschien een onsje meer wezen?

code:

ShortString 255 characters          2 to 256 bytes
AnsiString  ~2^31 characters    4 bytes to 2GB  
WideString  ~2^30 characters    4 bytes to 2GB

Normaal als je een string declareert wordt een AnsiString gebruikt.

[Coltrui]

Mag ik mij dan hierbij verontschuldigen?
(Ik heb ook diezelfde tekst in de Delphi help-files gevonden, maar heb zoals gewoonlijk weer niet verder gekeken dan mijn neus lang was )

[nightowl]

Ik weet het niet zeker maar volgens mij kun je hier geen filetype : TextFile voor gebruiken. Heb je geprobeerd een andere filetype te gebruiken? TextFile is namelijk gebaseerd op ASCII code en niet op bytes/binair.

[Verwijderd]

Het is al weer een tijdje geleden voor mij, maar volgens mij kun je hier beter met datastreams werken

[Verwijderd]

Ehm... Waar kan ik een lijst met filetypes vinden? Dat TextFile heb ik ergens hier op het forum opgedaan, maar ik kan nergens (google/search/help) een andere type vinden!

[Verwijderd]

Verwijderd schreef op 28 January 2003 @ 18:38:
Het is al weer een tijdje geleden voor mij, maar volgens mij kun je hier beter met datastreams werken

Leg uit. Ik ben namelijk nog een ietsiepietsie newbie!

[lordsnow]

Ipv Readln te gebruiken kan je de file toch gewoon openen, en er dan doorheen "stappen" met brokken van 256 byte of zo, en elke brok 'omkeren'?

Of alleen de eerste 256 bytes van elke JPEG. Dan is de header ook wel zo verne*kt denk ik dat 'ie normaal niet meer af te beelden is.

[FendtVario]

lordsnow schreef op 28 January 2003 @ 18:51:
Ipv Readln te gebruiken kan je de file toch gewoon openen, en er dan doorheen "stappen" met brokken van 256 byte of zo, en elke brok 'omkeren'?

Maar als je steeks blokken van 256 bytes omkeert kom je vast niet goed uit aan het eind. Als een JPEG 1896 byte is heb je 7 blokken en een beetje. Je zou dan ook nog ergens moeten bijhouden wat het aantal resterende bytes is. Niet handig.

[Verwijderd]

zucht... waarom doe je dit hele gepruts niet gewoon met een stream?

stuk eenvoudiger en 'regels' (zoals bij een text typed file) gaan bij een binary file niet op...

btw, als je een stream onleesbaar wilt maken (en nog lekker snel ook, XOR gewoon de hele buffer met een leuk getal)

afijn, suc6

[Verwijderd]

Kan ik dan weer wel met die TextFile werken? Ik begin het onderhand een beetje kwijt te raken. Het kan toch nooit extreem lastig zijn om een file op z'n kop te zetten ?

[Verwijderd]

Met streams is dit inderdaad het beste op te lossen. Ik heb even een korte procedure geschreven om een willekeurige afgeleide van TStream (dus TFileStream, TStringStream, etc.) om te keren. Dat gaat als volgt:

code:

procedure invertStream(inStream: TFileStream; outStream: TFileStream);
var
  charCount: Integer;
  bufferData: String;
begin
  for charCount := (inStream.Size - 1) downto 0  do
  begin
    bufferData := ' ';
    inStream.Seek(charCount,0);
    inStream.Read(bufferData[1],1);
    outStream.Write(bufferData[1],1);
  end;
end;

Je kunt de TFileStream types zelf vervangen door andere types.. je kunt hem bijvoorbeeld de data weg laten schrijven naar een TMemoryStream, en die dan vervolgens direct laden in je bitmap, volgens mij is dat mogelijk.

[chris]

FendtVario schreef op 28 januari 2003 @ 18:59:
[...]


Maar als je steeks blokken van 256 bytes omkeert kom je vast niet goed uit aan het eind. Als een JPEG 1896 byte is heb je 7 blokken en een beetje. Je zou dan ook nog ergens moeten bijhouden wat het aantal resterende bytes is. Niet handig.

hoezo moet je dat bijhouden dan? je kan toch vanaf het begin die blokken omdraaien en vervolgens kom je weer niet goed uit aan het eind. Dan draai je dat toch weer om? correct me if i'm wrong....

[Verwijderd]

Verwijderd schreef op 28 januari 2003 @ 19:15:
Met streams is dit inderdaad het beste op te lossen. Ik heb even een korte procedure geschreven om een willekeurige afgeleide van TStream (dus TFileStream, TStringStream, etc.) om te keren. Dat gaat als volgt:

code:

procedure invertStream(inStream: TFileStream; outStream: TFileStream);
var
  charCount: Integer;
  bufferData: String;
begin
  for charCount := (inStream.Size - 1) downto 0  do
  begin
    bufferData := ' ';
    inStream.Seek(charCount,0);
    inStream.Read(bufferData[1],1);
    outStream.Write(bufferData[1],1);
  end;
end;

Je kunt de TFileStream types zelf vervangen door andere types.. je kunt hem bijvoorbeeld de data weg laten schrijven naar een TMemoryStream, en die dan vervolgens direct laden in je bitmap, volgens mij is dat mogelijk.

Nou, ik moet zeggen dat ik er niet veel van snap, maar ik neem het maar gewoon zo over, en kijk wel of het werkt tnx!

[Verwijderd]

_JWB_: het werkt niet! Ik heb nu dit gedaan:

code:

InStream := TFileStream.Create(filename, fmCreate or fmOpenWrite);
Outstream := TfileStream.Create(filename + '.bak', fmCreate or fmOpenWrite);
invertstream(instream,outstream);
InStream.Free;
Outstream.Free;

En nu hou ik uiteindelijk een leeg bestand over! Hellup!

deletefile(filename);
renamefile(filename + '.bak',filename);

[Brothar]

Je opent een file om te gaan schrijven.
Dan moet je het ook weer sluiten. Waarschijnlijk zet pascal / Delphi met 'close' pas een EOF-character. (NB ik herken dit van Pascal; heb vroeger eens hetzelfde gehad. oplossing: closefile).

[Verwijderd]

Volgensmij gebeurt dat door

code:

instream.free
outstreem.free

[Verwijderd]

Laat maar, ik ben dom geweest. Ik had de instream op create en readwrite staan, en de oustream alleen op read... moest natuurlijk andersom! Alles werkt nu. Tnx jongens!

[FendtVario]

/dev/null schreef op 28 januari 2003 @ 19:21:
[...]

hoezo moet je dat bijhouden dan? je kan toch vanaf het begin die blokken omdraaien en vervolgens kom je weer niet goed uit aan het eind. Dan draai je dat toch weer om? correct me if i'm wrong....

Dat ligt eraan hoe je met het laatste blok omgaat. Je zou het er natuurlijk achteraan kunnen plakken en niets mee doen, dan hoeft het inderdaad niet.

[Verwijderd]

Misschien een beetje laat, maar is het niet een mooiere optie om je jpegjes op te slaan als blob in een-of-andere db? Op die manier krijg je op je CD maar 2 bestanden, de applicatie en een bestand waar alle jpegjes inzitten. Je beveiliging is dan zo goed als de gekozen database, en dat is vaak beter en uitgebreider dan gewoon een bestandje omkeren..

(daarnaast wordt het maken van je app. dan een stuk makkelijker, kun je bv. gewoon dbgrids gebruiken etc.)

[DaCoTa]

PING hezik wint de prijs. Lijkt me inderdaad een stuk handiger, alleen even kijken naar welke database en welke beveiliging er gebruikt wordt. De obfuscation van een bestand is nml. niet echt een sterke beveiliging, en xor met een vast getal nog veeel minder...

[Just_a_Gamer]

Volgens mij als je blobs gebruikt bij een database wordt je database steeds trager naar mate er meer bestanden in komen te staan. Alhoewel Jpeg sterke compressie heeft kan je toch niet voorkomen dat gebruikers belachelijke JPeg bestanden van 20 mb erin gooien bv (extreem voorbeeld).