DATA transfer via JPG

User avatar
rbytes
Posts: 1417
Joined: Sun May 31, 2015 12:11 am
My devices: iPhone 6
iPad 2
Dell Inspiron laptop
Location: Canada
Flag: Canada
Contact:

Re: DATA transfer via JPG

Post by rbytes » Sat Aug 05, 2017 2:02 am

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.
####### Living the colorful life #######

User avatar
Dutchman
Posts: 748
Joined: Mon May 06, 2013 9:21 am
My devices: iMac, iPad Air, iPhone
Location: Netherlands
Flag: Netherlands

Re: DATA transfer via JPG

Post by Dutchman » Sun Aug 06, 2017 10:28 am

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"
We consider it a refreshing mental exercise to figure out ways to circumvent foolishness (Quote from Richard)

User avatar
rbytes
Posts: 1417
Joined: Sun May 31, 2015 12:11 am
My devices: iPhone 6
iPad 2
Dell Inspiron laptop
Location: Canada
Flag: Canada
Contact:

Re: DATA transfer via JPG

Post by rbytes » Wed Aug 09, 2017 5:11 am

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.
####### Living the colorful life #######

User avatar
Mr. Kibernetik
Site Admin
Posts: 4286
Joined: Mon Nov 19, 2012 10:16 pm
My devices: iPad, iPhone, MacBook
Location: Russia
Flag: Russia

Re: DATA transfer via JPG

Post by Mr. Kibernetik » Wed Aug 09, 2017 7:42 am

rbytes wrote:
Wed Aug 09, 2017 5:11 am
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

User avatar
Dutchman
Posts: 748
Joined: Mon May 06, 2013 9:21 am
My devices: iMac, iPad Air, iPhone
Location: Netherlands
Flag: Netherlands

Re: DATA transfer via JPG

Post by Dutchman » Wed Aug 09, 2017 8:15 am

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.
We consider it a refreshing mental exercise to figure out ways to circumvent foolishness (Quote from Richard)

User avatar
rbytes
Posts: 1417
Joined: Sun May 31, 2015 12:11 am
My devices: iPhone 6
iPad 2
Dell Inspiron laptop
Location: Canada
Flag: Canada
Contact:

Re: DATA transfer via JPG

Post by rbytes » Wed Aug 09, 2017 1:50 pm

Thanks for the responses! :D
####### Living the colorful life #######

User avatar
Dutchman
Posts: 748
Joined: Mon May 06, 2013 9:21 am
My devices: iMac, iPad Air, iPhone
Location: Netherlands
Flag: Netherlands

Re: DATA transfer via JPG

Post by Dutchman » Sat Aug 12, 2017 1:54 pm

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.
We consider it a refreshing mental exercise to figure out ways to circumvent foolishness (Quote from Richard)

User avatar
rbytes
Posts: 1417
Joined: Sun May 31, 2015 12:11 am
My devices: iPhone 6
iPad 2
Dell Inspiron laptop
Location: Canada
Flag: Canada
Contact:

Re: DATA transfer via JPG

Post by rbytes » Sat Aug 12, 2017 2:31 pm

Glad to hear that you will be continuing development of this technique. I'm looking forward to the multiple- file version. 8-)
####### Living the colorful life #######

User avatar
Henko
Posts: 621
Joined: Tue Apr 09, 2013 12:23 pm
My devices: iPhone 5S, iPad air 2, Windows PC's
Location: Netherlands
Flag: Netherlands

Re: DATA transfer via JPG

Post by Henko » Sun Aug 13, 2017 7:05 am

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

User avatar
Dutchman
Posts: 748
Joined: Mon May 06, 2013 9:21 am
My devices: iMac, iPad Air, iPhone
Location: Netherlands
Flag: Netherlands

Re: DATA transfer via JPG

Post by Dutchman » Sun Aug 13, 2017 8:37 am

A simpler approach is to use the commands GUNZIP Z$ TO F$ and GZIP F$ TO Z$
We consider it a refreshing mental exercise to figure out ways to circumvent foolishness (Quote from Richard)

Post Reply