> Есть ли сей продукт или придется-таки самому опять писать ?
вы действительно собираетесь заняться разработкой столь массивного продукта с целью отсортировать личные фотки? ;) думаете экономия времени на поиске и просмотре этих самых личных фоток в нем по сравнению с поиском и просмотром фоток просто разумно разложенных по подкаталогам окупит его разработку? ;)))
вообще если уж заниматься его разработкой, то на продажу. если таки соберетесь это делать - свистните ;) может скооперируемся как-нить ;) по крайней мере юз-кейсы можно коллективно описать ;)
Хранение фоток
Всего 13 сообщ.
|
Показаны 1 - 13
Re: Хранение фоток
Re: Хранение фоток
грейангел, вы слишком поверхностно смотрите на проблему, если вам кажется, что от выбора средства разработки (по крайней мере между дельфями и вижуал си) у вас сильно изменится время разработки. а также, если считаете, что человеко-месяц на ui к такой штуке - это много ;)
для начала могу предложить вам простое упражнение: напишите подробные юз-кейсы. хотя бы неформально.
притом базовые понятны уже сейчас, нужно как минимум описать, например:
1. юзер засунул карточку в читалку и хочет скинуть с нее _выбранные_ картинки в систему, параллельно классифицируя их (не по одной, естественно) по тем-то и тем-то осям
2. юзер хочет посмотреть какие картинки он недавно скинул и еще никак не обрабатывал. возможно, срез их по тематике.
3. юзер хочет подредактировать ту или иную картинку и сохранить результат параллельно с изначальной картинкой
4. юзер хочет подредактировать картинку и сохранить результат вместо изначальной картинки
5. юзер хочет смасштабировать выбранный набор картинок и классифицировать результат каким-то образом
6. юзер хочет отпечатать набор картинок, притом по несколько картинок на листе, используя некий продукт, позволяющий это делать
7. юзер хочет узнать, какие картинки он не печатал из определенного среза.
8. юзер хочет склеить панораму из набора картинок используя некую тулзу.
9. юзер хочет узнать какие отредактированные варианты той или иной картинки существуют, с какими целями проводилось редактирование, а также что из них напечатано, что выложено в веб и т.п.
10. юзер хочет удалить набор картинок (опции: -со всеми их отредактированными вариантами или -сохраняя связи между оставшимися отредактированными вариантами)
11. случайно удалив картинки, юзер хочет отменить операцию удаления
12. юзер хочет создать бэкап всей базы картинок и метаинформации.
13. юзер хочет скинуть часть картинок в архив на двд и удалить их из основной базы для экономии места на винче.
14. юзер хочет иметь возможность искать по метаинформации от картинок, скинутых на двд, и, буде какая-то конкретная картинка его заинтересует, получить четкие инструкции как найти соотвествующий диск
к этому всему прибавьте грамотную генерацию и кэширование тумбнейлов, быстрый (и грамотный) зум и скролл картинок, правильное чтение форматов (даже если запись вам не понадобится), разумную реализацию базы метаинформации, разумный менеджмент ее категорий и прочих осей - времени, ассоциаций между картинками, статусов картинок и т.п.
короче, прежде чем говорить "да я эту ерунду на дельфи за месяц наваяю" нужно осознавать объем задачи. или, точнее говоря, тот факт, что если вы хотите, что полученным результатом хотя бы вам самому потом захотелось пользоваться, то объем задачи существенно возрастает по сравнению с задачей "поиграться в разработку image library management system" ;)
для начала могу предложить вам простое упражнение: напишите подробные юз-кейсы. хотя бы неформально.
притом базовые понятны уже сейчас, нужно как минимум описать, например:
1. юзер засунул карточку в читалку и хочет скинуть с нее _выбранные_ картинки в систему, параллельно классифицируя их (не по одной, естественно) по тем-то и тем-то осям
2. юзер хочет посмотреть какие картинки он недавно скинул и еще никак не обрабатывал. возможно, срез их по тематике.
3. юзер хочет подредактировать ту или иную картинку и сохранить результат параллельно с изначальной картинкой
4. юзер хочет подредактировать картинку и сохранить результат вместо изначальной картинки
5. юзер хочет смасштабировать выбранный набор картинок и классифицировать результат каким-то образом
6. юзер хочет отпечатать набор картинок, притом по несколько картинок на листе, используя некий продукт, позволяющий это делать
7. юзер хочет узнать, какие картинки он не печатал из определенного среза.
8. юзер хочет склеить панораму из набора картинок используя некую тулзу.
9. юзер хочет узнать какие отредактированные варианты той или иной картинки существуют, с какими целями проводилось редактирование, а также что из них напечатано, что выложено в веб и т.п.
10. юзер хочет удалить набор картинок (опции: -со всеми их отредактированными вариантами или -сохраняя связи между оставшимися отредактированными вариантами)
11. случайно удалив картинки, юзер хочет отменить операцию удаления
12. юзер хочет создать бэкап всей базы картинок и метаинформации.
13. юзер хочет скинуть часть картинок в архив на двд и удалить их из основной базы для экономии места на винче.
14. юзер хочет иметь возможность искать по метаинформации от картинок, скинутых на двд, и, буде какая-то конкретная картинка его заинтересует, получить четкие инструкции как найти соотвествующий диск
к этому всему прибавьте грамотную генерацию и кэширование тумбнейлов, быстрый (и грамотный) зум и скролл картинок, правильное чтение форматов (даже если запись вам не понадобится), разумную реализацию базы метаинформации, разумный менеджмент ее категорий и прочих осей - времени, ассоциаций между картинками, статусов картинок и т.п.
короче, прежде чем говорить "да я эту ерунду на дельфи за месяц наваяю" нужно осознавать объем задачи. или, точнее говоря, тот факт, что если вы хотите, что полученным результатом хотя бы вам самому потом захотелось пользоваться, то объем задачи существенно возрастает по сравнению с задачей "поиграться в разработку image library management system" ;)
Re: Хранение фоток
> Пока слишком сырой и неудобный.
вот в том-то и фигня, что сделать хехе сухой и удобный продукт такого плана - это надо долбаться притом не одному, а тимом, достаточно продолжительное время. конечно adobe для этого быть совсем не обязательно, но все же надо осознавать что стоимость разработки тут не меньше 30-40К даже в условия россиийской (даже не московской) стоимости рабочей силы и перманентного неуемного энтузиазма разработчиков ;)
это, понимашь, не утилита командной строки для конвертации raw в tiff ;)
кстати, этот самый image/media management - это довольно таки интересный вертикальный рынок. но только там решения стоят дорого, рассчитаны на коллективное использование и на пиратских сидишках их, я полагаю, достать трудно ;)
вот в том-то и фигня, что сделать хехе сухой и удобный продукт такого плана - это надо долбаться притом не одному, а тимом, достаточно продолжительное время. конечно adobe для этого быть совсем не обязательно, но все же надо осознавать что стоимость разработки тут не меньше 30-40К даже в условия россиийской (даже не московской) стоимости рабочей силы и перманентного неуемного энтузиазма разработчиков ;)
это, понимашь, не утилита командной строки для конвертации raw в tiff ;)
кстати, этот самый image/media management - это довольно таки интересный вертикальный рынок. но только там решения стоят дорого, рассчитаны на коллективное использование и на пиратских сидишках их, я полагаю, достать трудно ;)
Re: Хранение фоток
я уже писал тут как я делаю. повторюсь пожалуй: отснятые подряд кадры (обычно - одну флешку, иногда - часть кадров на флешке, иногда несколько флешек вместе) кидаю в подкаталог, имя которого отражает дату (или даты) съемки в формате YYYYMMDD или YYYYYMMdd_DD (если снято с dd по DD) и тематику... пример: 20031221_GUESTS
далее, внутри создаю подкаталоги для разных версий. раньше это было DONE, WEB и WEB\THUMBNAILS, сейчас - PRINT, WEB и WEB\THUMBNAILS
раньше я все файлы также переименовывал по датам и тематике и плюс писал им префиксы типа что за файл - оригинал, для печати, для веба. теперь понял что для меня это - лишняя операция, отнимающая время, и имена файлов сохраняются, а разные версии обработки (которые на самом деле появляются редко) дополняются постфиксами _1, _2 и т.п.
ну вот, в общем-то и все. система неидеальная, но простая. и ориентироваться вполне позволяет.
а да еще все эти подкаталоги "пленок" лежат в двух - FILMS и NEWFILMS. изначально я кладу все в NEWFILMS, но если все необъодимые операции над всеми кадрами той или иной "пленки" произведены, то я перекладываю соответствующий каталог (со всеми подкаталогами) в FILMS.
что касается объемов, то сейчас порядка 6 гигов за 2001-2003 годы, но это большей частью с 2 мегапиксельной камеры. чую с 300д эта цифра существенно вырастет, особенно учитывая процесс raw -> tif, съедающий 24 мега на кадр, даже если тиф 8-битный. но ничего.
просматриваю все это дело обычно psp.
далее, внутри создаю подкаталоги для разных версий. раньше это было DONE, WEB и WEB\THUMBNAILS, сейчас - PRINT, WEB и WEB\THUMBNAILS
раньше я все файлы также переименовывал по датам и тематике и плюс писал им префиксы типа что за файл - оригинал, для печати, для веба. теперь понял что для меня это - лишняя операция, отнимающая время, и имена файлов сохраняются, а разные версии обработки (которые на самом деле появляются редко) дополняются постфиксами _1, _2 и т.п.
ну вот, в общем-то и все. система неидеальная, но простая. и ориентироваться вполне позволяет.
а да еще все эти подкаталоги "пленок" лежат в двух - FILMS и NEWFILMS. изначально я кладу все в NEWFILMS, но если все необъодимые операции над всеми кадрами той или иной "пленки" произведены, то я перекладываю соответствующий каталог (со всеми подкаталогами) в FILMS.
что касается объемов, то сейчас порядка 6 гигов за 2001-2003 годы, но это большей частью с 2 мегапиксельной камеры. чую с 300д эта цифра существенно вырастет, особенно учитывая процесс raw -> tif, съедающий 24 мега на кадр, даже если тиф 8-битный. но ничего.
просматриваю все это дело обычно psp.
