This Is A Self-Referential Problem

Question

Tupper's Self-Referential Formula _{^{(copied from Wikipedia)}}

Tupper's self-referential formula is a formula defined by Jeff Tupper that, when graphed in two dimensions at a very specific location in the plane, can be "programmed" to visually reproduce the formula itself. It is used in various math and computer science courses as an exercise in graphing formulae.

$$ \frac{1}{2} < \left\lfloor \text{mod}\left( \left\lfloor \frac{y}{17} \right\rfloor 2^{ -17 \lfloor x \rfloor -\text{mod}\left( \lfloor y \rfloor ,17 \right) } ,2 \right) \right\rfloor $$

where \$\lfloor\cdot\rfloor\$ is the floor function.

Let \$k\$ be the following 543-digit number: 960939379918958884971672962127852754715004339660129306651505519271702802395266424689642842174350718121267153782770623355993237280874144307891325963941337723487857735749823926629715517173716995165232890538221612403238855866184013235585136048828693337902491454229288667081096184496091705183454067827731551705405381627380967602565625016981482083418783163849115590225610003652351370343874461848378737238198224849863465033159410054974700593138339226497249461751545728366702369745461014655997933798537483143786841806593422227898388722980000748404719

If one graphs the set of points \$(x, y)\$ in \$0 \le x < 106\$ and \$k \le y < k + 17\$ satisfying the inequality given above, the resulting graph looks like this (note that the axes in this plot have been reversed, otherwise the picture comes out upside-down):

So what?

The interesting thing about this formula is that it can be used to graph any possible black and white 106x17 image. Now, actually searching through to search would be extremely tedious, so there's a way to figure out the k-value where your image appears. The process is fairly simple:

1. Start from the bottom pixel of the first column of your image.
2. If the pixel is white, a 0 will be appended to the k-value. If it is black, append a 1.
3. Move up the column, repeating step 2.
4. Once at the end of the column, move to the next column and start from the bottom, following the same process.
5. After each pixel is analyzed, convert this binary string to decimal, and multiply by 17 to get the k-value.

What's my job?

Your job is to create a program which can take in any 106x17 image, and output its corresponding k-value. You can make the following assumptions:

1. All images will be exactly 106x17
2. All images will only contain black (#000000) or white (#FFFFFF) pixels, nothing in between.

There's a few rules, too:

1. Output is simply the k-value. It must be in the proper base, but can be in any format.
2. Images must be read from either a PNG or PPM.
3. No standard loopholes.

Test Images

[ ] should produce ~1.4946x10⁵⁴²

[ ] should produce ~7.2355x10¹⁵⁹

[ ] should produce 2¹⁸⁰¹ * 17

[ ] should produce (2¹⁸⁰²-1) * 17

Check out this Gist for the exact solutions.

This is code-golf, so least number of bytes wins.

---

Helpful Links

Wikipedia

Wolfram Mathworld

Answer 1

Pyth - 21 bytes

Simple to do with pyth's i base conversion. Takes input as PBM file name and reads using ' command. I had to use !M to negate blacks and whites. Everything else is self-explanatory.

*J17i!MsC_cJrstt.z7 2

Try it here online. (Web interpreter can't read files, so is modified and takes file as input).

Answer 2

CJam, 16

l,l~q:~f*/W%ze_b

With big thanks to Dennis. Try it online

In case you're having problems with the url, this is the input I tested:

P1
106 17
0000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000011111100000000000000000000000
0000000000000000000000000000000000000000000000000000000000000111111000
0000011111100110000000000000000000000000000000000000000000000000000000
0000000000000000000000000110011111100000100111100001000000000000001100
0110000000000000000000000000000000000000000000000000000000001000011110
0100010011111100001000000000000100101001110000000000000000000000000000
0011000000000000000000000100001111110010010110000110001000000000000100
0110010010000000011000000000000000000100100000000000000000000100011000
0110101111000000111111000000000001000110010011111100100100111001111100
0111001011110000000000000011111100000011111111000000110111000000000001
0000100111100000110000110001100000101000001100001000000000000011101100
0000111110110000001000010000000000010010000100100110011001100100100110
0100110010011001000000000000100001000000110110011000011000010000000000
0100110001001001100110011000001001100100110010011001000000000000100001
1000011001100111111111001100000000000100110001001001100110011001111001
1001001100100110010000000000001100111111111001101111111111111100000000
0001001010010010011001100101000110011001100000110000100000000000001111
1111111111010111001001001110000000000000110001101101100110011000111001
1001100111110011110000000000000001110010010011100010001001000100000000
0000000000000000000000000000000000000000000000000000000000000000000000
1000100100010000100000000001000000000000000000000000000000000000000000
0000000000000000000000000000000000001000000000010000010000000010000000
0000000000000000000000000000000000000000000000000000000000000000000000
0001000000001000000011111111000000000000000000000000000000000000000000
0000000000000000000000000000000000000000111111110000

I used the format that GIMP generated when exporting as ASCII pbm, with the comment removed.

Explanation:

l,    read the first line ("P1" magic number) and get its length (2)
l~    read and evaluate the second line (106 17)
q     read the rest of the input (actual pixels)
:~    evaluate each character ('0' -> 0, '1' -> 1, newline -> nothing)
f*    multiply each number by 17
/     split into rows of length 106
W%    reverse the order of the rows
z     transpose
e_    flatten (effectively, concatenate the lines)
      now we have all the pixels in the desired order, as 0 and 17
b     convert from base 2 "digits" to a number

Answer 3

Python 2: 133 110 bytes

A first attempt in python using PIL:

from PIL.Image import*
j=open(input()).load()
a=k=0
while a<1802:k=(j[a/17,16-a%17][0]<1)+k*2;a+=1
print k*17

Thanks to helpful commenters below

Answer 4

C#, 199

This was fun! There's nothing wrong with reloading a bitmap 106 * 17 times, right? I did it as a function to save some bytes, not sure if that's legal.

BigInteger s(string i){return (Enumerable.Range(0,106).SelectMany(x=>Enumerable.Range(0,17).Select(y=>new BigInteger(new Bitmap(i).GetPixel(x,y).B==0?1:0)).Reverse()).Aggregate((x,y)=>(x<<1)+y)*17);}

i is the input file name.

Also, as a single expression, just because it is one expression, with i provided or subbed (167 bytes)

(Enumerable.Range(0,106).SelectMany(x=>Enumerable.Range(0,17).Select(y=>new BigInteger(new Bitmap(i).GetPixel(x,y).B==0?1:0)).Reverse()).Aggregate((x,y)=>(x<<1)+y)*17)

Answer 5

Wolfram Language (Mathematica) 69 50 Bytes

Update: After revisiting this code a few years later due to @Matt's comment, I've found a few bytes of savings. Note that the test pictures must be Binarized first, because they are 24 bit color PNGs as downloaded from the posted question, instead of being monochrome format as posted in the assumptions.

17Fold[#+##&,1-Join@@Reverse/@Thread@ImageData@#]&

old code

17*FromDigits[1-Flatten[Reverse/@Transpose[ImageData@Binarize@#]],2]&

This function will reproduce the image:

   ArrayPlot[Table[Boole[1/2<Floor[Mod[Floor[y/17]2^(-17Floor[x]-Mod[Abs[y],17]),2]]],{y,1+#,17+#},{x,106,1,-1}]]&