DATA transfer via JPG

[rbytes]

This is developing nicely. Thanks, Ton.

I propose that in the next phase you add a requester for selecting the file to embed. For extracting data, it would be good to be able to choose between an ALBUM IMPORT and a file load of the data jpg. I expect many of these jpgs will be saved directly to the camera roll from a website or email.

Another thought. Would you extend your store and extract routines so that the filename is stored and then extracted from the jpg, in addition to the file data? Otherwise the user will always have to type in the save filename when extracting a file.

[Dutchman]

I have modified the functions and the example-code.
- Name of input-file is extracted from path-name.
- Default-name of extracted file is derived from JPG-Filename.

I will make another example with 'find-select' facilities, therefore I have separated the relevant functions into the library-file "DATA_viaJPG.func"

[rbytes]

I could probably look this up, Ton and Mr. K, but you both seem very well informed about the file structures of jpgs. Would you please explain to me and any others who are wondering - how is it that the sequence of bytes 255 and 217 is never found within the data of a jpg file, but only as the EOF marker? I had always believed that any combination of bytes could occur within an image, depending on its particular pixel arrangement.

I have been wondering about the possibility of encoding multiple files at the end of a jpg. The trick would be to have markers at the end of each, to know how to separate them. It may be that these markers already exist for standard data types such as audio and text files. I am interested to know if an entire game might be encoded into a single jpg, complete with program code, images and sounds that could be extracted at the receiving end.

[Mr. Kibernetik]

I could probably look this up, Ton and Mr. K, but you both seem very well informed about the file structures of jpgs. Would you please explain to me and any others who are wondering - how is it that the sequence of bytes 255 and 217 is never found within the data of a jpg file, but only as the EOF marker? I had always believed that any combination of bytes could occur within an image, depending on its particular pixel arrangement.

Because size of each block is defined. SOI and EOI are just block identifiers.
https://en.wikipedia.org/wiki/JPEG_File ... _structure

[Dutchman]

The code 'FF' is reserved as start of markers and will not be present in the picture data.

Each marker consists of two bytes: an FF byte followed by a byte which is not equal to 00 or FF and specifies the type of the marker.

[rbytes]

Thanks for the responses!

[Dutchman]

I have changed the error-handling.
In the old version the program stopped if an error was detected.
For the program under development, I want to have the facility to process multiple files in one run.
Therefore the error-message is now written into 'DATA_.ErrorMsg$' and 'DATA_.Error' is set to 1 if an error occurs.
The program can then print that message and continu with the next file in the select-list.
The example-program and the function-lib have been updated.
Please note that the function-lib should be placed in the folder "System".
In future it will also contain other system-files for the coming program.

[rbytes]

Glad to hear that you will be continuing development of this technique. I'm looking forward to the multiple- file version.

[Henko]

An option could be added to encrypt the data. Apple cannot detect then if the picture is used to transmit a program. A simple encryption/decryption function follows. By the way, a WAV file could also be used to pack data. When played, the old days of loading from casette will revive .


' This function will encrypt a text-file which must be present
' in the map where the program is started.
' Encryption is done with mode=1, the result is written to the
' output-file and is given back by the function as a string.
' Decryption to readable tekst must be done with mode=-1, and
' of course with the same key. When trying to decrypt with a
' different key, the program may crash, which might be a desirable
' feature in this special case.
' The key may consist of any caracters, but normally it is a easy
' to remember word. Maximum length is 15 letters (change the dim-
' statement if you want more). Preferable lengths are prime numbers
' such as 7 or 13. Best results if all characters in the key are
' different.
' The encrypted text cannot easily be deciphered without the key,
' as any specific letter in the text is replaced by different
' tokens in the encrypted text.
' The input-file must be enclosed in double quotes to ensure that
' the entire file is regarded as one (1) string.
' the function works for either option base 0 or 1
'
def crypt$(file_in$,key$,file_out$,mode)
base=substr$("10",1,1) ' base=option base x
dim key(15)
file file_in$ input in$
lk=len(key$) ! lt=len(in$) ! out$=""
for i=base to lk-1+base ! key(i)=asc(substr$(key$,i,i)) ! next i
for i=base to lt-1+base
out$=out$ & chr$(asc(substr$(in$,i,i))+mode*key(base+mod(i,lk)))
next i
if file_exists(file_out$) then file file_out$ delete
file file_out$ print """" & out$ & """"
crypt$=out$
end def

def mod(a,m)
d=a/m ! mod=m*(d-floor(d))
end def

[Dutchman]

A simpler approach is to use the commands GUNZIP Z$ TO F$ and GZIP F$ TO Z$