База данных по кораблям.

apple17> Мне не нравится
apple17> - лучше почесать репу и придумать движок для мегасправочника.

По мне навалхистори хоть и технологичный, но ИМХО не удобный.
Да и данных маловато

apple17> Потом в него сандалить хоть самолетики хоть танчики хоть кораблики (ведь разницы никакой нет)

Это долго мучиться придется.
Или делать универсальный движок - объектно ориентированный
с наследвоанием класс / тип / корабль
с универсальным набором
характеристика / значение

Оно так надо?

apple17> WIKI вид сбоку это не решение, хоть и позволяет быстро набить что-то.

Пока это попытка выработать приемлемую форму. Хоть и получается что-то близкое к вике, но чем подобный вид не устраивает?

ИМХО нужно определиться с полями БД - т.е. теми, которые можно будет обрабатывать.
А без описания никуда не денешься.
И в поисании круче движка HTML что-то нужно разве?

П.С. А что на просторах интернета больше всего понравилось. Неужто навалхистори?

sas1975kr> Да и данных маловато
Данных там целый Конвей запихан - естественно в основном англосаксы
Есть прикольные штуки типа срез как работала конкретная верфь в конкретный период.

sas1975kr> Это долго мучиться придется.
sas1975kr> Оно так надо?

Мне надо чтобы можно забить любые факты - есть известные частные задачи
- например просеять советские мемуары - там ведь сотни фамилий и разных мелочей которые в голове не удержишь.
Или делать запросы по времени - где какие корабли были на такую-то дату например.
Или собирать достоверность источников по случаям разрешения противоречий и
получить числовые подверждения того, что Джейн регулярно врет и не читает региональную прессу,
а в арбузовках фото подписывают не напрягаясь.
Классификация это детский сад, даже если брать самую яркую - таких сайтов десятки.

В принципе что делать понятно - добавлять сущности динамически
(хоть объектную структуру ваять и потом мапить в реляционную базу, хоть сразу таблицы цеплять).
Может что-то фришное такое удобное есть - не интересовался. Вебморду к нему прикрутить как бы не самое сложное.
Пару лет забивать целыми книжками и справочниками. А потом уже кайф получать - строить запросы
разные. Но тут надо фанатом быть - я пока не созрел - из фотографий никак не выпутаюсь, а там ведь всего
пяток полей на фото Кстати был ведь кто-то на форуме пяткой себя в грудь бил что все уже придумал
и база у него все вопросы закрывает - договорится и опубликовать.

apple17> Данных там целый Конвей запихан - естественно в основном англосаксы

Как-то маловато ИМХО. Может не все раскопал....

apple17> Есть прикольные штуки типа срез как работала конкретная верфь в конкретный период.

Ну это допустим по датам закладки / спуска на воду и заводским номерам уже можно делать...

apple17> Мне надо чтобы можно забить любые факты - есть известные частные задачи

Все и любые - ИМХО нереально...

apple17> - например просеять советские мемуары - там ведь сотни фамилий и разных мелочей которые в голове не удержишь.

Люди и даты - это хорошо и нужно. А что еще в мелочах?

apple17> Или делать запросы по времени - где какие корабли были на такую-то дату например.

С этим сложно. Как быть при походах? Задавать точки маршрута с датами? Если точек будет мало - достоверность данных невелика. Есть конечно схемы поминутные боев - но это ИМХО делать нужно отдельным функционалом.

apple17> Или собирать достоверность источников по случаям разрешения противоречий и

В принципе тоже можно. Но база будет пухлая...

apple17> получить числовые подверждения того, что Джейн регулярно врет и не читает региональную прессу,
apple17> а в арбузовках фото подписывают не напрягаясь.
apple17> Классификация это детский сад, даже если брать самую яркую - таких сайтов десятки.

Пока не понятно что будет. Рассматриваются любые предложения.

sas1975kr> Люди и даты - это хорошо и нужно. А что еще в мелочах?

Советские мемуары отражают действительность очень выборочно.
Однако их достаточно много и информация перекрывается.
Хочется автоматически
0. Составить хоть какие-то списки людей - царские мичманы они все на учете, а советских лейтенантов
никто никогда не считал
1. Выловить более достоверные версии (соответственно определить авторов-сказочников)
2. Собрать данные в кучу дабы не держать их в голове

sas1975kr> С этим сложно. Как быть при походах? Задавать точки маршрута с датами? Если точек будет мало - достоверность данных невелика. Есть конечно схемы поминутные боев - но это ИМХО делать нужно отдельным функционалом.

Что известно то и задавать - есть точка - точку - есть сообщение типа
"в первых числах августа лодка стояла в Таллине" - так и заводить
Схемы боев это отдельное развлечение - у них низкая достоверность
- это другая сущность вообще

sas1975kr> В принципе тоже можно. Но база будет пухлая...
База да будет пухлая - больше фактов - больше пользы

sas1975kr> Пока не понятно что будет. Рассматриваются любые предложения.

На мой взгляд нужно слепить схему обычной реляционной базы
пусть будет 200 табличек для начала.
Можно сразу с базой не связываться -
дать просто описание на уровне объектов - замапить в базу это работа техническая.
Потом нужно иметь примеры как реальные факты будут ложится в базу.
Прогнать через нее какой-нибудь справочник по железкам и какой-нибудь
номер Тайфуна чтобы людей поднять.
Быть готовым постоянно добавлять новые сущности в схему объектов.

Пример - одиночная фотография

У нее что есть
Общее:
Название (подпись)
Автор - отсылка к табличке людей
Дата (дата и время) (хитрый тип данных - может быть точной, может приблизительной, может быть точкой а может интервалом (при том что точка это тоже интервал))

Технические параметры - широта, высота, DPI, URI файла в хранилище и тп

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

Сведения о происхождении фото - в обратном порядке - кто оцифровал,
если из книжки то из какой, если есть негатив то где.
Тоже отсылки к людям, архивам, книжкам, издательствам.

Те табличек 10 уже есть
Это в области где обычно обходятся одной строчкой.

Capt(N)> пока слушаем мнения и предложения ...
А почему бы не попробовать по образцу и подобию тактического формуляра корабля, не глупые же люди придумали эту форму, все основные даты, ттд, фотографии?

apple17> На мой взгляд нужно слепить схему обычной реляционной базы
apple17> пусть будет 200 табличек для начала.
вот этого я вам категорически не рекомендую. как пациэнтЪ.
табличек должно быть мало (в идеале - одна)
будут они, правда, при этом ооочень жирными.

вам поможет, если это будет выглядеть так? :

1. <c type="ship">
2. <n t="ship_id.name" v="Севастополь" l="r"/>
3. (<n t="ship_id.bnum" v="зав. № 794"/>).
4. <n t="work.ssz" v="ССЗ §им. А. А. Жданова§ (г. Ленинград)"/>
5. <c type="bld">
6. <bld1><d t="dmy" v="1966.06.08">08.06.1966</d></bld1> г.;
7. <bld2><d t="dmy" v="1967.04.28">28.04.1967</d></bld2> г.;
8. <bld3><d t="dmy" v="1969.09.25">25.09.1969</d></bld3> г.
9. </c>
10. <c type="ship_note">
11. После вступления в строй входил в состав <x t="x" v="СФ"/>, а
12. с <d t="dmy" v="1980.02.11">11.02.1980</d> г. - в состав <x t="x" v="ТОФ"/>.
13. Перешел из Мурманска во Владивосток по Севморпути в <d t="y" v="1981">1981</d> г.
14. <d t="dmy" v="1989.12.15">15.12.1989</d> г. <sc0>корабль</sc0> из-за износа материальной части и отсутствия средств на проведение среднего ремонта был исключен из боевого состава флота и передан <x t="x" v="ОФИ"/> для утилизации.
15. </c>
16. </c>

apple17> Прогнать через нее какой-нибудь справочник по железкам и какой-нибудь

1. <c type="weapon_tbl">
2.  
3. <weapon_dsk> Основные характеристики зенитных ракетных комплексов </weapon_dsk>
4.  
5. <c type="weapon_tbl_hdr">
6. <h>Наименование комплекса (индекс <x t="x" v="ЗУР"/>)</h>
7. <h>Назначение</h>
8. <h>(год принятия на вооружение)</h>
9. <h>Длина <x t="x" v="ЗУР"/>, м</h>
10. <h>Максимальный диаметр <x t="x" v="ЗУР"/>, м</h>
11. <h>Количество ступеней <x t="x" v="ЗУР"/>, ед.</h>
12. <h>Стартовая масса <x t="x" v="ЗУР"/>, кг</h>
13. <h>Дальность стрельбы, км</h>
14. <h>Высота стрельбы, м</h>
15. <h>Скорость полета <x t="x" v="ЗУР"/>, м/с</h>
16. <h>Скорость полета цели, м/с</h>
17. <h>Двигатель 1-й ступени</h>
18. <h>(2-й ступени <x t="x" v="ЗУР"/>)</h>
19. <h>Тип <x t="x" v="БЧ"/></h>
20. <h>Масса <x t="x" v="БЧ"/>, кг</h>
21. <h>Система наведения</h>
22. <h>Тип <x t="x" v="ГСН"/></h>
23. <h>Дальность действия <x t="x" v="ГСН"/>, м</h>
24. <h>Количество каналов по цели , ед.</h>
25. <h>(темп стрельбы, с)</h>
26. <h>Тип <x t="x" v="ПУ"/> (количество направляющих, ед.)</h>
27. <h>Носители</h>
28. </c>
29.  
30. <c type="weapon">
31. <v><n t="x" v="Волна" q="1"/> [1|460] (В 600)</v>
32. <v><x t="x" v="БД"/></v>
33. <v>(<d t="y" v="1962">1962</d>)</v>
34. <v>5,89</v>
35. <v>0,61</v>
36. <v>2</v>
37. <v>923</v>
38. <v>4 - 15</v>
39. <v>100 - 10000</v>
40. <v>~700</v>
41. <v>600</v>
42. <v><x t="x" v="ПРД"/></v>
43. <v>(<x t="x" v="ПРД"/>)</v>
44. <v><x t="x" v="ОФ"/></v>
45. <v>60</v>
46. <v><x t="x" v="РКМ"/></v>
47. <v><nul_v /></v>
48. <v>1000</v>
49. <v>1</v>
50. <v>(30)</v>
51. <v>палубная наводящаяся (2)</v>
52. <v><sc8>БПК</sc8> <n t="ship_prj" v="пр. 61"/>, <n t="ship_prj" v="пр. 61М"/>, <n t="ship_prj" v="пр. 61МП"/>, <n t="ship_prj" v="пр. 57А"/></v>
53. </c>
54.  
55. </c>

apple17> Пример - одиночная фотография
apple17> У нее что есть
apple17> Общее:
apple17> Название (подпись)
apple17> Автор - отсылка к табличке людей
...
apple17> Технические параметры - широта, высота, DPI, URI файла в хранилище и тп
apple17> Подробное текстовое описание что на фото - список отсылок
apple17> на объекты (это корневой объект иерархии - люди, коробки, место и тп)

1. <c type="pic_sheme">
2. <pic_dsk>Схема общего вида <sc8>РКР</sc8> <n t="ship_id.name" v="Грозный" l="r"/> по состоянию на <d t="y" v="1974">1974</d> г. и (вверху) и после модернизации (внизу)</pic_dsk>
3. <s n="1"><x v="РБУ-6000"/></s>
4. <s n="2"><x t="x" v="ПУ"/> <x t="x" v="ЗРК"/> <n t="x" v="Волна" q="1"/></s>
5. <s n="3">обтекатель антенны <x t="x" v="ГАС"/> <n t="x" v="Геркулес-2М" q="1"/></s>
6. <s n="4"><x t="x" v="ПУ"/> <x t="x" v="ПКРК"/> <x v="П-35"/></s>
7. <s n="5">обтекатель антенны станции <x t="x" v="ЗПС"/></s>
8. <s n="6"><x t="x" v="АП"/> <x t="x" v="РЛС"/> <n t="x" v="Дон-2" q="1"/></s>
9. <s n="7">ходовая рубка</s>
10. <s n="8"><x t="x" v="АП"/> <x t="x" v="РЛС"/> <x t="x" v="СУ"/> <n t="x" v="Ятаган" q="1"/></s>
11. <s n="9">оптический перископический визир боевой рубки (<x t="x" v="РКП"/>)</s>
12. <s n="10">оптический перископический визир ходовой рубки</s>
13. <s n="11">ходовой мостик</s>
14. <s n="12"><x t="x" v="АП"/> <x t="x" v="РЛС"/> <x t="x" v="СУ"/> <n t="x" v="Бином" q="1"/></s>
15. <s n="13"><x t="x" v="АП"/> станции <n t="x" v="Ограда" q="1"/></s>
16. <s n="14"><x t="x" v="АП"/> <x t="x" v="РЛС"/> <n t="x" v="Ангара" q="1"/></s>
17. <s n="15"><x t="x" v="АП"/> радиопеленгатора</s>
18. <s n="16">30-мм <x t="x" v="АУ"/> <x v="АК-630М"/></s>
19. <s n="17"><x t="x" v="АП"/> <x t="x" v="РЛС"/> <x t="x" v="СУАО"/> <n t="x" v="Вымпел" q="1"/></s>
20. <s n="18">533-мм <x t="x" v="ТА"/></s>
21. <s n="19"><x t="x" v="АП"/> системы <n t="x" v="Успех-У" q="1"/></s>
22. <s n="20"><x t="x" v="АП"/> станции <n t="x" v="Залив" q="1"/></s>
23. <s n="21"><x t="x" v="АП"/> станции <n t="x" v="Бизань-4Д" q="1"/></s>
24. <s n="22">45-мм салютная пушка</s>
25. <s n="23"><x t="x" v="АП"/> <x t="x" v="РЛС"/> <x t="x" v="СУАО"/> <n t="x" v="Турель" q="1"/></s>
26. <s n="24">76-мм <x t="x" v="АУ"/> <x v="АК-726"/></s>
27. <s n="25">вертолет <x t="2" v="Ка-25"/></s>
28. </c>

apple17> Дата (дата и время) (хитрый тип данных - может быть точной, может приблизительной, может быть точкой а может интервалом (при том что точка это тоже интервал))
это излечимо:

1. <bld1><d t="dmy" v="1966.06.08">08.06.1966</d></bld1> г.;
2.  
3. либо
4.  
5. <d t="ny" v="2000.07">июль 2000</d>
6.  
7. либо
8.  
9. <d t="y" v="1972">1972</d>
10.  
11. либо
12.  
13. "Во второй половине <d t="e" v="1980">1980-х</d> годов"
14.  
15. и т.п.

apple17>> пусть будет 200 табличек для начала.
ko4evnik> вот этого я вам категорически не рекомендую. как пациэнтЪ.
Как доктор замечу, что таблицы в БД должны все же удовлетворять хотя бы 2-й НФ. Лучше - 3-й.
Тогда база действительно будет удобной и расширемой. Обратное чаще всего свидетельствет, о
не законченном анализе структуры объектов. Чаще всего это приведет к проблемам в дальнейшем.
А большую единую табличку для просмотра (да и дла редактироваия) легко собратиь из таблиц 3НФ.

apple17>>> пусть будет 200 табличек для начала.
ko4evnik>> вот этого я вам категорически не рекомендую. как пациэнтЪ.
LtRum> Как доктор замечу, что таблицы в БД должны все же удовлетворять хотя бы 2-й НФ. Лучше - 3-й.
как ботаник - доктору, замечу что БД не обязана быть реляционной с ее нормально/ненормальными формами.

LtRum> Тогда база действительно будет удобной и расширемой. Обратное чаще всего свидетельствет, о
LtRum> не законченном анализе структуры объектов.Чаще всего это приведет к проблемам в дальнейшем.
проблема в том что анализ структуры не может быть "закончен" в принципе. он может быть только "ограничен" жесткими рамками. которые неизбежно придется в дальнейшем ломать.

были, к примеру, корабли и были самолеты. а потом появились гидросамолеты, экранопланы и суда на подводных крыльях.
были ЗРК и ЗАК. а потом внезапно появился ЗРАК.

вы на каждую вновь появившуюся "помесь" предлагаете заводить отдельную табличку? или наоборот - склеивать пересекающиеся таблицы все-в-одну?

LtRum> А большую единую табличку для просмотра (да и дла редактироваия) легко собратиь из таблиц 3НФ.
ну, скажем, sql-запрос-на-чтение к 20..30 табличкам написать вполне в моих силах. а вот запрос-на-модификацию к 200 - слегка превышает мою квалификацию.

уважемый Apple описал вполне конкретные соображения. но про "200 табличек" он загнул...

то что он предлагает вполне можно осуществить.
взять книжку/справочник/статью и вусмерть его утэгировать. можно - ручками. а можно применить информатику-кибернетику и прочую автоматизацию (я для себя программку для этой надобности писал).

скажем, регулярное выражение:

1. [А-ЯЙ]+-\d+

найдет в тексте все обозначения вида А-10, К-141, РБУ-6000 и т.п.

1. ([А-ЯЙ]\. *?){1,2}[А-ЯЙ][а-яй]+(-[А-ЯЙ][а-яй]+)*

- все что похоже на фамилии от "В.Ленин" до "Г. Г.Мамонтов-Прибой-Зданович-Довгопятко".

потом - шерстить эти тэги и составлять пресловутые "таблички". только будут они - всего лишь первым этапом дооолгого пути.

Вопрос в русле дискуссии:
1) Применяют ли уважаемые соратники в своих коварных целях какие-либо программки поиска и изничтожения дубликатов файлов и в частности файлов изображений?
2) чего им в этих программках не хватает?

ko4evnik> Вопрос в русле дискуссии:
ko4evnik> 1) Применяют ли уважаемые соратники в своих коварных целях какие-либо программки поиска и изничтожения дубликатов файлов и в частности файлов изображений?

Ну раз пошла такая пьянка, может товарищи поделитесь? Кто-какое программное обеспечение использует для своего хобби?

LtRum>> Тогда база действительно будет удобной и расширемой. Обратное чаще всего свидетельствет, о
LtRum>> не законченном анализе структуры объектов.Чаще всего это приведет к проблемам в дальнейшем.
ko4evnik> проблема в том что анализ структуры не может быть "закончен" в принципе. он может быть только "ограничен" жесткими рамками. которые неизбежно придется в дальнейшем ломать.
И как только банки живут годами? А ВМС США с ее внутренними БД? А предприятия? Если все сделано правильно, то нужно будет не ломать, а расширять, оставляя старое в качестве ядра.

LtRum>> А большую единую табличку для просмотра (да и дла редактироваия) легко собратиь из таблиц 3НФ.
ko4evnik> ну, скажем, sql-запрос-на-чтение к 20..30 табличкам написать вполне в моих силах. а вот запрос-на-модификацию к 200 - слегка превышает мою квалификацию.
Ну ясно же, что 200 - это условная цифра. Реально - 40-50.


ko4evnik> потом - шерстить эти тэги и составлять пресловутые "таблички". только будут они - всего лишь первым этапом дооолгого пути.
А, что кто-то обящал легкую жизнь?

ko4evnik>> проблема в том что анализ структуры не может быть "закончен" в принципе. он может быть только "ограничен" жесткими рамками. которые неизбежно придется в дальнейшем ломать.
LtRum> И как только банки живут годами? А ВМС США с ее внутренними БД? А предприятия? Если все сделано правильно, то нужно будет не ломать, а расширять, оставляя старое в качестве ядра.
банки и бюрократия - консервативнее похоронных бюро. там структура баз может не меняться десятилетиями. дебет-кредет. прибыл-убыл-списан.

реальный прогресс в области анализа слабоструктуризованной информации следует отслеживать по системам автоматического перевода с/на иностранные языки. а там в данный момент глухо.

ko4evnik>> ну, скажем, sql-запрос-на-чтение к 20..30 табличкам написать вполне в моих силах. а вот запрос-на-модификацию к 200 - слегка превышает мою квалификацию.
LtRum> Ну ясно же, что 200 - это условная цифра. Реально - 40-50.

даже эта цифра завышена. можно обойтись меньшим количеством.

ko4evnik>> потом - шерстить эти тэги и составлять пресловутые "таблички". только будут они - всего лишь первым этапом дооолгого пути.
LtRum> А, что кто-то обящал легкую жизнь?
а что, кто-то хотел легкой жизни?

vladre> Ну раз пошла такая пьянка, может товарищи поделитесь? Кто-какое программное обеспечение использует для своего хобби?
у меня оно самописное в основном. как метод расширения границ собственного невежества.

в частности -
ko4evnik>> 1) Применяют ли уважаемые соратники в своих коварных целях какие-либо программки поиска и изничтожения дубликатов файлов и в частности файлов изображений?
пишу собственную такую программулину.
выглядит так:

http://www.ii4.ru/images/527450gazegear.png [not image]

идентичные файлы под разными именами обнаруживаются за два чиха.

к примеру - сборничек файлов с китайских форумов (выложенный некогда Apple17) - 1.5 Гига - 5641 файл - проходит за 87 сек.
находит 257 файлов которые имеют по 2/3/4 дубля:

1. CRC = 0x799CA514
2.         D:\## photo - china-warship\china\!s\12086.jpg
3.         D:\## photo - china-warship\china\!s\98849.jpg
4.  
5. CRC = 0x63981752
6.         D:\## photo - china-warship\china\!s\12087.jpg
7.         D:\## photo - china-warship\china\!s2\1\98846.jpg
8.  
9. CRC = 0x0277845B
10.         D:\## photo - china-warship\china\!s\12255.jpg
11.         D:\## photo - china-warship\china\chn\Chongqing - 133\12255.jpg
12.  
13. CRC = 0xB8496880
14.         D:\## photo - china-warship\china\!s\12941.jpg
15.         D:\## photo - china-warship\china\chn\Zunyi - 134\12941.jpg
16.  
17. CRC = 0x43CA8BB7
18.         D:\## photo - china-warship\china\!s\14513.jpg
19.         D:\## photo - china-warship\china\!s\56247.jpg
20.         D:\## photo - china-warship\china\chn\N 970\2004_4_22_56246_56247.jpg
21.  
22. CRC = 0x4331BFE3
23.         D:\## photo - china-warship\china\!s\153464.jpg
24.         D:\## photo - china-warship\china\!s\154517.jpg
25.  
26. CRC = 0x1D47A741
27.         D:\## photo - china-warship\china\!s\154882.jpg
28.         D:\## photo - china-warship\china\!s2\31311.jpg
29.  
30. ...

с неидентичными-но-похожими все гораздо сложнее, не некоторые идеи имеются...

потому собственно и интересует мнение окружающих - чего от такой программки еще можно хотеть?

sas1975kr> Кэп, что нибудь прояснилось?
sas1975kr> Или пока Рома воюет с Корбиной все заглохло?
будет у Романа время свободное зайдет на "Морской"

sas1975kr> П.С. Мне в качестве минимального наполнения понравился немецкий сайт.
sas1975kr> Лаконично и наглядно
sas1975kr> Kaiser Information
sas1975kr> Gneisenau Info
ИМХО, читабельно. Какие еще мнения будут?

sas1975kr> Или пока Рома воюет с Корбиной все заглохло?

Да, пока сижу на дорогом и мобильном Интернете, с кодом БД возиться сложно. Пока ковыряюсь в офлайне с более удобными для офлайновой работы вещами. Хотя, м.б. и постараюсь перетащить то, что вышло, и начать расширять в офлайне

ko4evnik> потому собственно и интересует мнение окружающих - чего от такой программки еще можно хотеть?

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

Как кстати работает?

На коленке я бы сводил бы фотографии к размеру 128 на 128
и для каждой точки переведя ее в YCbCr считал бы разницу для все трех компонент и суммировал как-то
для всей картинки. (например среднюю по квадрату 16 на 16)
Если все три если меньше порога то значит одно.

Справляется ли программка с важной функцией поиска дубликатов без учета китайских подписей?

apple17> Справляется ли программка с важной функцией поиска дубликатов без учета китайских подписей?

У Кочевника - по CRC. Соответственно подписи игнорируются.

Но для вас этого мало
Вы ж хотите - когда, источник, что и кто на фотографии. А это уже ручной труд, который автоматизировать без ИИ невозможно...

ko4evnik>> потому собственно и интересует мнение окружающих - чего от такой программки еще можно хотеть?
apple17> Хотелось бы находить максимально качественный вариант из всех имеющихся.
apple17> (размер в точках больше, при этом степень компрессии Jpeg не ниже порога
apple17> - из djvu такие уроды большеточечные делают бывает)
задавать пороговую степень - видимо можно. проверю.
еще можно автоматически гнобить файлы по размеру меньше порогового. и с отношением ширины к высоте больше порогового...

apple17> Как кстати работает?
там все без чудес. ЦиклоКонтрольныйКод - алгоритм древний и классический. суть в том что бинарный файл мыслится как длиннющий полином вида а1*x^b + а2*x^(b-1)+... + aj*x¹ + ak*x⁰, где ai = 0 или 1 - который делится на некоторый стандартный полином. получается остаток от деления - который таки уникален с некоторой заданной вероятностью.
алгоритм отлично ищет АБСОЛЮТНО идентичные - вплоть до байта - файлы. но если файлы отличаются хотя бы одним байтом - чиселки будут разные...

собственно подобных программок вагон и маленькая тележка - и интересовало меня кто чем пользуется и какие от них впечатления.

apple17> На коленке я бы сводил бы фотографии к размеру 128 на 128
apple17> и для каждой точки переведя ее в YCbCr считал бы разницу для все трех компонент и суммировал как-то
apple17> для всей картинки. (например среднюю по квадрату 16 на 16)
apple17> Если все три если меньше порога то значит одно.
такая мысль мне в голову тоже приходила. но:
а) это уже алгоритмы распознавания образов, что крайне головоломно;
б) банально может не хватить вычислительной мощности сравнить все со всем.

есть у меня тестовая папочка - 45 файлов = 25Мег.
если включена только проверка CRC - проход по бинарнику - тратится 1 сек;
если файлы открывать как изображения - извлекать оттуда размер/палитру и т.п. - 6 сек;
если делать проход по всем пикселам (я там пытаюсь считать "мат.ожидание цвета" )- 232 сек.

так что гигабайт он будет обсчитывать минут 15...

пока что я пытаюсь быть проще и действую руководствуясь анекдотом:
"- как подсчитать овец на склоне?
- посчитать количество ног и поделить на 4..."

apple17> Справляется ли программка с важной функцией поиска дубликатов без учета китайских подписей?
нет. по крайней мере пока.
но идеи имеются.

к примеру - сравнивать спектр.
изображения отличающиеся только надписью - будут отличаться незначительно.

P.S. есть такой сервис - TinEye Reverse Image Search
так он находит и масштабированные, и кропнутые файлы, и маленько подредактированные.
так что надежда на осуществимость есть.

Balancer> Пока ковыряюсь в офлайне...

Все по прежнему?

П.С. Кэп меня неделю не было - смотрю никаких подвижек. Благое начинание кануло в лету?

sas1975kr> П.С. Кэп меня неделю не было - смотрю никаких подвижек. Благое начинание кануло в лету?

Я три недели без Интернета сидел. Сейчас навёрстываю по работе накопившееся.

apple17> Хотелось бы находить максимально качественный вариант из всех имеющихся.

apple17> Справляется ли программка с важной функцией поиска дубликатов без учета китайских подписей?

таки да. теперь можно сказать справляется - как минимум некоторые находит:

1. ...
2. Color = 0xFF828986
3.         D:\## photo - china-warship\china\!s\455410.jpg   == 163 кб
4.         D:\## photo - china-warship\china\!s2\66348.jpg  == 217 кб
5.         D:\## photo - china-warship\china\!s2\80295.jpg  == 536 кб
6.  
7.  
8. Color = 0xFF66737B
9.         D:\## photo - china-warship\china\!s\121243.jpg  == 122 кб
10.         D:\## photo - china-warship\china\!s\197909.jpg  == 121 кб
11.         D:\## photo - china-warship\china\!s\339703.jpg  == 121 кб
12.         D:\## photo - china-warship\china\!s2\3147.jpg  == 132 кб

мааааленькая только проблемка - 1.5 гига китайцев у меня считались 12 часов...

sas1975kr> Уж май кончается, а ясности все нет.
мы куда-то торопимся?

sas1975kr> Кэп, новостей никаких?
Будет у Романа, время зайдет сюда

Capt(N)> мы куда-то торопимся?

А кто-то любит ждать? Руки требуют штурвала
Пока есть энтузиазм, нужно этим пользоваться...

Capt(N)> Будет у Романа, время зайдет сюда

Насколько понял Рому, сделает так, как попросим. Вот поэтому и вопрос как делаем. Ты еще даже не ответил на вопрос делаем поисковик/каталог фото по форуму или полноценный справочник...