Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deciphering the Business Card Raytracer

fabiensanglard.net

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Deciphering the Business Card Raytracer

#41

Post by Sharlin »

evincarofautumn wrote: post #38
Sharlin wrote: post #36

Earlier quoted context omitted.

Raw data without any header, I suppose. You must know or guess the width and height to properly decode the image.

Guessing the dimensions of an image with n pixels is equivalent to factoring n , so good luck with that! And only if your luck is really good (prime width and height) will there be a unique solution—actually you still don’t know whether to choose portrait or landscape. It gets even more interesting if you don’t know the number of channels or the pixel format.

Well, you can check if the image matches common resolutions and aspect ratios - if there are 307200 pixels, for example, a pretty good guess is that it's 640x480 (or 480x640). You'd need a human to see if the image looks correct - actually, with a simple GUI, it wouldn't take a human very long at all to figure out the correct aspect ratio. This could probably be automated easily enough using some pattern recognition - the "shearing" pattern caused by guessing the width wrong is pretty linear and well-behaving.

Re: Deciphering the Business Card Raytracer

#42

Post by LeafStorm »

mistercow wrote: post #28
fabien_sanglard wrote: post #22

Earlier quoted context omitted.

How come you decided for a coordinate system with Z pointing up instead of the traditional right hand/left hands coordinate systems ?

In non-programming math contexts, it's pretty standard for Z to point up. I have no idea why, as it seems to me like the typical way it works in graphics programming is the more obvious extension of 2D plotting into 3D.

When I took Calculus III, Z was up. When I took Engineering Physics the same semester, Y was up.

According to legend, this is why the Math and Physics departments hate each other.

Re: Deciphering the Business Card Raytracer

#43

Post by logicallee »

chrissnell wrote: post #14

If you want to make your own, like Fabian Sanglard did, take this block of binary numbers and draw your initials (left-justified) with 1's: 0001110000010001110 0010000000000010000 0100000000010010000 0100000000010001100 0100000000010000100 0010000010010000010 0001110001100011100 That's my initials, cjs. If you unfocus your eyes, you can see the letters pretty clearly. Take each line, top to bottom, and convert to dec…

thanks.

what exactly were you referring to with "I probably could have coded this in the time that it took me to draw my initials in binary pixels."?

Re: Deciphering the Business Card Raytracer

#44

Post by phySi0 »

raminf wrote: post #21
a_e_k wrote: post #18

Hi there, code author here. I've been lurking here for years, but couldn't resist an invitation like this. I've always enjoyed Fabien's analyses so it's great fun to see what he makes of my own code. Anyway, a few clarifications from what I remember of this. (I wrote this '09, and I don't have my old notes in front of me right now): * The `n` value returned by the trace function, `T()`, is the surface normal. It retu…

#define op operator #define rt return Then replacing the corresponding inline tokens shaves off another 25 bytes from the source without affecting the output or (arguably) the readability. Sorry, my inner obfuscator couldn't resist :-) Beautiful bit of coding, btw.

>Then replacing the corresponding inline tokens shaves off another 25 bytes from the source

I dunno, I kinda like the current size.

Re: Deciphering the Business Card Raytracer

#45

Post by mistercow »

Luc wrote: post #39
mistercow wrote: post #28

Earlier quoted context omitted.

In non-programming math contexts, it's pretty standard for Z to point up. I have no idea why, as it seems to me like the typical way it works in graphics programming is the more obvious extension of 2D plotting into 3D.

It makes sense if you think of the X and Y axis as being drawn on paper, which usually lies flat on the desk.

Sort of, kind of, but it's a stretch. "Up and down" on a page are not oriented according to gravity, but according to the top and bottom of the page. If you say "Well, we'll make the z-axis vertical because vertical is perpendicular to the plane of the desk, and that's depth", and then you put the z-axis toward the top of the page, you're using two completely different definitions of "vertical" in the same sentence.

Re: Deciphering the Business Card Raytracer

#46

Post by chrissnell »

logicallee wrote: post #43
chrissnell wrote: post #14

If you want to make your own, like Fabian Sanglard did, take this block of binary numbers and draw your initials (left-justified) with 1's: 0001110000010001110 0010000000000010000 0100000000010010000 0100000000010001100 0100000000010000100 0010000010010000010 0001110001100011100 That's my initials, cjs. If you unfocus your eyes, you can see the letters pretty clearly. Take each line, top to bottom, and convert to dec…

thanks. what exactly were you referring to with "I probably could have coded this in the time that it took me to draw my initials in binary pixels."?

I could have coded something to generate customized versions of the original source, given three ASCII initials.

Re: Deciphering the Business Card Raytracer

#47

Post by logicallee »

evincarofautumn wrote: post #38
Sharlin wrote: post #36

Earlier quoted context omitted.

Raw data without any header, I suppose. You must know or guess the width and height to properly decode the image.

Guessing the dimensions of an image with n pixels is equivalent to factoring n , so good luck with that! And only if your luck is really good (prime width and height) will there be a unique solution—actually you still don’t know whether to choose portrait or landscape. It gets even more interesting if you don’t know the number of channels or the pixel format.

No, that's not it at all.

What you just mentioned is actually really easy (if it worked): factoring n where n is up to 10 megapixels.

Factoring up to a few megapixels (e.g. 3648 x 2736) isn't hard at all! At most there are 3159 guesses (square root of number of pixels) before you hit one of the factors - and that's starting at 1, rather than starting at sane minimum aspect ratio.

(It's only when you start trying to factor really large numbers that the problem becomes intractable. For example, the same trick just doesn't apply to a composite number that's 600 digits long. We're talking 6-9 digits, which a tight loop can crunch through faster than a disk read.)

The harder issue is after you do factor it into primes, you still have to combine those primes into a width and height.

For example, 640 x 480 is 307200. Factor that and you get 2^12 * 3 * 5^2.

There's obviously quite a few ways to combine those into two groups (two factors)...

so you're really not done. Probably the best heuristic is to simply count pixels and then compare with common formats.

I suppose you could do your factorization trick, and then try combining the factors in every possible way into two groups, and for any combinations that result in a "sane" aspect ratio, run some kind of vision algorithm to see if there are connected color blobs or something.

it does seem to me that for truly arbitrary pixel counts, the factors help but don't determine a unique choice.

Re: Deciphering the Business Card Raytracer

#48

Post by logicallee »

chrissnell wrote: post #46
logicallee wrote: post #43

Earlier quoted context omitted.

thanks. what exactly were you referring to with "I probably could have coded this in the time that it took me to draw my initials in binary pixels."?

I could have coded something to generate customized versions of the original source, given three ASCII initials.

Come on, Chris. I'm a big fan of the humblebrag, but you would still have to draw the binary pixel version of each letter (because C doesn't come with binary pixel array versions of the 26 letters) - so it would be 8 times as much work at an absolute minimum (26 characters versus the 3 that you did), even if the code to embed them in the array were a completely obvious 1-liner, and so was the code to clean up the justification.

Let's not flatter ourselves :)

Re: Deciphering the Business Card Raytracer

#49

Post by chrissnell »

logicallee wrote: post #48
chrissnell wrote: post #46

Earlier quoted context omitted.

I could have coded something to generate customized versions of the original source, given three ASCII initials.

Come on, Chris. I'm a big fan of the humblebrag, but you would still have to draw the binary pixel version of each letter (because C doesn't come with binary pixel array versions of the 26 letters) - so it would be 8 times as much work at an absolute minimum (26 characters versus the 3 that you did), even if the code to embed them in the array were a completely obvious 1-liner, and so was the code to clean up the jus…

Didn't mean to come off as arrogant but there are existing tools that would make this a lot easier. figlet(1) would make the pixel conversion pretty easy. Pixels to binary really isn't that hard. You could do it with a regex.

Re: Deciphering the Business Card Raytracer

#50

Post by raminf »

fabien_sanglard wrote: post #23
raminf wrote: post #21

Earlier quoted context omitted.

#define op operator #define rt return Then replacing the corresponding inline tokens shaves off another 25 bytes from the source without affecting the output or (arguably) the readability. Sorry, my inner obfuscator couldn't resist :-) Beautiful bit of coding, btw.

Can you pastebin.com it so we can see what it looks like ?

http://pastebin.com/ktukPBHE

I reformatted it so it would justify right like the original but for some reason Pastebin likes to reflow things.

It turns out the single-character tokens 'u' and 'w' were not being used so repurposing them for the #defines leads to a saving of 46 characters at the cost of an extra line. There are a few other recurring tokens but you hit a point of diminishing return.

One should not, however, lose sight of what an awesomely clever hack the whole thing is. Reminds me of some of the text-flow layouts in old illuminated manuscripts, or the more modern variations here (like the one with the light-bulb): http://www.smashingmagazine.com/2008/02/11/award-winning-new...

Post reply on HN