Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -1/+101 |
| | |||||
* | forgot to `git add` a file | Kartik K. Agaram | 2021-07-16 | 1 | -0/+1098 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -3/+3 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 6 | -1539/+1363 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -1133/+23 |
| | |||||
* | more powerful load-sectors | Kartik K. Agaram | 2021-07-16 | 3 | -18/+46 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 5 | -33/+33 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 3 | -21/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 241 | -9375/+18695 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 89 | -102/+293 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -5/+5 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 1 | -1/+1 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 1 | -55/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-15 | 6 | -45929/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-14 | 1 | -0/+1217 |
| | |||||
* | color dithering seems to be working | Kartik K. Agaram | 2021-07-14 | 1 | -1/+8 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-14 | 1 | -0/+1 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-14 | 1 | -1/+1 |
| | |||||
* | clarify a corner case in 2's complement integers | Kartik K. Agaram | 2021-07-14 | 1 | -0/+31 |
| | | | | https://merveilles.town/@akkartik/106577885001702701 | ||||
* | dithering ppm files using all 256 colors | Kartik K. Agaram | 2021-07-13 | 1 | -2/+205 |
| | | | | | Not quite working yet, but yields an interesting 'sketching-like' effect. | ||||
* | scaling the palette working on third attempt | Kartik K. Agaram | 2021-07-13 | 1 | -2/+16 |
| | | | | | See commits b4e997adb8 and 2777479a94. This seems like a good sign that dithering is now extremely precise. | ||||
* | get rid of our ugly rounding code | Kartik K. Agaram | 2021-07-13 | 1 | -8/+1 |
| | | | | | | | | | | | | | | | It turns out "truncating" the last 4 bits is actually more accurate, because it divides up the palette evenly. Before: 0-7 -> 0 8-0x17 -> 1 0x18-0x27 -> 2 ... 0xd8-0xe7 -> 0xe 0xe8-0xff -> 0xf The first interval is just 8 shades, and the final interval is 24 shades. | ||||
* | clean up some unseemly speckles | Kartik K. Agaram | 2021-07-13 | 1 | -3/+2 |
| | | | | | | | Turns out they were a bug after all, and scaling the palette was just making them more obvious. The bug: I was carefully clamping to 0xf0 to avoid rounding later, but I forgot to do so for values between 0xf0 and 0xff. As a result, some values could round up past 0xff and turn black. | ||||
* | cleanup | Kartik K. Agaram | 2021-07-13 | 1 | -65/+5 |
| | |||||
* | give up on .pgm files with color depths != 255 | Kartik K. Agaram | 2021-07-13 | 1 | -9/+5 |
| | | | | | | Things kinda seem to work for color depths close to 255, but it isn't really the goal here, and I don't have the skills of numerical analysis to track this down. | ||||
* | undo | Kartik K. Agaram | 2021-07-13 | 1 | -19/+7 |
| | |||||
* | experiment | Kartik K. Agaram | 2021-07-13 | 1 | -7/+19 |
| | | | | | Now scaling pixels to 255 levels looks a lot better. Still worse, though. On both t.pgm and barbara.pgm. | ||||
* | now t.pgm looks right | Kartik K. Agaram | 2021-07-13 | 1 | -7/+7 |
| | |||||
* | clamp the upper bound of nearest-color as well | Kartik K. Agaram | 2021-07-13 | 1 | -30/+53 |
| | | | | | I'd kinda convinced myself it would never happen, but observations say otherwise. Unless there's a bug elsewhere.. | ||||
* | . | Kartik K. Agaram | 2021-07-13 | 1 | -6/+11 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-13 | 1 | -14/+10 |
| | |||||
* | finally a clue: error is going over 255 | Kartik K. Agaram | 2021-07-13 | 1 | -9/+75 |
| | | | | Exactly in the places to the right of the line. | ||||
* | undo | Kartik K. Agaram | 2021-07-13 | 1 | -14/+2 |
| | |||||
* | experiment: scaling pixels to 255 levels | Kartik K. Agaram | 2021-07-13 | 1 | -2/+14 |
| | | | | | This is strictly worse than before, both with barbara.pgm and more subtly with t.pgm. | ||||
* | . | Kartik K. Agaram | 2021-07-12 | 3 | -43/+1331 |
| | | | | | | | | | Undo commit 70a03be0d0 and reinline the helper extracted there. I have a better sense now of the primitives to reuse between greyscale and color dithering. https://merveilles.town/@akkartik/106571585137582228 | ||||
* | more precise error-diffusion | Kartik K. Agaram | 2021-07-12 | 2 | -34/+22222 |
| | | | | | | | | | The Barbara test image has been looking right since commit 430dd67cb2. However, t.pgm has not. This doesn't fix it, but does seem like an improvement. The remaining error seems to be unrelated to rounding. Adding 8 more bits of precision has no effect. | ||||
* | . | Kartik K. Agaram | 2021-07-12 | 1 | -28/+28 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-11 | 1 | -2/+2 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-11 | 1 | -5/+2 |
| | |||||
* | forget HSL conversion for now, stick to RGB | Kartik K. Agaram | 2021-07-11 | 2 | -13/+50 |
| | | | | | It looks like seeking the nearest neighbor in HSL space leads to more saturated colors. | ||||
* | . | Kartik K. Agaram | 2021-07-11 | 1 | -42/+42 |
| | | | | Inline a helper. | ||||
* | . | Kartik K. Agaram | 2021-07-11 | 1 | -33/+39 |
| | | | | Extract a helper. | ||||
* | . | Kartik K. Agaram | 2021-07-11 | 1 | -32/+30 |
| | | | | Inline an unnecessary block. | ||||
* | . | Kartik K. Agaram | 2021-07-11 | 1 | -20/+20 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-11 | 1 | -1/+11 |
| | |||||
* | dither 256-level greyscale to 8-level greyscale | Kartik K. Agaram | 2021-07-11 | 2 | -2/+212 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-10 | 1 | -24/+24 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-10 | 1 | -3/+3 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-10 | 4 | -23/+3 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-10 | 1 | -88/+47 |
| |