I did a further test by copying the DATA_JPG folder from my iPhone X to Dropbox and then to my iPad in the correct location. When I run DATA_viaJPG on the 3 JPGs, the data is still missing!
To me this suggests that when the JPGs are exported and imported the data added after the EOF marker is being stripped off. If true, we won't be able to use JPGs to move data between devices that way.
It would still be possible to encode the data within the images themselves, as I do in my list program Listful.sb
That data does travel successfully between devices using EXPORT and IMPORT commands.
DATA_viaJPG for multiple files
- rbytes
- Posts: 1338
- Joined: Sun May 31, 2015 12:11 am
- My devices: iPhone 11 Pro Max
iPad Pro 11
MacBook
Dell Inspiron laptop
CHUWI Plus 10 convertible Windows/Android tablet - Location: Calgary, Canada
- Flag:
- Contact:
Re: DATA_viaJPG for multiple files
The only thing that gets me down is gravity...
- rbytes
- Posts: 1338
- Joined: Sun May 31, 2015 12:11 am
- My devices: iPhone 11 Pro Max
iPad Pro 11
MacBook
Dell Inspiron laptop
CHUWI Plus 10 convertible Windows/Android tablet - Location: Calgary, Canada
- Flag:
- Contact:
Re: DATA_viaJPG for multiple files
My final test confirms that data is being stripped from the JPGs at some point between EXPORT and IMPORT. I copied my DATA_JPG folder to Dropbox and from there to my iPhone. Now the MakeInstall files can be successfully extracted from the JPGs.
The only thing that gets me down is gravity...
- GeorgeMcGinn
- Posts: 435
- Joined: Sat Sep 10, 2016 6:37 am
- My devices: IPad Pro 10.5in
IMac
Linux i386
Windows 7 & 10 - Location: Venice, FL
- Flag:
- Contact:
Re: DATA_viaJPG for multiple files
Sorry for the late response, but I have 2 weeks before my lease expires, and with my back and needed hip fusion, I get fevers due to severe inflammation wheeverI try to do anything. I have hired a moving company to pack, load, drive the truck 397 feet and unload, but I've been trying to at least create piles to make it easy for the packers and throw out what I don't want to take with me. I'm having a very difficult time lately.
I still get the link does not exist message from Dropbox. If all the files are zipped, can you email them to me?
gjmcginn@icloud.com.
I still get the link does not exist message from Dropbox. If all the files are zipped, can you email them to me?
gjmcginn@icloud.com.
GeorgeMcGinn wrote: ↑Tue Aug 15, 2017 8:30 amHi, the link gets a message that says it no longer exists.
Can you provide another one?
Dutchman wrote: ↑Sun Aug 13, 2017 2:51 pmThe functions for transfer of data via JPG-files from viewtopic.php?f=20&t=1888 have been extended with find and select functions in order to simplify handling of multiple files.
Programs and function libs are collected in the folder DATA_viaJPG.
The folder DATA_viaJPG can be downloaded from https://www.dropbox.com/sh/b5e4vk9eo8mh ... LgjUa?dl=0
The find and select functions originate from viewtopic.php?f=20&t=1530 with a specific function for the buttons.
After selection of multiple files the button "Done" will start the process.
The process is logged to the screen and to the file "processed.info'.
screenshots.PNG
George McGinn
Computer Scientist/Cosmologist/Writer/Photographer
Member: IEEE, IEEE Computer Society
IEEE Sensors Council & IoT Technical Community
American Association for the Advancement of Science (AAAS)
Computer Scientist/Cosmologist/Writer/Photographer
Member: IEEE, IEEE Computer Society
IEEE Sensors Council & IoT Technical Community
American Association for the Advancement of Science (AAAS)
- Dutchman
- Posts: 851
- Joined: Mon May 06, 2013 9:21 am
- My devices: iMac, iPad Air, iPhone
- Location: Netherlands
- Flag:
Re: DATA_viaJPG for multiple files
The link to DATA_viaJPG in your quote indeed does not work.GeorgeMcGinn wrote: ↑Tue Jul 17, 2018 9:25 am…
I still get the link does not exist message from Dropbox. If all the files are zipped, can you email them to me?
…
The original link in my initial post of 12 aug 2017 however is correct: https://www.dropbox.com/sh/vkzgbjq4johu ... jfusa?dl=0
Probably it is corrupted by quoting.
I will send it to you by mail.
- Dutchman
- Posts: 851
- Joined: Mon May 06, 2013 9:21 am
- My devices: iMac, iPad Air, iPhone
- Location: Netherlands
- Flag:
Re: DATA_viaJPG for multiple files
The DATA is added after the EOI (End Of Image) marker. The EOF (End Of File) marker is after the DATA.
So somewhere the file is corrupted before its end.
Probably we should find or create a space before the EOI marker
- rbytes
- Posts: 1338
- Joined: Sun May 31, 2015 12:11 am
- My devices: iPhone 11 Pro Max
iPad Pro 11
MacBook
Dell Inspiron laptop
CHUWI Plus 10 convertible Windows/Android tablet - Location: Calgary, Canada
- Flag:
- Contact:
Re: DATA_viaJPG for multiple files
Thanks, Ton. I hope you will experiment with this and see if you can move the data before the EOI marker. In that case, though, wouldn't it add garbage pixels to the image? Maybe that wouldn't matter if it is a full-screen image, because those pixels would be off-screen (I think].
I will be happy to test it.
I will be happy to test it.
The only thing that gets me down is gravity...
- Dutchman
- Posts: 851
- Joined: Mon May 06, 2013 9:21 am
- My devices: iMac, iPad Air, iPhone
- Location: Netherlands
- Flag:
Re: DATA_viaJPG for multiple files
JPEG has a COM (comment) marker (HEX 'FFFE') in the image part. But then you have to divide the data into 64kb chunks.
See https://en.wikipedia.org/wiki/JPEG
I am now unable to pay more attention to it. Perhaps in the near future.
See https://en.wikipedia.org/wiki/JPEG
I am now unable to pay more attention to it. Perhaps in the near future.
- Dutchman
- Posts: 851
- Joined: Mon May 06, 2013 9:21 am
- My devices: iMac, iPad Air, iPhone
- Location: Netherlands
- Flag:
Re: DATA_viaJPG for multiple files
I have created a variant in which the data is stored within the description of the image in COM (comment) segment(s). So the data is stored before the EOI marker. See the extension under 20180723 of my first post in this thread.
I assumed that this would solve the problem. But unfortunately it turned out differently. This data is also stripped. It even appears that the Exif data is also being changed. For example, the resolution is changed from 144dpi to 72dpi.
Initially I thought I could solve it by changing an adjustment in the Photo app: "TRANSFER TO MAC OR PC" changed from "Automatic" to "Keep Originals". But that proved to be no solution.
Eventually I found information on the internet that the app that delivers the photo to the library is responsible for whether or not the photo is stripped. Therefore, I can only conclude that the problem AND the solution must be found in SB.
If that is the case, then in a new version of SB that is adapted to it, data transfer should be possible in this way.
Then I wonder if Mr. K. wants and can investigate this.
I assumed that this would solve the problem. But unfortunately it turned out differently. This data is also stripped. It even appears that the Exif data is also being changed. For example, the resolution is changed from 144dpi to 72dpi.
Initially I thought I could solve it by changing an adjustment in the Photo app: "TRANSFER TO MAC OR PC" changed from "Automatic" to "Keep Originals". But that proved to be no solution.
Eventually I found information on the internet that the app that delivers the photo to the library is responsible for whether or not the photo is stripped. Therefore, I can only conclude that the problem AND the solution must be found in SB.
If that is the case, then in a new version of SB that is adapted to it, data transfer should be possible in this way.
Then I wonder if Mr. K. wants and can investigate this.
- Mr. Kibernetik
- Site Admin
- Posts: 4786
- Joined: Mon Nov 19, 2012 10:16 pm
- My devices: iPhone, iPad, MacBook
- Location: Russia
- Flag:
Re: DATA_viaJPG for multiple files
Most probably ALBUM IMPORT command recompresses JPG file instead of making a plain copy of the file from the gallery (it uses system import function). So, all extra markers will be wiped out.
I would suggest using non-compressed PNG file format (if it is possible to import PNGs) and encode information inside pixels. Each pixel can keep 4 bytes of information and even recompression will not destroy data.
I would suggest using non-compressed PNG file format (if it is possible to import PNGs) and encode information inside pixels. Each pixel can keep 4 bytes of information and even recompression will not destroy data.
- rbytes
- Posts: 1338
- Joined: Sun May 31, 2015 12:11 am
- My devices: iPhone 11 Pro Max
iPad Pro 11
MacBook
Dell Inspiron laptop
CHUWI Plus 10 convertible Windows/Android tablet - Location: Calgary, Canada
- Flag:
- Contact:
Re: DATA_viaJPG for multiple files
This is a mystery, because I use JPGs to encode data for several of my programs. The data images, such as the one below, are written with bytes in a series of horizontal bands that are 8 pixels tall. Henko came up with the original encoding method and I added the scanning. The data manages to survive not only JPG compression and any processing such as resizing that is done by SB ALBUM EXPORT and ALBUM IMPORT. I can create and read data images on both my iPad and iPhone.
This is my shopping list for today
Once the picture is shared between devices via iCloud, I can load the image and extract the data with no problem. I didn't change any settings on either device in order for this to work. Dutchman, this is a long shot, but maybe try encoding your data into larger images, and making the images either square (like mine, above) or of a 4:3 aspect ratio. Perhaps small or oddly-shaped images are more subject to alteration. Even if you had to encode your data into a full-screen JPG, that would be worth it to get the process to work.
This is my shopping list for today
Once the picture is shared between devices via iCloud, I can load the image and extract the data with no problem. I didn't change any settings on either device in order for this to work. Dutchman, this is a long shot, but maybe try encoding your data into larger images, and making the images either square (like mine, above) or of a 4:3 aspect ratio. Perhaps small or oddly-shaped images are more subject to alteration. Even if you had to encode your data into a full-screen JPG, that would be worth it to get the process to work.
The only thing that gets me down is gravity...