From
Evgeny Goljakov
→
To
Valerij Kozhevnikoff
4 October 2002
Hello Valerij.
Let's test it!
Question: If this is a storage format for indexed colors,
why then only B/W?
For example, the jpeg viewer conveyed colors by the distribution of pixel density and
There are no restrictions on the number of colors. Moreover,
that jpeg is an order of magnitude more difficult.
Give me a universal GIF viewer!!!
=====
If you have a document in Russian to get
general idea of this format or comparison
with his kind. Please drop it. Here or to the soap.
Thank you for your attention.
From
Valerij Kozhevnikoff
→
To
Alexandr Tkachev
15 October 2002
Hello, Alexandr!
14 Oct 02 00:56, Alexandr Tkachev -> Valerij Kozhevnikoff:
VK>> GIF image viewer 1.0b 256x192 B&W
VK>> (c) Jason 2002
VK>> I look forward to your wishes and bug reports.
AT> An excellent and very useful program, you often come across different circuits
AT> in this format, but there’s nothing to see, now thanks to you life will become
AT> a little easier THANK YOU... From the wishes, well, of course support for the top
AT> memory and the ability to cut out the desired piece... Of the bugs, everything seems to be ok
AT> maybe he doesn’t want to show some gifs, but these are probably just those
AT> which you mentioned.
There is only one serious bug. Amount of available lower memory
determined with an error of 260*6=1560 bytes. If you look at wide pictures -
the line buffer will creep onto the disk cache. This is what happens if there is an extra JR
comment...
1.1b does not have this drawback.
Now I will test the version for 512x192...
It works! Interlaced 512x384! People, remember this day - October 15, 2002
of the year! With the starting address of the program = 30700 in the bare (all
residents and driver for 64 characters) Idose version 3.5, memory for line buffer7460 bytes, which is enough for images 1800 pixels wide! XTR circuit
I just looked at the modem, and this is 1084x784 pixels, and there were only 4472 bytes
busy!
I click the screens every interruption. I’ll make the /g+ key right now so that it’s a gigaskrin
include.
* Originally written in REAL.SPECCY
* also sent to ZX.SPECTRUM
* also sent to ZXNET.SOFT
WBR, Jason.
/*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/
/np:/ *silence*
From
Valerij Kozhevnikoff
→
To
Evgeny Goljakov
17 October 2002
Hello, Evgeny!
04 Oct 02 14:00, Evgeny Goljakov -> Valerij Kozhevnikoff:
EG> Let's test it!
There are glitches there.
EG> Question: if this is a format for storing indexed colors,
EG> why then only B/W?
How is this "only"?
EG> For example, the jpeg viewer conveyed colors using the distribution of pixel density
And that’s what I have.
EG> Give me a universal GIF viewer!!!
EG> =====
EG> If you have a document in Russian to get
EG> general idea of this format or comparison
EG> with others like it. Please drop it. Here or to the soap.
256 colors, one bitplane.
Regular LZW compression. If you change the unpacker to RLE in the source code - PCX can be
watch.
WBR, Jason.
/*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/
/np:/ *silence*
From
Valerij Kozhevnikoff
→
To
Evgeny Goljakov
19 October 2002
Hello, Evgeny!
19 Oct 02 17:18, Evgeny Goljakov -> Valerij Kozhevnikoff:
EG>>> Let's test!
VK>> Glitches there.
EG> Then we'll test them too!
There were two serious bugs.
1. The amount of available lower memory was determined with an error of 260*6=1560
byte. If you look at wide pictures, the line buffer will creep onto the disk cache.
This is what happens if you comment out an extra JR...
2. The /b key did not work. EXX got lost
BRIGHT_KEY
> EXX this one.
INC HL
INC HL
PUSH HL
As a result, the brightness threshold turned out to be equal to the taken number of about 200.
VK>> 256 colors, one bitplane.
EG> Why is interlacing invented?
And x.z.
VK>> Regular LZW compression. If the source contains an unpacker in RLE
VK>> change - PCX can be viewed.
EG> And I naively believed that there was a minimum(!) Huffman :(
At offset +2 in the PCH there is a byte. If it =1, then RLE. Doc on him
show?
The encoding method is as follows:
FOR every X byte read from file
IF both high order bits of X are 1, then
= 6 least significant bits of X
= next byte after X
OTHERWISE = 1
= X
EG> Then maybe you know which format is more effective for indexed ones
EG> colors (<256), without loss of quality?
PNG.
WBR, Jason.
/*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/
/np:/ *silence*
From
Evgeny Goljakov
→
To
Valerij Kozhevnikoff
19 October 2002
Hello Valerij.
Thu 17 Oct 02 Valerij Kozhevnikoff -> Evgeny Goljakov:
EG>> Let's test it!
VK> Glitches there.
Then we’ll test them too!
EG>> For example, the jpeg viewer transmitted colors by distribution
EG>> point densities
VK> And that’s what I have.
Then it’s probably cool (no offense to chunk fans)
EG>> If you have a document in Russian to get
EG>> general idea of this format or comparison
EG>> with others like it. Please drop it. Here or to the soap.
VK> 256 colors, one bitplane.
Why was the interlacing invented?
VK> Regular LZW compression. If the source contains an unpacker in RLE
VK> change - PCX can be viewed.
And I, out of naivety, believed that there was a minimum(!) Huffman :(
Then maybe you know which format is more efficient for indexed colors
(<256), without loss of quality?
VK> WBR, Jason.
Thank you for your attention.
From
Valerij Kozhevnikoff
→
To
All
22 November 2002
Hello, All!
21 Oct 02 08:16, Valerij Kozhevnikoff -> Alexandr Tkachev:
VK>>> The process is near completion.
VK>>> I’m thinking of making a key /db to change the size of the disk buffer
VK>>> in sectors. Is it necessary? Or is 1 sector enough?
AT>> If you're not too lazy, do it of course.
VK> Laziness. 1.1. it will be without him, a lot has already been done there. I'll do it in 1.2.
The subject has been more or less settled.
The disk buffer has left 1 sector for now. On floppy computers it will slow down.
A screw or ramdisk is desirable.
What is now.
1. Works in IS-DOS Chic and classic.
2. Memory can handle up to 4 megabytes (256 pages). There are currently only drivers up to 1M.
3. Able to download .scr from the screen. The version for 512x192 screen unloads
monochrome unpacked .pcx 512x384. There is a PCX packer, but it’s not good
The shrinking pictures are glitching... So for now without it.
4. In addition, the version for an extended screen can display an image on
printer (if the driver is installed).
5. Well, Gigascreen is supported.
The printing/saving system can be easily disabled in the source code, so I’ll ask now:
are they needed? Because I feel sorry for the memory...
Now I’ll sit down to finish the manual and put everything in the archive. One of these days it will fly into an echo.
The license will be GPL.
WBR, Jason./*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/