Друзья, натолкните на решение, плииииз 
Для мобильных приложений используется пнг картинка, содержащая фрагменты остальных фреймов, исполйзуемых при прорисовки собственных элементов(кнопки, баблы и т.д.). Используемый пнг файл загружается в хип, поэтому необходимо все имеющиеся картинки из нескольких файлов объединить в одном, чтобы ускорить время доступа к данным. На данный момент используется дополнительный тул ImageMagic, который может сливать картинки воедино по принципу кластеров либо вертикально либо горизонтально, но в результате это приводит к потере места, так как образуется много пустых пикселей на конечном пнг. Хотелось бы иметь возможность подгонять фрагменты изображения(тобиш исходные картинки), как в пазле, максимально близко друг к другу. Но я слышал, что на яве можно читать пнг, но формировать файл таким образом не получится. Ведь необходимо сохранить прозрачность всех исходников...Может, поделистесь мыслями, аааааа  Заранее мерси!!!!

Если, честно, то я не вижу смысла в таких вот действия.

Если нужно чтобы картинка была одна и содержала все картинки, то объедини эти картинки на компе и в jar засовывай только один файл.




От куда такое заключение, что доступ к одной большой картинке (причем еще и не оптимизированной - могут быть пустые места)  будет быстрее чем к 10-ку маленьких картинок? Ты проводил замеры или от куда данные?


Если же все же хочется решить поставленную задачу, то вот куда копать: 

1. создаешь новый Image нужно размера (какой это нужный размер Image - это уже задача двухмерной упаковки, которая является NP-трудной. Кстати, может у кого-то есть решение такой задачки? )

2. делаешь эту картинку прозрачной (доступно только в МИДП2) 

3. и потом на эту картинку рисуешь другие картинки.

да, возможно Вы и правы, что нет никакой дополнительной пользы в работе с одним неоптимированным файлом. Но мои коллеги (я студент на фирме) предложили мне этот вариант, как факт, с которым мне нужно жить . А задача заключается именно в возможности слить эти многочисленные картинки на один файл и подсказка с методой упаковки как раз кстати  Пасиба !!!. Очень прошу привести короткий пример кода, где показано, как на имидж обьект можно разместить(нарисовать) изображения из других файлов. И почему необходимо создавать изначальную картинку прозрачной? это спасёт транспарентность??? Просто я эщё не работал с подобными задачами для ява. Буду благодарен любым подсказскам.

Так-с, сорри.

С прозрачностью я наплужил.



Так не правильно, так ты прозрачность не сможешь убрать.

Вот так правильно: 

1. Создаешь массив (скажем byte [] x);
2. Берешь от всех своих картинок getRGB() (получил массив байт).
3. По разработанному тобой алгоритму заполняешь х из всех массивов байт из п.2
4. из массива х - создаешь картинку Image.createRGBImage().

Какая тут сложность в реализация п.3:
1. Массив х - должен быть одномерный. т.е. если твоя картинка финальная будет размером W на H, то х будет инициализироваться вот так:
 
x = new byte[W*H];

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


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

1. Работы много лишней . Проше в фотошопе подготовить нужного размера картинки.
2. Такой метод будет жрать много памяти - не на всех телефонах будет работать.
Как подсчитать приблизительно затраты на память: 
1 пиксель картинки = 2 байт (это внутренне представление картинки в памяти jvm).

например у тебя 5 картинок размером 20х20 пикселей

50х50 = 2500 (в картинке 2500 пикселей)

2500 х 2 (1 пиксель = 2 байта) = 5000 байт в памяти телефона.

5000 * 5 (5 - это сколько картинок) = 25000; (у тебя скорее всего картинки будут разных размеров, так что считай сам).


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

2500 * 5 = 12500;

Пусть эти все пять картинок смогут влезть в картинку размером 100х150. Массив байт получится 100 х 150  = 15000;

и когда будет создаваться картинка методом createRGBImage нужно будет еще 15000 х 2 = 30000 байт

Сумма: 25000 + 12500 + 15000 + 30000 = 82500
Т.е. вместо 25000 байт потребуется уже 82500

Расход памяти при таком методе почти в 3 раза больше.
Если картинки достаточно большие будут - то такой метод не подойдет.

3. Время загрузки программы увеличится, но быстродействие - никак нет.

eugine_s, тебя не понять. ты пишешь 
тогда как из этого: 
следует, что нужно писать x = new byte[W*H*2];

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

Это сообщение отредактировал(а) Firexel - 15.8.2008, 08:26

да, ты прав.

только не совсем.

Вместо вот этого: 
x = new byte[W*H];

должно быть вот это

x = new int[W*H]; - а int  - это 2 байта.

createRGBImage в качестве аргумента принимает массив int[], а не byte[]

и везде тоже нужно byte заменить на int (ну и при подсчетах, где считался размер массива, нужно умножить на 2).