The pixel party continues: a booklet printed on one screen

[Henko]

An ascci code consists of 8 bits. One bit can be represented on the screen by one pixel. Hence in 8 vertical pixels we can put one character. On a iPad retina screen we have about 3 million pixels, this means about 375.000 characters. A paperback page can accomodate about 4000 characters. One screen can then contain a booklet of say 80 pages.
The little program hereafter prints a sentence of 43 characters. This sentence is then "pixelized" using the function "draw_num". It's the little smudge under the printed sentence.
After that, the little smudge is converted back into a sentence using the function "get_num".

Code: Select all

graphics ! ss=screen_scale()
a$="This was a very nice summer, that is in NL."
draw text a$ at 20,40
le=len(a$)
for i=0 to le-1
  draw_num(600+i,160,asc(mid$(a$,i,1)))
  next i
for i=0 to le-1
  b$ &= chr$(get_num(600+i,160))
  next i
draw text b$ at 20,100
end

def draw_num(x,y,num)
for i=0 to 7
  if bit(num,i) then draw pixel x,y+i
  next i
end def

def get_num(x,y)
num=0
for i=0 to 7
  get pixel x,y+i color r,g,b
  if r+g+b>2.5 then num+=2^i
  next i
return num
end def

[Henko]

After a little more thinking: using 8 pixels for one ascii character is still an enormous waste of space . One pixel has 4 property values, R,G,B,A, (internally) each from 0-255. That's 4 ascii characters per pixel. Hence there is a "spillage" factor of 32. Roughly 12 million ascii character can be "written" on one iPad retina screen. That's the content of 10 books, or the size of a large private database.
Apart from practical applicability aspects, i will surely make the code to do such a job.

[Henko]

IMG_1282.PNG (877.38 KiB) Viewed 6193 times

A piece of art? No, it's a piece of text, 1.000.000 randomly chosen ccharacters, the size of an average book.

Code: Select all

graphics
dim cl(5)

for i=1 to 100000
  teksto$ &= chr$(20+rnd(120))
  next i
for i=1 to 10 ! tekst$ &= teksto$ ! next i

lt=len(tekst$)-1 ! xpix=500 ! k=0 ! xo=480 ! x=xo ! y=60
while k<lt
  for i=1 to xpix
    for j=1 to 4
      if k<=lt then cl(j)=asc(mid$(tekst$,k,1))
      k+=1
      next j
    draw_pixel(x,y,cl)
    if k>lt then break
    x+=1
    if x-xo>xpix then ! x=xo ! y+=1 ! end if
    next i
button "1" text k at 10,10 size 100,40
  end while
debug pause
end

' draw a pixel using values 0-255 for r,g,b and alpha in cl(4)
'
def draw_pixel(x,y,cl())
r=cl(1)/255 ! g=cl(2)/255 ! b=cl(3)/255 ! a=cl(4)/255
draw pixel x,y color r,g,b,a
end def

' get pixel values 0-255 for r,g,b,alpha in array cl(1) - cl(4)
'
def get_pixel(x,y,cl())
get pixel x,y color cl(1),cl(2),cl(3),cl(4)
for i=1 to 4 ! cl(i)=floor(cl(i)*255) ! next i
end def

[rbytes]

I think there is great potential for your process, which is like a miniature QR code. I can see immediate uses in encryption and syncing between devices.

I would like to incorporate it into my list program. The way I see it working is:

1. Automatic save of a pixeldata image to the Camera Roll whenever I save a list file. (or optionally, an Export button)
2. On the other device, click an Import button (which I will need to create), and select the pixeldata image from My Photo Stream
3. The synced file opens.

Done!

Compare that to:

1. Close Listful and launch smart BASIC
2. Navigate to My Apps/Listful/Shopping and select the list file I want
3. Copy it
4. Switch to DropBox
5. Paste it

On my other device:

1. Close Listful and launch smart BASIC
2. Switch to Dropbox
3. FInd and copy the list file
4. Switch to sB root folder
5. Navigate to My Apps/Listful/Shopping and paste the list file
6. Launch Listful
7. Click load
8. Navigate to Shopping folder.
9. Select file

There could be an issue trying to identify which pixeldata image I want if I have saved many.
The image below shows how I would resolve that. The image could be made very small, just large enough to hold the maximum required data and the filename printed in a large font so that it can be read from the thumbnail.

In order for me to test this technique, would you please post your most recent version with the code for reading as well as writing data?

Thanks, Henko

[Henko]

Yes, i'll do that tomorrow, and try to find a suitable book (in .txt) instead of generated characters. The version tomorrow will only work with rectangular areas, where the user states the number of horizontal pixels. A next version will have a linked list structure, where the "data" can be scattered over the entire screen.

[Mr. Kibernetik]

Anyway, decoding of this info should be done by software. So, encoding also can be done not for direct human reading. That is, color of a pixel can have its meaning. Each pixel can have 256*256*256 values. So potential amount of encoded info can be very large.

[rbytes]

That will be a very efficient storage method for some applications. I remembered this morning, though, that whenever I save PNG files to the Camera Roll, they are converted to JPEGs before being copied to Photo Stream! That scrambles all of the color values and makes the data unreadable if it depends on color values. I think that Apple has hard-coded the conversion into iOS to save cloud storage space. I don't recall an option to disable it. So the color method could not be used to sync data between devices.

This is not an insurmountable problem. It just means that the data save format can not be as miniaturized as for uncompressed image files. We know that QR Codes are successful, and they are often exchanged as JPGs or JPEGs. What needs to be done is to test how small our individual chunks of information can be made before errors occur when reading data back from a JPEG.

[rbytes]

Here is some code I wrote adapting your datastore program so that it can share data between devices.

When the send variable is set to 1, whatever text you include in a$ will be saved to the Camera Roll as a tiny image.

Copy the program to your other device, set send =0 and run it. You will see an image browser. Your data image should appear in the Moments folder at the top of the image browser. Click on it, the image will load. The data in it will be scanned and the transmitted message will appear in the lower field.

For fun, I substituted emoji for certain designated characters in the message: [ ] and ^

Image 1: what you see on screen when sending
Image 2: what you see on screen when receiving.
Image 3: the data image that carries the message, shown to scale

[rbytes]

Taking it a little further - by scanning rows, I have increased capacity to 18 kbytes
within a 200 x 200 image. At the quality level used by Apple, jpegs have
not caused any errors in reading of data. At higher compression ratios
I would expect errors to appear.

Here is the revised code and the changed screenshots for writing
and reading plus the data image.

In the text, I mention that emoji can be printed by substituting them for standard ASCII characters. To see this work, look for the code lines that replace characters [ ] and ^ Currently I have to set them to "" because the Forum will not accept emoji. But you can insert any that you wish into the 3 "" and see them display

Code: Select all

' Datastore Sync

' based on Datastore by Henko
' October 2016

SET ORIENTATION LANDSCAPE
laun$=LAUNCHER$ ()
GET SCREEN SIZE sw,sh
dev$=DEVICE_TYPE$()
iostest=0                ' set to 1 to test other iOS devices on iPad
IF iostest THEN
  dev$=""
  sw=667!sh=375          ' to test iPhone 6
ENDIF
rw=sw/1024!rh=sh/768
le=20000
GRAPHICS ! ss=SCREEN_SCALE()
send=0

IF send THEN
   a$="We have a very chilly Fall here in Calgary."&CHR$(10)
   a$&="I am testing the data storage."&CHR$(10)
   a$&="I am going to save an image and export it to the camera roll."&CHR$(10)
   a$&="I will include some emoji: [ ] ^ ."&CHR$(10)
   
  FOR m=1 TO 100
   a$&="We have a very chilly Fall here in Calgary."&CHR$(10)
   a$&="I am testing the data storage."&CHR$(10)
   a$&="I am going to save an image and export it to the camera roll."&CHR$(10)
   a$&="I will include some emoji: [ ] ^ ."&CHR$(10)
  NEXT m
   
  le=LEN(a$)

   FIELD "input" TEXT a$ AT 50*rw,220*rh SIZE 800*rw,260*rh ML RO
   DRAW FONT SIZE 14*rw
   DRAW TEXT "imagedata1.jpg" AT 0,190*rh
   DRAW FONT SIZE 20*rw
   DRAW TEXT "Write" AT 880,290*rh
   DRAW TEXT "data to" AT 880,310*rh
   DRAW TEXT "screen" AT 880,330*rh
   lin=-8!k=0
   FOR i=0 TO le-1
     IF i%400=0 THEN! lin+=8!k=0!ENDIF
     draw_num(k,lin,ASC(MID$(a$,i,1)))
     k+=1
   NEXT i
   GRAPHICS SAVE 0,0, 200,200 TO "imagedata1.jpg"
   ALBUM EXPORT "imagedata1.jpg"
ELSE

   ALBUM IMPORT "imagedata2.jpg"
   DRAW IMAGE "imagedata2.jpg" AT 0,0 SCALE .5
ENDIF
   'le=1000
   DRAW TEXT "Read" AT 880,560*rh
   DRAW TEXT "data from" AT 880,580*rh
   IF send THEN
     DRAW TEXT "screen" AT 880,600*rh
   ELSE
     DRAW TEXT "saved" AT 880,600*rh
     DRAW TEXT "image" AT 880,620*rh
   ENDIF
   
   lin=-8!k=0
   FOR i=0 TO le-1
     IF i%400=0 THEN! lin+=8!k=0!ENDIF
     temp$ =CHR$(get_num(k,lin))
     IF temp$="]" THEN temp$=""
     IF temp$="[" THEN temp$=""
     IF temp$="^" THEN temp$=""
     b$ &= temp$
     k+=1
   NEXT i
   FIELD "output" TEXT b$ AT 50*rw,500*rh SIZE 800*rw,260*rh ML RO

PAUSE 10
END

DEF draw_num(x,y,num)
FOR i=0 TO 7
  IF BIT(num,i) THEN DRAW PIXEL x,y+i
NEXT i
END DEF

DEF get_num(x,y)
num=0
FOR i=0 TO 7
  GET PIXEL x,y+i COLOR r,g,b
  IF r+g+b>2.5 THEN num+=2^i
NEXT i
RETURN num
END DEF

[Henko]

Anyway, decoding of this info should be done by software. So, encoding also can be done not for direct human reading. That is, color of a pixel can have its meaning. Each pixel can have 256*256*256 values. So potential amount of encoded info can be very large.

There is no difference between this statement and the use i make of the pixel colordata. Taking into accout the "alpha" as well, one pixel may have one out of 256*256*256*256 colors, or 2^32 colors, as the color is defined by 4 bytes = 32 bits.

If we use the 4 bytes to represent ascii characters, then one pixel represents one "word" of 4 characters out of an alphabet of 256 different characters. The number of possible words for one pixel is then 256*256*256*256 words, the only difference is that the "state" of a pixel is called "word" instead of "color".