Author Topic: so how many k is bloat for you?  (Read 364 times)

mineiro

  • Member
  • ****
  • Posts: 577
Re: so how many k is bloat for you?
« Reply #15 on: May 20, 2020, 08:49:19 AM »
Nice.
The most easy way to speed up a program execution is by creating tables, precalculating things before so we can just move results. The problem is that tables give an increase in size of procedure.
When I as an eletronic addict I think that we can optimize by Karnaugh map, just transposing to assembly language.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

jj2007

  • Member
  • *****
  • Posts: 10260
  • Assembler is fun ;-)
    • MasmBasic
Re: so how many k is bloat for you?
« Reply #16 on: May 20, 2020, 09:12:10 AM »
Interesting.
You can hide a signature/watermark in the least significant bit of each color.

How would you do that, for example with \Masm32\examples\exampl04\car\car.jpg ?

mineiro

  • Member
  • ****
  • Posts: 577
Re: so how many k is bloat for you?
« Reply #17 on: May 20, 2020, 09:20:12 AM »
jpeg is lossy, we loose bits with that. But, after dumping to raw file that can be done if we save that as bmp, gif, png, ... (lossless).
In gif files we also have map color table, and most programs that read a gif file ignore what comes after ";", the last byte.
Jpeg2000 is a lossless solution, but I never played with that.

---edit---
I build an example to you son; please open image using hexadecimal editor.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

jj2007

  • Member
  • *****
  • Posts: 10260
  • Assembler is fun ;-)
    • MasmBasic
Re: so how many k is bloat for you?
« Reply #18 on: May 20, 2020, 10:40:58 AM »
jpeg is lossy, we loose bits with that

Yessss! And guess what happens if you send emails with photos in png, bmp or gif format instead of jpg? Our secret friends get very curious :bgrin:

I am working on a simple image and video viewer, see attachment - just drag any file over it. Without a commandline it will throw an error.

Compared to the standard M$ viewer in Win7, it's a lot faster, and the zoom function yields a better image quality. Feedback welcome, it's work in progress but already pretty stable. It works with animated GIF and TIFF images, too. I am particularly curious how it works with non-Ansi filenames, e.g. on Russian or Chinese systems.

- mousewheel zooms
- arrow up/down views other image files in the same folder and its subfolders, sorted by date
- arrow left/right and Shift up/down moves the zoomed image

P.S.: Thanks for the secret message, mineiro :thup:

Siekmanski

  • Member
  • *****
  • Posts: 2130
Re: so how many k is bloat for you?
« Reply #19 on: May 20, 2020, 06:01:04 PM »
mineiro, it's not a secret anymore.  :biggrin:

Jochen, I got this message,
Fatal error:
Line ???: Array erased or undefined
Creative coders use backward thinking techniques as a strategy.

jj2007

  • Member
  • *****
  • Posts: 10260
  • Assembler is fun ;-)
    • MasmBasic
Re: so how many k is bloat for you?
« Reply #20 on: May 20, 2020, 07:21:59 PM »
Jochen, I got this message,
Fatal error:
Line ???: Array erased or undefined

Without a commandline it will throw an error.

Siekmanski

  • Member
  • *****
  • Posts: 2130
Re: so how many k is bloat for you?
« Reply #21 on: May 20, 2020, 07:48:49 PM »
OK.  :thup:
Creative coders use backward thinking techniques as a strategy.

daydreamer

  • Member
  • *****
  • Posts: 1217
  • I also want a stargate
Re: so how many k is bloat for you?
« Reply #22 on: May 21, 2020, 08:08:06 PM »
Often I try to find ways to make executables as small as possible, just for the kick.
But most important is finding a balance between quality, speed and size.
Just for fun, I try to find repeating patterns in data to compress it to smaller sizes if possible.
Last month I was successful in writing an algorithm that compressed an old Amiga Protracker Music-note table.
16 * 3 octaves and finetune stages.
The original was 1152 bytes long, my algorithm routine to pre-calculate the table and inserting the errors back, is 127 bytes.
It wasn't easy because there were a lot of rounding errors in the original from the year 1987.
The result was 11% of the original size, this is what coding makes fun.  :eusa_dance:
great reduction :thumbsup:

Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
Gone serverside programming p:  :D
I love assembly,because its legal to write
princess:lea eax,luke
:)

daydreamer

  • Member
  • *****
  • Posts: 1217
  • I also want a stargate
Re: so how many k is bloat for you?
« Reply #23 on: May 22, 2020, 06:26:33 PM »
isnt this the best solution on modern cpu to not have unneccerary bitfiddling when you want it to run fast?also you dont want overhead of uncompress right before a invoke that needs it to be dword size
first you develop with data sizes that works good on modern cpus,bytes and dwords and qwords and octowords
when you get it working right and debugged it,start to reduce size and init proc that expands bits into bytes,dwords...,screencoordinates bytes/words->dwords
???

something that only need true/false can be placed as bits,instead of bytes,words and dwords,qwords


Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
Gone serverside programming p:  :D
I love assembly,because its legal to write
princess:lea eax,luke
:)

Siekmanski

  • Member
  • *****
  • Posts: 2130
Re: so how many k is bloat for you?
« Reply #24 on: May 22, 2020, 08:46:35 PM »
Thanks Magnus,

Sometimes you can get reasonable size reduction with creating pre-calculate lookup tables with indexed values such as used in 256 indexed colored pictures to represent larger bit values 32-64-128 and replace them with a byte/word stored as index number to reduce the size.
But sometimes the fastest and smallest way is to calculate it on the fly in code without lookup tables.
It all depends on the algorithm you create and the type of data you need to work with.
Write smart equations, simplify them to the max, removing all variables you can do without.
Try finding repeatable patterns and index them.
It's always fun to find a smart way to reduce data that doesn't fit so well in standard packing algorithms.

A great candidate for massive size reduction is 3D object vector data.
Symmetric objects you can store halve and mirror the other halve when depacking.
Some objects have many repeating 3D vector data, 8 tentacles can be saved as 1 and the other 7 can be translated in position when depacking etc.
Never store normals, calculate them when depacking.
Many object parts can be 100% calculated using trigonometric formulas and bend in shape with curve routines ( exp, sin cos combinations etc.)
Another cool technique is sub-division to remove vertices for storage and rebuild them when depacking.

Reducing bit depth without losing resolution:
For example, 8 bits is enough to represent a highly detailed vector object with a screen resolution of 10 bits.
If you create a 3 dimensional space divided in 3 by 3 by 3 cubes, you can reduce and store a 32 bit float as 8 bit ( subtracting the cube offset ) in each space cube,
when depacking add the xyz offset of each cube to the coordinates per cube to restore the original values and store them as floats in memory.
You don't need index numbers to identify the 27 cubes, only the coordinate count per cube to reconstruct the data.
If you divide the 3D space of the object in even more 3D cubes you can reduce the 3D object size even more.

Math rules!  :cool:
« Last Edit: May 22, 2020, 09:52:20 PM by Siekmanski »
Creative coders use backward thinking techniques as a strategy.