about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* finally a clue: error is going over 255Kartik K. Agaram2021-07-131-9/+75
| | | | Exactly in the places to the right of the line.
* undoKartik K. Agaram2021-07-131-14/+2
|
* experiment: scaling pixels to 255 levelsKartik K. Agaram2021-07-131-2/+14
| | | | | This is strictly worse than before, both with barbara.pgm and more subtly with t.pgm.
* .Kartik K. Agaram2021-07-123-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-diffusionKartik K. Agaram2021-07-122-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. Agaram2021-07-121-28/+28
|
* .Kartik K. Agaram2021-07-111-2/+2
|
* .Kartik K. Agaram2021-07-111-5/+2
|
* forget HSL conversion for now, stick to RGBKartik K. Agaram2021-07-112-13/+50
| | | | | It looks like seeking the nearest neighbor in HSL space leads to more saturated colors.
* .Kartik K. Agaram2021-07-111-42/+42
| | | | Inline a helper.
* .Kartik K. Agaram2021-07-111-33/+39
| | | | Extract a helper.
* .Kartik K. Agaram2021-07-111-32/+30
| | | | Inline an unnecessary block.
* .Kartik K. Agaram2021-07-111-20/+20
|
* .Kartik K. Agaram2021-07-111-1/+11
|
* dither 256-level greyscale to 8-level greyscaleKartik K. Agaram2021-07-112-2/+212
|
* .Kartik K. Agaram2021-07-101-24/+24
|
* .Kartik K. Agaram2021-07-101-3/+3
|
* .Kartik K. Agaram2021-07-104-23/+3
|
* .Kartik K. Agaram2021-07-101-88/+47
|
* increase precision for dithering computationsKartik K. Agaram2021-07-101-3/+8
| | | | Now we get a perfect checkerboard pattern.
* .Kartik K. Agaram2021-07-102-34/+106
| | | | https://merveilles.town/@akkartik/106559551043772522
* .Kartik K. Agaram2021-07-101-4/+4
| | | | https://merveilles.town/@akkartik/106557664535993377
* dithering greyscale using black/whiteKartik K. Agaram2021-07-105-24/+293
| | | | Starting to look right.
* reorder a few functionsKartik K. Agaram2021-07-081-126/+128
|
* .Kartik K. Agaram2021-07-081-0/+12
|
* scaling ppm imagesKartik K. Agaram2021-07-081-26/+76
|
* scaling pgm imagesKartik K. Agaram2021-07-081-21/+65
|
* .Kartik K. Agaram2021-07-081-3/+2
|
* .Kartik K. Agaram2021-07-081-3/+3
|
* .Kartik K. Agaram2021-07-081-4/+4
|
* .Kartik K. Agaram2021-07-081-1/+1
|
* scaling pbm imagesKartik K. Agaram2021-07-081-30/+67
|
* .Kartik K. Agaram2021-07-081-18/+18
|
* better ppm colorsKartik K. Agaram2021-07-081-7/+31
| | | | I had some logic to make hue distance cylindrical, but it wasn't right.
* better greyscaleKartik K. Agaram2021-07-081-2/+8
|
* .Kartik K. Agaram2021-07-081-14/+14
|
* .Kartik K. Agaram2021-07-081-1/+0
|
* ppm colors are weird, thoughKartik K. Agaram2021-07-084-1/+16404
|
* ppm supportKartik K. Agaram2021-07-071-3/+32
| | | | Typo in commit fe3cbcd77: it only rendered pbm/pgm.
* instructions for Universal CtagsKartik K. Agaram2021-07-072-3/+4
| | | | Thanks Sumeet Agarwal for raising this issue.
* .Kartik K. Agaram2021-07-071-9/+9
|
* render ppm/pgmKartik K. Agaram2021-07-071-7/+106
| | | | Looks pretty bad compressing 256 shades of grey to 8.
* load ppm/pgm/ppm on demandKartik K. Agaram2021-07-071-8/+113
|
* initial image renderingKartik K. Agaram2021-07-075-0/+6163
| | | | | | Supports just some ASCII formats: https://en.wikipedia.org/wiki/Netpbm Colors are messed up. That's next.
* .Kartik K. Agaram2021-07-061-8/+18
|
* .Kartik K. Agaram2021-07-062-44/+44
|
* nearest h/s/l color by a euclidean metricKartik K. Agaram2021-07-061-0/+51
|
* primitives for double-bufferingKartik K. Agaram2021-07-051-4/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I thought I needed these for this bouncing-ball demo: def (bounce screen) with (w (width screen) h (height screen) cx 16 cy 16 dx 12 dy 19) while 1 clear screen ring screen cx cy 16 3 5 cx += dx cy += dy when (or (cx > w) (cx < 0)) set dx 0-dx when (or (cy > h) (cy < 0)) set dy 0-dy for _ 0 (< _ 100) ++_ # delay No matter how I adjusted the delay I couldn't get rid of the jitter. So I built a double-buffered version: (bounce2 . [def (bounce2 screen) with (w (width screen) h (height screen) cx 16 cy 16 dx 12 dy 19 screen2 (new_screen (columns screen) (lines screen))) while 1 clear screen2 ring screen2 cx cy 16 3 5 cx += dx cy += dy when (or (cx > w) (cx < 0)) set dx 0-dx when (or (cy > h) (cy < 0)) set dy 0-dy blit screen2 screen for _ 0 (< _ 100) ++_]) # delay But it didn't make a difference! Turns out nothing will help you when successive frames are too far apart. This is the correct tweak to `bounce`: - dx 12 - dy 19) + dx 1 + dy (/ 19 12)) Still, we'll keep double-buffering around for the future.
* shell: fix clear on screensKartik K. Agaram2021-07-051-1/+1
| | | | | | | Broken since commit c95648c96 on Jul 3. Unclear what test to write for this. Should clear-stream check for NULL? Should apply-clear?
* expose Mu implementation of 'bezier'Kartik K. Agaram2021-07-051-1/+256
| | | | Still no support for acute-angled control points.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-23 10:35:29 +0000