Программа идентификации ИСЗ в широких полях.

[Tau]

Вопрос по поводу взаимодействия с пользователем: нужно ли для обрабатываемого кадра сохранять его параметры?

Так вроде FITS Header и EXIF как раз для этого, нет?

На фитцы я изначально не закладывалась, извините. Только 8-разрядные изображения: jpg, bmp. Чтение EXIF-а отметается сразу и без дискуссий.

[CTPAHHNK]

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

Win32, Vb6
Спасибо, почитала про MD5-хэш. А идеи попроще есть? Сродни топору.

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

[Tau]

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

Держать описание рядом с файлом = записывать информационный файл в ту же директорию, где лежит кадр? Это означает выйти за пределы директории программы и мусорить на чужом компьютере. Некрасиво как-то.

[CTPAHHNK]

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

Держать описание рядом с файлом = записывать информационный файл в ту же директорию, где лежит кадр? Это означает выйти за пределы директории программы и мусорить на чужом компьютере. Некрасиво как-то.

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

[1212Lupus]

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

[Tau]

CTPAHHNK

А скопировать файл в нужную директорию для обработки вера не позволяет?

Скопировать 300 кадров по 3.5 Мб во внутренний архив - уже минус 1 гиг на винчестере. Я не готова к таким жертвам даже на своем компутере.

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

У меня тоже такая идея возникла, но, как я написала,  смущает совпадение имен файлов. Сегодня я, допустим, развлекалась с файлом 0001.jpg, а через пару дней - с другим файлом 0001.jpg.
Или только я страдаю упрощением имен файлов?

[Tau]

Предложите пользователю по маске сложное имя - дата, время, пункт.. Чтоб он сам не мучился с сочинением..(он и так уже всё ввёл). И повторяться не будут

Сложное имя для чего? Для информационного файла? Тогда как связывать его с кадром? Или сложное имя для кадра? Переименовывать чужой кадр?

[xd]

Как по мне, так лучше завести отдельную директорию в корне программной директории и там хранить файлы с параметрами.

Это не решает вопроса конфликта имён файлов. Наоборот, создаёт дополнительные сложности.
Кроме того, ещё год-два и этот вариант перестанет прокатывать: по-хорошему пользователь на компе не должен иметь возможности писать куда угодно что угодно. Так что профиль или реестр, и никуда больше.

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

И как потом прога подхватит открытый ранее в некоторое неопределённое время файл? Или предлагаете пользователю подсовывать проге этот самый файл метаданных?

[xd]

Win32, Vb6

Уууу... Не буду комментировать, дабы не отхватить порцию гнева...

Спасибо, почитала про MD5-хэш. А идеи попроще есть? Сродни топору.

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

[xd]

2) Программа сама создает файл и сама его загружает при повторном открытии, но тут сложность со связью обрабатываемого кадра и информационного файла. По имени кадра их связывать? В случае загрузки кадров с простыми/повторяющимися именами возникнет неразбериха с информационными файлами.

[xd]

Какой нетерпеливый.
Может быть лучше сделать сразу нормально, а не переделывать по сто раз?

[sp]

Предлагаю FITS с треком ("Джигит", Ка-Дар). Практически все данные по снимку есть в заголовке фитса. Если что надо дополнительно-пишите.
http://narod.ru/disk/42477313001.cc449f91a6e8c50816ddb94df8d10fd3/60p_20120220_191513_2n_420sec_-31C_Clear.rar.html

[Tau]

Deimos

Уууу... Не буду комментировать, дабы не отхватить порцию гнева...

Какой гнев? У меня уже комплекс неполноценности сложился по поводу vb. С одной стороны я ни разу не встречала задач, которые нельзя было бы решить с помощью vb. С другой стороны - мне не нравится направление прогресса виндов, и если в дальнейшем такие приложения поддерживаться не будут - Майкрософт будет проклят от имени меня лично и во веки веков.

Я согласна с Lupus-ом  в том, что пользователь должен иметь возможность ориентироваться в информационных файлах и читать их глазами (я и сама люблю в файлах копаться). То есть имя информационного файла должно быть говорящим само за себя. Чтобы избежать конфликта имен файлов к имени информационного файла (= короткому имени кадра) будет добавлен индекс, характеризующий содержимое кадра. Всё, проще топора не придумать.

[Tau]

  Да я тоже встречал такое отношение со стороны людей, программирующих 3+2 или освоивших за 10 лет 1с-бухгалтерию... ну, и запомнивших 3-4 крутых слогана

Дело не в квалификации критиков. И разбирающиеся люди понимают в чем ограничение vb, он уже почти умер, он не поддерживается. Финансово выгодно проталкивать современный VB.Net, но  это практически уже другой язык, на него так просто не перепрыгнешь. На этом плач по поводу vb заканчиваю.

[1212Lupus]

Сегодня я, допустим, развлекалась с файлом 0001.jpg, а через пару дней - с другим файлом 0001.jpg.

Можно включить в имя файла дату.

Кроме того, ещё год-два и этот вариант перестанет прокатывать: по-хорошему пользователь на компе не должен иметь возможности писать куда угодно что угодно. Так что профиль или реестр, и никуда больше.

С какого перепугу вариант перестанет прокатывать?! И почему "куда угодно", если я писал про поддиректорию внутри директории программы отождествления? На счёт профиля -- в топку! Искать файл по длиннющему пути -- нафинг нужно.

И как потом прога подхватит открытый ранее в некоторое неопределённое время файл? Или предлагаете пользователю подсовывать проге этот самый файл метаданных?

Имеено! Или у нас с программой будут иметь дело дебилоиды, которые не могут выбрать файл вручную, а программа должна всё сделать самостоятельно?

Да я тоже встречал такое отношение со стороны людей, программирующих 3+2 или освоивших за 10 лет 1с-бухгалтерию... ну, и запомнивших 3-4 крутых слогана

Звёздочкин, не выделывайтесь. Deimos отличный программист, в чём я убеждался не раз. А вот вы -- не пойми кто в этом деле. Хватит уже понты кидать -- противно.

[Tau]

Можно включить в имя файла дату.

А если дата совпадет?

Имеено! Или у нас с программой будут иметь дело дебилоиды, которые не могут выбрать файл вручную, а программа должна всё сделать самостоятельно?

Я уже намылилась на программный вариант. Ввести что ли в меню функцию выбора файла пользователем? Если программа определит информационный файл неправильно - пусть юзер сам файл выбирает из директории информационных файлов.

[1212Lupus]

Ввести формат DD-MM-YYYY-HHMMSS_название-картинки -- и пусть узер удавится. 
На счёт выбора конфигурации -- лично я больше доверяю себе, чем программе. Но тут как сделать, чтобы было оптимально, я затрудняюсь ответить.

[xd]

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

[1212Lupus]

Согласен.

[Tau]

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

То есть информационный файл сохранять в ту директорию, где кадр лежит?