DATA_viaJPG for multiple files

[rbytes]

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!

7769AE31-FC86-4C10-8E62-76015DA7B5C4.png (1.49 MiB) Viewed 4196 times

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.

[rbytes]

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.

[GeorgeMcGinn]

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.

Hi, the link gets a message that says it no longer exists.

Can you provide another one?

The 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

[Dutchman]

…
I still get the link does not exist message from Dropbox. If all the files are zipped, can you email them to me?
…

The link to DATA_viaJPG in your quote indeed does not work.
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]

…
To me this suggests that when the JPGs are exported and imported the data added after the EOF marker is being stripped off.
…

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]

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.

[Dutchman]

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.

[Dutchman]

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".

setting photo-transfer.PNG (32.51 KiB) Viewed 4112 times

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]

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.

[rbytes]

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

BAA4DFB6-E84F-456A-A5F5-BBAC8376459A.jpeg (76.85 KiB) Viewed 4100 times

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.