What is the better way to save pictures?

[bosapara]

What is the better way to save pictures as text? Item metadata or world / mod folder?

An example 1 picture 25x25 pixels takes about 650 bytes

[neoh4x0r]

What is the better way to save pictures as text?

As text ??

Do mean you want to generate ASCII art from a photo ?

(If not then you can't save a photo as text, unless you want garbage data).

[bosapara]

As text ?? Do mean you want to generate ASCII art from a photo ?

(If not then you can't save a photo as text, unless you want garbage data).

Yep, as text. An example we save some pixel art (an example from let's paint mod)
as "abcdefg" (a=black, b=white, c=red and etc), then open as formspec and can see some picture.

[Eran]

Item metadata gets sent to the client according to the minetest modding book. So since images get big quickly, using item metadata puts a bunch of unnecessary load on the connection. Better to use mod storage or maybe directly write to a file.

[bosapara]

Better to use mod storage or maybe directly write to a file.

One of problem is can we delete data from any storage when we delete item?

[Eran]

I think you'd have to track all ways the item can vanish by overriding its functions in the item definition. Though as far as I'm aware there's no way to do this foolproof since other mods can add all kinds of ways for items to vanish. This is a tough problem,
maybe you can find an alternative to binding it to an item.

[GreenXenith]

My skinmaker mod saves and loads images as PNG. Perhaps take a look at it.

[neoh4x0r]

As text ?? Do mean you want to generate ASCII art from a photo ?

(If not then you can't save a photo as text, unless you want garbage data).

Yep, as text. An example we save some pixel art (an example from let's paint mod)
as "abcdefg" (a=black, b=white, c=red and etc), then open as formspec and can see some picture.

Alright, I get it now....

You don't want to save a picture as a text string.....you want to generate a picture from text (in-game) (where each letter represents a pixel with a given color)


It should be noted that this is a really bad way to store image data -- it is essentially uncompressed data where the size of the image will be a 2nd order polynomial: y = x^2 .


An image of 32 x 32 pixels will need 1024 MB (1 GB) and a 64 x 64 image will be need more than 4096 MB (4 GB) of storage/memory.

[Eran]

It should be noted that this is a really bad way to store image data -- it is essentially uncompressed data where the size of the image will be a 2nd order polynomial: y = x^2 .


An image of 32 x 32 pixels will need 1024 MB (1 GB) and a 64 x 64 image will be need more than 4096 MB (4 GB) of storage/memory.

You are assuming that each pixel takes a megabyte, which is a bit (actually a bunch of bits) more than needed. Images still get big quickly though.

[bosapara]

My skinmaker mod saves and loads images as PNG. Perhaps take a look at it.

thanks, will check

You don't want to save a picture as a text string.....you want to generate a picture from text (in-game) (where each letter represents a pixel with a given color).

A few wrong, I would save it like meta as item, then just open this picture like formspec (on_use).

An image of 32 x 32 pixels will need 1024 MB (1 GB) and a 64 x 64 image will be need more than 4096 MB (4 GB) of storage/memory.

An image 25*25 takes 625 bytes of text for meta, an example below:

Code: Select all

abcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijk

[neoh4x0r]

It should be noted that this is a really bad way to store image data -- it is essentially uncompressed data where the size of the image will be a 2nd order polynomial: y = x^2 .


An image of 32 x 32 pixels will need 1024 MB (1 GB) and a 64 x 64 image will be need more than 4096 MB (4 GB) of storage/memory.

You are assuming that each pixel takes a megabyte, which is a bit (actually a bunch of bits) more than needed. Images still get big quickly though.

No, I am not assuming....

We aren't talking about actual pixels here....

They are wanting to use characters to represent a colored pixel and would require 1 byte (8-bits) per character.
A picture would be represented by a sequence of characters: abcdefg, etc -- and then display it in a formspec.

[neoh4x0r]

An image 25*25 takes 625 bytes of text for meta, an example below:

Code: Select all

abcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijkabcdefghijklmnabcdefghijk

I saved your text string to a file and the size of the file was 625 bytes + 1 byte (1 byte per letter) -- and by inference a 64x64 image will take a proportional amount of storage (1024 MB).

It doesn't matter how you store that string (in a file, int item meta data, or directly in system ram) it will always take (x^2 + overhead) bytes to store it -- it will be stored either on disk or in memory.

Let's face it.....this is a very inefficient method to store image data -- and it is the very reason that we have image compression/decompression algorithms.

You will definitely need to use a compression / decompression algorithm such as for png in GreenDimond's skinmaker -- however, that code was limited to 16x16 pixels.

[GreenXenith]

It should be noted that this is a really bad way to store image data -- it is essentially uncompressed data where the size of the image will be a 2nd order polynomial: y = x^2 .


An image of 32 x 32 pixels will need 1024 MB (1 GB) and a 64 x 64 image will be need more than 4096 MB (4 GB) of storage/memory.

You are assuming that each pixel takes a megabyte, which is a bit (actually a bunch of bits) more than needed. Images still get big quickly though.

No, I am not assuming....

We aren't talking about actual pixels here....

They are wanting to use characters to represent a colored pixel and would require 1 byte (8-bits) per character.
A picture would be represented by a sequence of characters: abcdefg, etc -- and then display it in a formspec.

You clearly said a 32x32 image would take up 1GB of space. That is absurd. In this case, it would take up just over a kilobyte of space. A real 32x32 image (with 8 bit color) would be around 8kb.

[neoh4x0r]

You clearly said a 32x32 image would take up 1GB of space. That is absurd. In this case, it would take up just over a kilobyte of space. A real 32x32 image (with 8 bit color) would be around 8kb.

I don't know why my eyes wanted to insert something that wasn't there.
------------------
at 1 byte per character....
25x25 (625) characters -- 625 bytes / 1024 kb/byte = <1 kb.
32x32 (1024) characters --1024 bytes / 1024 kb/byte = 1 kb.
64x64 (4096) characters -- 4096 bytes / 1024 kb/byte = 4kb.
------------------

However, the storage space is still x^2 -- that part is correct.

[GreenXenith]

I saved your text string to a file and the size of the file was 625 bytes + 1 byte (1 byte per letter) -- and by inference a 64x64 image will take a proportional amount of storage (1024 MB).

You clearly said a 32x32 image would take up 1GB of space. That is absurd. In this case, it would take up just over a kilobyte of space. A real 32x32 image (with 8 bit color) would be around 8kb.

That's because the pixels are not encoded as RGB integers but as a string of characters "abcdefghijklmnabcdefghijkab...."

Again, this is absurd. You must have your conversions wrong.
1 character (UTF8) takes up 1 byte. 1000 bytes is 1 kilobyte. 1000 kilobytes is 1 megabyte.
1024 megabytes of characters would be 1,024,000,000 (1.024 billion) characters.

You will definitely need to use a compression / decompression algorithm such as for png in GreenDimond's skinmaker -- however, that code was limited to 16x16 pixels.

It is not. Skins are 64x32, and as noted in the README, any size image can be displayed in a formspec.

[neoh4x0r]

I updated my previous post right before you replied: 1024 bytes per kilobyte.

[GreenXenith]

Regardless, saving as a string is perfectly viable. 1 character for each color and another for row breaks.

And it isn't always x^2, if the image is not square.
(Also, 1024bytes is a little more than a kilobyte)

[neoh4x0r]

It is not. Skins are 64x32, and as noted in the README, any size image can be displayed in a formspec.

I was refereing to: https://github.com/GreenXenith/skinmake ... -this-work

Specifically:

How does this work?
This mod is limited to 16x16 textures due to the method used and the limitations of the Minetest engine.
The Drawbacks
The reason Aurailus' mod is limited to 16x16 is the hard limit on texture modifiers used in nodes. Entities do not share this limit.

[Krock]

An image of 32 x 32 pixels will need 1024 MB (1 GB) and a 64 x 64 image will be need more than 4096 MB (4 GB) of storage/memory.

Assumptions:
* 32-bit color depth (4 bytes per pixel: RGB+A)
* Raw byte encoding, bitmap-like
* No ^[combine strings or whatsoever

Calculation: size_MiB = 4 * width * height / 1024^2
Reverse: an image of 32768 pixels in width and height would result in your calculated 4 GiB.

Even ^[combine is more efficient than your calculations (~27x the byte count): https://github.com/minetest/minetest/issues/6821

[bosapara]

Let's face it.....this is a very inefficient method to store image data -- and it is the very reason that we have image compression/decompression algorithms.

I see 5.0.1 version using restrictions for text length 10000 symbols as metadata for books.

So 625 symbols for metadata - isn't too much, will use item metadata instead of mod storage or similar thing.

[neoh4x0r]

(Also, 1024bytes is a little more than a kilobyte)

Well it has to do with how binary values are stored -- kilobyte (base-10) vs kibibyte (base-2).

1024 bytes to kilobytes = 1024 bytes / 1000 bytes/kilobyte = 1.024 kilobytes
1024 bytes to kibibytes = 1024 bytes / 1024 bytes/kibibyte = 1 kibibyte

When talking about physical storage or memory you always have to use whole powers of 2.

This is what hard-drive manufactures use to confuse people on storage space: 500 GB is actually 465.661 gibibytes.
You can't actually store 500 GB worth of data on the drive, would actually need ~ 536 GB.

[neoh4x0r]

An image of 32 x 32 pixels will need 1024 MB (1 GB) and a 64 x 64 image will be need more than 4096 MB (4 GB) of storage/memory.

Assumptions:
* 32-bit color depth (4 bytes per pixel: RGB+A)
* Raw byte encoding, bitmap-like
* No ^[combine strings or whatsoever

Calculation: size_MiB = 4 * width * height / 1024^2
Reverse: an image of 32768 pixels in width and height would result in your calculated 4 GiB.

Even ^[combine is more efficient than your calculations (~27x the byte count): https://github.com/minetest/minetest/issues/6821

Yes, I know......my brain was thinking megabyte when it was actually seeing kilobytes -- it was an I/O error.
64 x 64 = 4096 bytes = 4 kilobytes

Code: Select all

4 kilobytes = 4 * (2^10)               = 2^2 * 2^10 = 2^12 bytes ; sqrt(2^(12/2) ; 64x64
4 megabytes = 4 * (2^10 * 2^10)        = 2^2 * 2^20 = 2^24 bytes ; sqrt(2^(24/2) ; 4096x4096
4 gibabytes = 4 * (2^10 * 2^10 * 2^10) = 2^2 * 2^30 = 2^32 bytes ; sqrt(2^(32/2) ; 65536x65536