Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Алгоритмы > конкурс для кодеров :)


Автор: oleg1973 6.8.2004, 19:09
ну так что будем делать конкурс или как?
задание уже есть
написать упаковщик для bmp 1024*768*24 бит
оцениватся будет скорость и степень сжатия, естественно надо и распаковать потом smile.gif
алгоритмы типа jpg и прочие с потерей данных не рассматриваются
язык програмирования неважен, наличие исходников приветствуется но не обязательно (ну вдруг там у вас суперпупер идея для комерч. использования)
кто переплюнет RAR по размеру и скорости получит 5 + в рейтинг biggrin.gif

кароче делаем ехе
main.exe -p somefile.bmp пакует
main.exe -d somefile.pak распаковывает

картинку для паковки выберем всеобщим голосованием smile.gif с сайтa playboy.com biggrin.gif biggrin.gif biggrin.gif


вопрос модераторам
может данный топик перенести из флейма? както он уж не флеймовый

Автор: Borland_Delphi_6 6.8.2004, 20:52
oleg1973
Поучавствовать не смогу, но с удовольствием понаблюдаю за ходом событий smile.gif Также могу предоставить сжимаемую картинку rolleyes.gif

Автор: oleg1973 6.8.2004, 21:07
значт так smile.gif
вот картинка http://digilander.libero.it/oleg1973/Water%20lilies.rar
ужата раром до 993 035 bytes
в нормальном виде 2 359 350 bytes

принимаются работы до 1 сентября smile.gif
между делом можете сообщать результаты промежуточные, типа для подогрева публики smile.gif

Автор: -=::BlackCat::=- 6.8.2004, 22:12
krasivaja kartinka, kst. u menja ee poka chto udolos sgat do 969 KB (993.030 Bytes) biggrin.gif
Добавлено @ 22:14
Xa dage do 825 KB (844.918 Bytes)

Автор: chipset 6.8.2004, 22:16
Цитата
кто переплюнет RAR по размеру и скорости получит 5 + в рейтинг

И пару штук баксов за проданные архиваторы tounge.gif
До первого сентября говоришь? Я вот немного разберусь с текущими проектами и попробую зачудитЪ smile.gif

Автор: oleg1973 6.8.2004, 22:19
-=::BlackCat::=-
Цитата
Xa dage do 825 KB (844.918 Bytes)

чем?

Автор: Borland_Delphi_6 6.8.2004, 22:22
oleg1973
Всякие CAB-MAN'ы и WinAc'ы вроде лучше рара сжимают smile.gif Или 7zip

Автор: -=::BlackCat::=- 6.8.2004, 22:43
kagetsja chto-to krupnoe namechaetsja, narod ne sowetuju wikladiwat ishodniki otkrito, nu a esli ug tak hochetsja no nuna nowij razdel, gde narod tolko za 200-250 nahoditsja mog bi, inache washi ideii mogut pribawit tjagesti chugim kormanam sad.gif

Автор: oleg1973 6.8.2004, 22:56
значит ставим новый предел 844.918 Bytes

Автор: maxim1000 6.8.2004, 23:34
Цитата
алгоритмы типа jpg и прочие с потерей данных не рассматриваются

jpeg может работать в режиме без потерь smile.gif
Добавлено @ 23:37
Цитата
кто переплюнет RAR по размеру и скорости получит 5 + в рейтинг

любой мало-мальский прдуманный алгоритм сжатия изображений переплюнет Rar, который универсален, именно из-за своей специализации

Автор: oleg1973 6.8.2004, 23:37
Цитата
jpeg может работать в режиме без потерь 

зато и жмет при этом не особо

Автор: Се ля ви 7.8.2004, 00:23
А если чувак надумает запихнуть данную картинку в екзешник, то сможет вообще ужать до 0 байт - только сверять имя файла и выдавать картику изнутри себя с размером 844.918 по раровскому, скажем, алгоритму wink.gif

Автор: cardinal 7.8.2004, 01:31
Цитата
оцениватся будет скорость и степень сжатия

Как скорость будет замерятся, если только main.exe есть?

А вообще с удовольствием приму участие в конкурсе. Если что скиньте сообщение по PM.

Автор: -=::BlackCat::=- 7.8.2004, 01:35
Се ля ви
Цитата
А если чувак надумает запихнуть данную картинку в екзешник, то сможет вообще ужать до 0 байт - только сверять имя файла и выдавать картику изнутри себя с размером 844.918 по раровскому, скажем, алгоритму


etu chifru RAR ne dostig, eto bil WINACE


cardinal
ti kagis na VB pishesh mnogo, popitaisja ego propihnut w chislo moshnih jazikow biggrin.gif

Автор: oleg1973 7.8.2004, 01:42
cardinal
думаю что скоростью в данном конкурсе можно и пренебреч

Автор: cardinal 7.8.2004, 01:44
Се ля ви, упаковщик - это не разбухальщик. smile.gif

Автор: cardinal 7.8.2004, 02:03
oleg1973, ну принебречь, так принебречь, но тогда конкурс несерьезным становится.

Так как картинка одна и таже, то соответственно можно под нее подстроится и выбрать алгоритм, который лучше всего ее ужимает. Тогда надо взять эту картинку для начала, а тестить потом по нескольким (причем допустим только тебе известным), тогда будет хоть на что-то похоже.
С другой стороны, если мы принебригаем временем, то можно вообще написать десяток алгоритмов и программа будет пять минут думать, а потом выдаст лучший результат. Тоже несерьезно.

Вобщем я за время и за качество.

Если время не играет никакой роли, то мне уже участвовать не интересно становится по описанным выше причинам.

Цитата
ti kagis na VB pishesh mnogo, popitaisja ego propihnut w chislo moshnih jazikow

-=::BlackCat::=-, не беспокойся. То с чем я пришел на это побоище написано (мною) на asm'e biggrin.gif
А вообще на VB пишу в последнее время очень мало. В основном только для форума.

Автор: maxim1000 7.8.2004, 10:00
предлагаю определиться с требованиями более конкретно:
потери
тут есть два варианта: допустимы и нет
если потери допустимы, то нужно указать, как искажение влияет на критерий оценки программы
класс изображений
вот действительно думал написать прогораммку с прицепленным файлом и показать, как я сжимаю его в 1 байт biggrin.gif, чтобы проиллюстрировать, что тестировать программу нужно на большом классе изображений.
например, для естественных изображений больше подходят алгоритмы вроде jpeg, для искусственных gif и т.д.
так что давайте определимся
предложение: давайте просто возьмем какой-то сайт с обоями (например, на тему природы) и будем сжимать их
проверять будем на нескольких изображениях
скорость
как она учитывается, как сильно влияет на критерий оценки программы, что важнее: скорость сжатия или скорость восстановления
размер программы
как оценивается, возможно, ограничен (еще один способ бороться с прицепленными файлами smile.gif )
----
я бы предложил сжатие без потерь - тогда их не нужно оценивать, а то совсем неочевидно, как именно это делать

Автор: RA 7.8.2004, 10:22
oleg идея хорошая но, почему именно картинку я к примеру могу написать архиватор (JPEGconВертор tounge.gif ) каторый без потерь уложит её примерно в 500kb. такчто у вас нет шансов. лучше посоревноваться на сжатии EXE'шников.

Автор: oleg1973 7.8.2004, 12:45
и так правила
1) сжатие без потерь, должно соответствовать 1*1
2) пока жмем тестовую картинку, в финале будет сделан тест на других картинках
3) время сжатия тоже будем оценивать
4) основная оценка размер выходного файла
к примеру баллы так можно начислить
размер+(время*1000)
5) размер ехе на баллы не влияет

время конкурса до 1 сентября

RAdmin
шансы у нас всегда есть smile.gif
а JPEGconВертор один фиг без потерь не сделает smile.gif

Автор: gepard 7.8.2004, 14:33
Цитата
кароче делаем ехе
main.exe -p somefile.bmp пакует
main.exe -d somefile.pak распаковывает

Обязательно так? А если я оформлю в Delphi?
Цитата
jpeg может работать в режиме без потерь

Не забывай, что он комерческий. Да и вообще, задолбаешься писать. Там у него 8 уровней сжатия. Хотя я подолбаюсь. Всё равно заняться особо не чем.

Автор: cardinal 7.8.2004, 15:49
Цитата(oleg1973 @ 7.8.2004, 11:45)
и так правила
1) сжатие без потерь, должно соответствовать 1*1
2) пока жмем тестовую картинку, в финале будет сделан тест на других картинках
3) время сжатия тоже будем оценивать
4) основная оценка размер выходного файла
к примеру баллы так можно начислить
размер+(время*1000)
5) размер ехе на баллы не влияет

время конкурса до 1 сентября

Я бы только немного уточнил. smile.gif

Баллы бы высчитывал так:
(Размер картинки после упаковки в байтах + (время в секундах на упаковку + на распаковку) * 100000) / 100000 и округлить до второго знака после запятой

Например:
размер картинки после упаковки 563400 байт
время на упаковку 1.234 сек
время на распаковку 3.542 сек
получаем: (563400 + 123400 + 354220) / 100000 = 10.4102 => 10.41 балла

Цитата
5) размер ехе на баллы не влияет

Размер картинки на размер exe тоже. smile.gif

Автор: gepard 7.8.2004, 16:06
Цитата
4) основная оценка размер выходного файла
к примеру баллы так можно начислить
размер+(время*1000)

Чего-то я пропустил этот пункт. А время-то зачем?
Время выполнения может зависить от ОЧЕНЬ многого.
Или тогда тестить надо всё в одно время и на одной тачке.

Автор: -=::BlackCat::=- 7.8.2004, 18:10
gepard
delphi proigrat 100% po wremeni, dumaju dage esli ti cherez ASM wstavki delat budesh sad.gif

Автор: <Spawn> 7.8.2004, 18:52
-=::BlackCat::=- Ни чего подобного - прочитав пол книги Криса Касперски "Оптимизация работы с памятью"(Ну просто супер книга - всем советую, написана классным языком и очень реально оптимизировать работу с памятью можно научиться - я проверял уже пару алгоритмов и даже в интерпертаторах есть прирост!!!!) я думаю, смогу оптимизировать алгоритм по скорости в несколько раз, если буду его делать(Все зависит от свобоного времени - на данный момент я делаю 2 проекта и еще работаю) smile.gif)

Автор: -=::BlackCat::=- 7.8.2004, 19:09
<Spawn>
dawai bodet ochen interesno gljanut smile.gif

Автор: Monty 7.8.2004, 19:18
Цитата
gepard
delphi proigrat 100% po wremeni, dumaju dage esli ti cherez ASM wstavki delat budesh sad.gif

Включи оптимизацию smile.gif

Автор: gepard 8.8.2004, 05:33
Блин, неужели придётся асм ковырять и с++ подключать... hmmm.gif

Автор: oleg1973 8.8.2004, 12:32
так ну все хватит трепатся, поехали!
3...2...1... старт!

Автор: RA 8.8.2004, 13:51
Пардон, я тут по делу выскажусь:

Но вые пределы_
Мне удалось раром сжать в 969 КБ (993 030 байт)
И WinAce-сом в 816 КБ (836 300 байт)

Цитата

gepard
delphi proigrat 100% po wremeni, dumaju dage esli ti cherez ASM wstavki delat budesh 

Сынок Делфи это Сила biggrin.gif . WinRAR и WinACE два мега лидера и оба написанны на делфях.

Автор: -=::BlackCat::=- 8.8.2004, 16:47
RAdmin
naschot delphi ja verju, prosto vidno ne figa ne umeju optimizirovat, kak ti WINACEom umudrilsja eshe 9 KB ubit?

Автор: oleg1973 8.8.2004, 18:02
как уже говорилось выше, язык в данном конкурсе не важен, хоть на Qbasic пишите
главное результат
ну и желательно свой алгоритм,так как переписывание заново LZW не совсем то что требуется smile.gif
мой результат пока шибко скромный примерно 1,500 , но будем старатся smile.gif

Автор: RA 9.8.2004, 05:29
Цитата
naschot delphi ja verju, prosto vidno ne figa ne umeju optimizirovat, kak ti WINACEom umudrilsja eshe 9 KB ubit?

WinAce версии 2.6B. если у тебя таже версия то нужно будет порыться в настройках компресси.

Добавлено @ 05:35
oleg1973

Алгоритм сжатия PPM (а он круче зипа) выдаёт:
1,45 МБ (1 521 193 байт)

поэтому я думаю, что дальше этой цифры никому не светит уйти.

Автор: oleg1973 9.8.2004, 11:09
Цитата
поэтому я думаю, что дальше этой цифры никому не светит уйти.

ну а как же WinAce c 800kb ?
переписав LZW олучим примерно тожесамое , а PPM тоже не панацея smile.gif

Автор: maxim1000 9.8.2004, 11:23
Цитата
Алгоритм сжатия PPM (а он круче зипа) выдаёт:
1,45 МБ (1 521 193 байт)
поэтому я думаю, что дальше этой цифры никому не светит уйти.


и в чем тут крутость?
до такого размера сожмет любой энтропийный кодировщик по той простой причине, что картинка непростая smile.gif
если внимательно посмотреть на значения пикселей, можно увидеть, что, скорее всего, камера, которой все этой снимали, была 5-ти битной smile.gif
Добавлено @ 11:25
кстати, как мне кажется LZW и прочие словарные методы тут не пройдут - это же вам не текст

Автор: oleg1973 9.8.2004, 16:53
так пора список участников составить
1) я-Oleg1973
2) cardinal
3) ?

Автор: maxim1000 9.8.2004, 17:06
Цитата
так пора список участников составить

а зачем?
кто пришлет, тот и участник


Автор: cardinal 9.8.2004, 17:26
oleg1973, дописывай cardinal smile.gif

Автор: RA 9.8.2004, 20:58
Цитата(oleg1973 @ 9.8.2004, 11:09)
ну а как же WinAce c 800kb ?
переписав LZW олучим примерно тожесамое , а PPM тоже не панацея smile.gif

До винАса как до Генуи из Милана пешком.

PPM это и есть переписанный zLIB, причем не за короткий срок.
и поскольку единсвенное что светит каждому из нас ( переписать zLIB smile.gif ) , то можно не замахиваться на таких гигантов как рар с асом.

Автор: AndyY 9.8.2004, 23:29
картинка была предварительно сжата JPEG, а потом распакована.
это очевидно из гистограмм по YUV. Вопрос - мы будем пережимать уже сжатые до нас c потерями картинки или пишем общий алгоритм?

Автор: RA 9.8.2004, 23:56
AndyY забей на картинку, она просто как ориентир для того чтобы можно было похвастаться.

Автор: GrayCardinal 10.8.2004, 12:17
oleg1973
запишите в список участников... буду RLE изучать wink.gif в общем, на главный приз не претендую, но поучаствовать будет интересно... biggrin.gif

Автор: oleg1973 10.8.2004, 14:30
RAdmin
нееее PPM и zLib этож как пуля и г... отличатся
AndyY
как справедливо заметил RAdmin
картинка так для орентиру smile.gif

ГОСПОДА УЧАСТНИКИ! еще раз напоминаю что жмем картинку, и это дает нам некие перспективы, если учитывать особенности именно картинки а не просто набора данных

Автор: GrayCardinal 11.8.2004, 10:50
oleg1973
Трабл возник - картинка не грузится. Как Линуксоид - качал в Линуксе, а мне она выдает ее просто как текст (смотрит его и все тут") пробовал даже wget-ом - нифига, "неправильный формат". если не сложно, зазипь ее... А то все по ней меряют результат...

Какие готовые алгоритмы можно использовать а какие нет ? Если я сам напишу то-же дерево Хаффмана (простой линукс-gzip), Пройдет на конкурс ? Или что сможешь реализовать без сдирания с уже готового кода (не алгоритма) то и делаешь ?

Автор: oleg1973 11.8.2004, 18:45
задача ужать как можно лучше smile.gif
можеш и Хаффмана написать, я к примеру сижу вот свой выдумваю smile.gif
пока тяжко smile.gif

Автор: chaos 13.8.2004, 15:00
а че за картинка??
Добавлено @ 15:00
Цитата(chaos @ 13.8.2004, 15:00)
а че за картинка??

дайте посмотреть

Автор: lynx_916 13.8.2004, 22:15
если у тя ХР, не ищи, она где-то по папкам.
Водяные лилии называется

Автор: chipset 13.8.2004, 23:40
.... я не опоздал, нет?
набор ещё не закончился? tounge.gif

Автор: cardinal 14.8.2004, 00:00
Цитата(chipset @ 13.8.2004, 22:40)
.... я не опоздал, нет?

Я думаю главное во время выложить работу. smile.gif

Автор: oleg1973 14.8.2004, 13:30
ну че результаты у кого какие?

Автор: GrayCardinal 18.8.2004, 15:22
Цитата
ну че результаты у кого какие?

почитай - ноль. только много интересного узнал и все. В общем простой модифицированный RLE теоретически может ужать на метр (по максимуму). Одинаковые пикселы искать нереально. Даже если по шесть старших бит совпадение искать. вот если бы потом выкинуть младшие два бита... мммммм не такие ужо и потери, по-мойму biggrin.gif

Автор: shedon 19.8.2004, 19:47
а как вы время собираетсь замерять, верить экзешнику или как, может тогда лучше в длл зделать ?
допустим длл будет экспортировать функцию
int Compress(char *psInputFile, char *psOutpFile);
и
int Decompress(char *psInputFile, char *psOutpFile);
в случае успеха функция возвращает 1 иначе 0
тогда напишем прогу exe, естсетвенно с открытым кодом для проверки dll и она же будет и время замерять ?
Цитата
наличие исходников приветствуется но не обязательно

А как тогда определить, что алгоритм не варованный ?

Автор: cardinal 19.8.2004, 23:39
Цитата(shedon @ 19.8.2004, 18:47)
в случае успеха функция возвращает 1 иначе 0

то есть наоборот smile.gif
Цитата(shedon @ 19.8.2004, 18:47)
int Compress(char *psInputFile, char *psOutpFile);
и
int Decompress(char *psInputFile, char *psOutpFile);

Кто-нибудь может этот файл dll в исходнике сюда выложить? Мы тогда возьмем эту рамку и вместо
Код
int Compress(char *psInputFile, char *psOutpFile)
{};

напишем свои функции. Тогда будет у всех одинаково.

Автор: GrayCardinal 20.8.2004, 07:25
Цитата
а как вы время собираетсь замерять

а в чем проблема ? не думаю что стоит считать ms, просто прогнать через прогу N (> 1000 biggrin.gif)файлов а там можно и по секундомеру.

Цитата
А как тогда определить, что алгоритм не варованный

не думаю что все "зажмут" алгоритмы... если он не круче JPG, конечно... а по алгоритму видно будет - на сколько он ворованный...

Автор: shedon 20.8.2004, 09:34
Цитата
Кто-нибудь может этот файл dll в исходнике сюда выложить?

А что выкладывать каждый будет писать на своём языке, это тогда надо выкладывать на всех языках...
Цитата
Цитата
в случае успеха функция возвращает 1 иначе 0

то есть наоборотsmile.gif

Почему наоборот ? Хотя это уже кому как больше нравится, но, вроде, принято именно так делать...

Автор: cardinal 20.8.2004, 16:28
Цитата(shedon @ 20.8.2004, )
Почему наоборот ? Хотя это уже кому как больше нравится, но, вроде, принято именно так делать...

Я привык, что не ноль - это ошибка, вот как здесь например (MSDN):
Цитата
atexit
Processes the specified function at exit.

int atexit( void ( __cdecl *func )( void ) );

Routine Required Header Compatibility
atexit <stdlib.h> ANSI, Win 95, Win NT


For additional compatibility information, see Compatibility in the Introduction.

Libraries

LIBC.LIB Single thread static library, retail version
LIBCMT.LIB Multithread static library, retail version
MSVCRT.LIB Import library for MSVCRT.DLL, retail version


To generate an ANSI-compliant application, use the ANSI-standard atexit function (rather than the similar _onexit function).

Return Value

atexit returns 0 if successful, or a nonzero value if an error occurs.

Parameter

func

Function to be called

Remarks

The atexit function is passed the address of a function (func) to be called when the program terminates normally. Successive calls to atexit create a register of functions that are executed in LIFO (last-in-first-out) order. The functions passed to atexit cannot take parameters. atexit and _onexit use the heap to hold the register of functions. Thus, the number of functions that can be registered is limited only by heap memory.

Example

/* ATEXIT.C: This program pushes four functions onto
* the stack of functions to be executed when atexit
* is called. When the program exits, these programs
* are executed on a "last in, first out" basis.
*/

#include <stdlib.h>
#include <stdio.h>

void fn1( void ), fn2( void ), fn3( void ), fn4( void );

void main( void )
{
  atexit( fn1 );
  atexit( fn2 );
  atexit( fn3 );
  atexit( fn4 );
  printf( "This is executed first.\n" );
}

void fn1()
{
  printf( "next.\n" );
}

void fn2()
{
  printf( "executed " );
}

void fn3()
{
  printf( "is " );
}

void fn4()
{
  printf( "This " );
}


Output

This is executed first.
This is executed next.


Process and Environment Control Routines

See Also   abort, exit, _onexit

Да и вообще если создать в том же MS VS компиляторе новый проект, то он вывалит парочку файлов, а в main написано следующее:
Код
#include "stdafx.h"

int main(int argc, char* argv[])
{



return 0;
}

То есть как бы: нет ошибок - return 0.

Автор: shedon 20.8.2004, 17:52
Ну это крорее усключение из правила, т.к. 0x00 Это нормалтьное завершение потока/процесса, аты посмотри что возращают все апи функции... Честно говоря у меня был один большой проект, в котором я по глупости зделал, что 0 это нормальное завершение функции, а ысе апи фуенкции у меня возвращали 1, не очень красиво получилось, после этого я взял за правио, что любая функция в случае успеза должна возвращать 1, хотя это всё на любителя. Но это всё оффтоп. А по поводу сабжа, я думаю тут врядли удасться кому либо изобрести новый алгоритм, скорее всего будет некая модификаци/оптимизация одного из известных алгоритмов....

Автор: GrayCardinal 21.8.2004, 10:09
Люди, поделитесь успехами ! А то вырезано цензурой тут с изобретением нового алгоритма и ничерта... у кого что-нибудь рабочее уже есть ?

Автор: cardinal 29.8.2004, 12:47
Похоже, что я не укладываюсь в сроки sad.gif...

На это появилось по ходу дела две причины:
1. оказалось, что то что я хотел использовать было сделано мной для 4 и 8 битных bmp'шек. С 24 надо придумывать другой способ сжатия. Когда я попробовал сжать по принципу, того каким можно ужать (причем неплохо) 8 битные картинки я получил файл на 100 Kb больше, чем тот который сжимал smile.gif Причем он разжимается правильно!
2. как всегда напряг со временем

Вот так-то... Можно было бы взять что-нибудь готовое, но это было бы нечестно. А на то, чтобы прочитать на чем построены другие (не те которые я уже делал) алгоритмы сжатия и их реализацию времени к сожалению нет...

Если бы мы сжимали 8 битную картинку... smile.gif

Автор: oleg1973 29.8.2004, 13:09
я сделал так
разбиваем на RGB
делаем кусок памяти А равный размеру картинки/8 тоесть 1024*768/8
зануляем его
потом берем наш цвет R примеру
находим все 0 и ставим соответствующие им биты в куске А
и так до 255
получим 0xff кусков заполненых 0 и коегде 1
можно ужать даже RLE biggrin.gif
и так же для G и B
осталось додумать суперRLE
так как в данный момент результат не особо
1100 кб
даже стыдна перед winace biggrin.gif biggrin.gif biggrin.gif

Автор: Girder 30.8.2004, 13:39
oleg1973 я тоже не успеваю. Может и правду сроки продлить?

Автор: oleg1973 30.8.2004, 15:23
ну давай продлим smile.gif
на скока?

Автор: Girder 30.8.2004, 16:31
Ну я думаю не более чем на месяц rolleyes.gif .

Автор: Sardar 30.8.2004, 22:34
Не знаю даст ли это хорошее сжатие: BWT сжатие(сдвиг/сортировка) - получаем данные лучше сгруппированные по однотипным значениям, сжимаем методом RLE(или круче PPM, но это сложно), анализируем данные, находим участки чисел разница которых не велика(оценивать лучше как 16, 24 битные значения), для ущастков задаем смещение, а затем небольшие значения относительно смещения(это даст при хорошем раскладе ~25% сжатия).
Jpeg не догонать, но rar, ace наверное метод сделает.

Добавленно: 25% в смысле для простого сжатия участки/смещения, сколько будет все сразу сказать трудно.

Автор: oleg1973 31.8.2004, 09:35
Sardar
джепг не в счет там с потерями, а тот который без потерь джпег жмет не лучше рара

Автор: shuricus 27.9.2004, 06:55
Народ, а че, уже всё закончилось?
Тогда где можно посмотреть результаты?
Если же нет, то я тоже хочу поучаствовать :)

Автор: cardinal 27.9.2004, 08:15
Я все таки схожу с динстанции, т.к. не хватает времени...

Автор: asdf 29.9.2004, 21:07
кто-нить получил меньше 794287?

Автор: chipset 30.9.2004, 02:58
я уже месяц здесь не был, вообще времени НЕТУ...

Автор: Girder 1.10.2004, 11:46
Цитата
Тогда где можно посмотреть результаты?
shurick у меня лично результаты пока не очень... так что похвастаться не могу. Но буду продолжать мучить алгоритм. Вроде у oleg1973 результат получился не плохой. oleg1973 надо бы как то обговорить, как выкладывать(достойные) исходники и результаты. И определится в каком случаи(т.е. при каком сжатии - размере) выкладывать.

Автор: shuricus 1.10.2004, 13:34
у меня пока ~810 000 :) но и то только потому, что картинку вы выбрали не фонтан - она слишком гладкая (выглядит как получена из 800x600 ресайзом).

Автор: oleg1973 1.10.2004, 17:02
у меня как я уже писал примерно 1100 кб sad.gif
будем думать biggrin.gif

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)