[pc] new image codec idea considerations

[fir]

[pc] means programming in c as some still dont know that programing in c
belongs to c and thus also could and should be discussed here
(it could also be discussed elsewhere but such grups are dead afaik)

i got the idea of image codec that compresses more than jotpeg if this
is possible..maybe not this what i consider but it is fun to consider anyway

the idea is to use maybe such recipe

image is a list of points something like

struct point {unsigned short x; unsigned short y; unsigned color; };

say
100, 100, 0xff0000
700, 300, 0xffff00
200, 700, 0xffffff


and you build the image that for each pixel in image (say 1000x1000
size) you find the closes (in a mean os sqrt(dx*dx+dy*dy)) point
on the list and set this pixel to the color of closest pixel

this will allow to store some images in an efficient way imo (Probably)

each point here has 64 bits/8 bytes of storage and to encode something
like polish flag image you need 2 points (16B)

i tested how it look if i set randomly soem dose of points like 1000
and render it and it looks like mosaic of random polygons mostly
pentagons though probably with dose of quads triangles and hexagons

now i think maybe to make simple editor to allow me to set thiose points
and drag them by mouse to see if some reasonal images can be build from
low dose of points

some notes

1) do you think it can be more efective storage than jotpeg?

2) the point size can be changed for examplesomethimes it could be cut
down if use les bits for x y and using liek palette for color
(also some other bit more elaborate modifications could be used)

3) most probably there could be also used one fiels
(liek say not this not much used alpha byte) for denoting how the
point could be treated - as points could work differently also
for example point could be marked not to chose closest
color but the mix making some gradient etc) - imo puting a variety
of meaning into thiose point potentially could make the best
optimisations for image

[fir]

Post by fir
[pc] means programming in c as some still dont know that programing in c
belongs to c and thus also could and should be discussed here
(it could also be discussed elsewhere but such grups are dead afaik)
i got the idea of image codec that compresses more than jotpeg if this
is possible..maybe not this what i consider but it is fun to consider anyway
the idea is to use maybe such recipe
image is a list of points something like
struct point {unsigned short x; unsigned short y; unsigned color; };
say
100, 100, 0xff0000
700, 300, 0xffff00
200, 700, 0xffffff
and you build the image that for each pixel in image (say 1000x1000
size) you find the closes (in a mean os sqrt(dx*dx+dy*dy)) point
on the list and set this pixel to the color of closest pixel
this will allow to store some images in an efficient way imo (Probably)
each point here has 64 bits/8 bytes of storage and to encode something
like polish flag image you need 2 points (16B)
i tested how it look if i set randomly soem dose of points like 1000
and render it and it looks like mosaic of random polygons mostly
pentagons though probably with dose of quads triangles and hexagons
now i think maybe to make simple editor to allow me to set thiose points
and drag them by mouse to see if some reasonal images can be build from
low dose of points
some notes
1) do you think it can be more efective storage than jotpeg?
2) the point size can be changed for examplesomethimes it could be cut
down if use les bits for x y and using liek palette for color
(also some other bit more elaborate modifications could be used)
3) most probably there could be also used one fiels
(liek say not this not much used alpha byte) for denoting how the
point could be treated - as points could work differently also
for example point could be marked not to chose closest
color but the mix making some gradient etc) - imo puting a variety
of meaning into thiose point potentially could make the best
optimisations for image

i wrote ad hoc basic editor, code below (using my green fire library)

but the problem is probably some gould algorithms for thiose gradients
should be found - it should just probably allow more like photographic
encoding, but the question is what algorithm? what exact algorith (based
on rendering on those movable points) whould bring the best result ?

screenshot


https://drive.google.com/file/d/1-6PcLyycJZyjC_1exrZhVAp0Yo60Z00Z/view?usp=sharing

app for win

https://drive.google.com/file/d/1-874K9wydLL15EzJ4ZcEh2J0_EywRvXZ/view?usp=drive_link

code (using my library green fire)


#include<stdio.h>
#include "green-fire.h"
#include<time.h>
#include<unistd.h>
#include<math.h>


struct point {int x; int y; unsigned color; float tag;};

const int points_max = 30;
point points[points_max] = {{100,100,0xff0000}, {200,100,0xffff00},
{200,200,0x00ff00}, {120,300,0x00ffff}};

int point_selected = -1;

void InitRandPoints()
{
for(int i=0; i<points_max;i++)
{
points[i].x = rand2(10,frame_size_x-1-10);
points[i].y = rand2(10,frame_size_y-1-10);

points[i].color = rand2(0,255)*256*256 + rand2(0,255)*256 +
rand2(0,255);

}

}


void OnResize() {}

int FindClosestPoint(int x, int y)
{
float min_dist = 1e9;
int min_dist_i = -1;

for(int i=0; i<points_max;i++)
{
points[i].tag = distance2d(x,y,points[i].x, points[i].y);
if(points[i].tag<min_dist)
{
min_dist = points[i].tag;
min_dist_i = i;
}
}
return min_dist_i;



}

int image_build = 0;

void BuildImage()
{
for(int y=0; y<frame_size_y; y++)
for(int x=0; x<frame_size_x; x++)
{
int n = FindClosestPoint(x,y);
if(n>=0)
SetPixelUnsafe(x,y, points[n].color);
else
SetPixelUnsafe(x,y, 0x000000);
}
image_build=1;
}

void DrawPointsAsCircles()
{
for(int i=0; i<points_max;i++)
{
if(point_selected!=i)
{
FillCircle(points[i].x, points[i].y, 3, points[i].color);

DrawCircle(points[i].x, points[i].y, 3, 0xffffff);
}
else
FillCircle(points[i].x, points[i].y, 3, 0xffffff);

}

}

void RunFrame()
{
if(frame_number == 0) InitRandPoints();

if(!image_build) BuildImage();

DrawPointsAsCircles();
}

int CheckIfTouchesSomePoint(int x, int y)
{
int n = FindClosestPoint(x,y);
if(n<0) return -1;

if(distance2d(points[n].x, points[n].y, x, y)<=3) return n;

return -1;
}

void ProcessMouseMove(int x, int y)
{
if(lmb_pressed)
{
points[point_selected].x=mouse_x;
points[point_selected].y=mouse_y;
image_build = 0;

}
else
{
int n = CheckIfTouchesSomePoint(x,y);
if(n>=0) point_selected = n;
}

}

void ProcesLMBClick(int x, int y)
{
return;

if(point_selected<0) return;

points[point_selected].x=mouse_x;
points[point_selected].y=mouse_y;
image_build = 0;

}

void ProcessKeyDown(int key)
{
if(key==' ') image_build=0;



}

void OnResizeFrameResoltion()
{
image_build=0;
}

int main(int argc, char* argv[])
{
RegisterMouseMove( ProcessMouseMove );
RegisterKeyDown( ProcessKeyDown );
RegisterLeftMouseButtonDown(ProcesLMBClick);

RegisterOnResize( OnResize );
RegisterOnResizeFrameResolution( OnResizeFrameResoltion );
RegisterRunFrame( RunFrame );
SetSleepValue(10);
SetScaleOnResize(1);

int base_height = 180;

SetupWindow4(" image experimental encoder idea", 10, 10, .9,
.9, base_height/.9 );

return 0;
}

[fir]

or maybe yet to rephrasing problem:

imagine you got list of N 2d points (ont pixels) given by coordinates x y
and color (and maybe yet some per point small data, but in simple case no
additional data)

how to exactly make an algorithm of interpolation (for pixels on a
rectangle where the points lay) to make it most suitable for storing
images with a less points (data) used and the image being most acurate for
such amount of points?

[Lawrence D'Oliveiro]

Post by fir
and you build the image that for each pixel in image (say 1000x1000
size) you find the closes (in a mean os sqrt(dx*dx+dy*dy)) point on the
list and set this pixel to the color of closest pixel

<https://en.wikipedia.org/wiki/PackBits>