Обработка на груби данни
Обработка на грубите данни
За подобряване на производителността на Aspose.PSD API въведохме метод за обработка на груби данни с версия 2.4.0. Обработката на груби данни сега се използва вътрешно и има външно API, така че може да се използва извън библиотеката, за да се подобри общата производителност. Понякога обработката става малко изпъната и се нуждае от някоя обяснителна информация. В момента обработката на груби данни е достъпна само за формата BMP.
За да помогнем на разработчиците да постигнат най-добрата производителност, Aspose.PSD API предоставя система за обработка на груби данни, която има външно API за персонализация. Разработчиците извикват семейството от методи LoadRawData и SaveRawData, за да използват обработката на груби данни. Тези методи също изискват задаването на желания формат на грубите данни, използвайки класа RawDataSettings. Класът RawDataSettings позволява на разработчиците да зададат който и да е формат на груби данни. Обаче, за да постигнете най-добрата производителност, трябва да използвате формата на грубите данни, в която се съхраняват данните. RawDataSettings, дефиниран в класа RasterImage, помага за определянето на формата на грубите данни на изображението. Като предадете инстанция на RawDataSettings в метода LoadRawData, данните се връщат такива, каквито са, без приложено преобразуване и може да подобри производителността. От другата страна, трябва да се грижите за всички възможни формати за разполагане на груби данни, което понякога може да бъде малко комплицирано.
За да опростите процеса на обработка, на цената на няколко процеси за производителност, може да зададете желаните RawDataSettings, като създадете и инициализирате класа с желаните настройки за груби данни. Има случаи, когато не е възможно да се върне грубите данни в посочения формат (например конверсия от CMYK цветово пространство към RGB не е налична в версия 2.4.0). Освен това може да има сценарии, при които обработката на груби данни не е налична за изображения. За да определите дали можете да използвате семействата методи LoadRawData и SaveRawData, трябва да заявите свойството IsRawDataAvailable.
Инсайт
За формата на RGB пикселите съществуват индексирани (базирани на палитра) и RGB базирани формати на груби данни. Индексираните формати на груби данни съдържат индекси на палитрата в обхвата 0..(2^брой битове – 1). Индексираните формати на груби данни са с 1, 2, 4 и 8 бита на пиксел. Останалите са RGB базирани формати на груби данни. При зареждането на груби данни, обърнете внимание, че има достатъчно налични байтове за зареждане на данните, в противен случай ще бъде генерирана съответната грешка. Може просто да оцените размера на масива от байтове, като умножите размера на реда по необходимите редове. Размерът на реда може да варира и зависи от формата на съхранението на грубите данни.
За постигане на най-добрата производителност винаги използвайте линия за груби данни с размер, равен на стойността на свойството RasterImage.RawLineSize. Въпреки това, понякога може да се наложи добавяне на допълнително пълнене на редовете с груби данни или намаляване на него, и когато това е случаят може да се използва различен размер на реда. Ако е необходимо подмножество от обкръжността на изображението, тогава вземете под внимание битовите измествания, които могат да се случат за индексирани RGB пиксел формати. Например, нека разгледаме изображение с размери 100x100 пиксела и формат на грубите данни от 1 бит на пиксел. Искате да заредите правоъгълник с груби данни с местоположение (7,0) и размери (2,1), или с други думи, искате 2 пиксела, започващи от x=7 и y=0. В този случай, трябва да получите следното подреждане на данните:
Това означава, че получавате 2 байта, където първият байт съдържа 7 ненужни пиксела, след това 1 желан пиксел, а вторият байт съдържа 1 желан пиксел и след това 7 ненужни. Можете да попитате защо не сме извършили изместване на данните и не сме сложили тези 2 пиксела в един байт? Отговорът е прост: за да поддържаме висока производителност. Вътрешната обработка обикновено се извършва с всички данни, започващи от първия пиксел и завършващи с последния наличен пиксел. Има рядко ситуации, когато се изисква подмножество на пиксели. Освен това нямаме представа как ще се обработват тези пиксели по-късно, така че изместването ще намали производителността и ще направи кода излишно сложен. Винаги оценявайте правилния бит (няма нужда да се определя точният байт, тъй като данните винаги идват с първия запълнен байт) където ще започнат изискваните пиксели. За изчисляване на правилния бит може да се използва проста формула: (rect.Left * брой битове) % 8.
Конверсия на индексирани RGB цветове
За постигане на възможно най-добра производителност винаги използвайте същите настройки за източник и дестинация на груби данни, формати на пикселите и размери на реда. Въпреки това понякога може да е необходимо да се извърши конверсия на данните. Например може да заредите RGB изображение с 1 бит на пиксел и го запазите с 2 бита на пиксел или заредите 4 битово RGB изображение и намалите неговия цветови обхват до 2 бита на пиксел. В такива случаи трябва да се приложи цветова конверсия. Конвертирането на индексирани RGB изображения понякога може да бъде трудно и не може да се извърши без наложени някои настройки. Трябва да определим как се отразява цветовият обхват на източника в целевото цветово пространство. За да изпълним тази задача, разполагаме с различни режими:
- Съвместно картиране (DitheringMethods.PaletteConversion)
- Картиране на грубите данни (DitheringMethods.PaletteIgnore)
- Потребителска конверсия (DitheringMethods.CustomConverter)
Когато се използва конверсия на палитра, източното цветово пространство се опитва да се приближи до целевото цветово пространство възможно най-точно. Например, предположете, че имаме 4-битово изображение със следните цветове: [0] RGB=0, 0, 0 [1] RGB=17, 17, 17 [2] RGB=34, 34, 34 [3] RGB=51, 51, 51 [4] RGB=68, 68, 68 [5] RGB=85, 85, 85 [6] RGB=102, 102, 102 [7] RGB=119, 119, 119 [8] RGB=136, 136, 136 [9] RGB=153, 153, 153 [10] RGB=170, 170, 170 [11] RGB=187, 187, 187 [12] RGB=204, 204, 204 [13] RGB=221, 221, 221 [14] RGB=238, 238, 238 [15] RGB=255, 255, 255
Източното изображение изглежда по следния начин:
И конвертираме 4-битовото изображение към 1-битово изображение с следните дефинирани цветове на палитрата:
[0] RGB = 0, 0, 0 [1] RGB = 255, 255, 255
При използване на конверсия на палитра, конверторът прочита източния цвят и определя целевия индекс, използвайки метода GetNearestColorIndex на целевата палитра. Стойността на свойството RasterImage.RawFallbackIndex се използва в случай, че методът GetNearestColorIndex на палитрата извън диапазона даде индекс. Това преобразува източните цветове в най-близките целеви цветове спрямо стойностите на интензивност. Целевото изображение се допада до източното изображение възможно най-точно. Можете да видите следния резултат:
При използване на режим за картиране на грубите данни се прилага различен сценарий. Просто се игнорират източната и целевата цветови палитри и индексите на източника се съпоставят с индексите на дестинацията. Когато бъде намерена стойност, която не може да бъде съпоставена с целевия обхват (при намаляване на битовете), тогава се използва стойността на свойството RasterImage.RawFallbackIndex. Стойността по подразбиране е 0 и ще бъде съпоставена с първия цвят в целевата палитра. Ако стойността на това свойство лежи извън обхвата на дестинацията, ще бъде генерирано съответно изключение. Това довежда до по-малко предсказуеми резултати, които могат да бъдат показани в следващата картинка:
Режимът за картиране на палитрата е по-правилното решение за проблема с картографирането на цветовете, но също отнема малко повече време за завършване, тъй като трябва да се извърши изчисления, за да се оцени правилното картографиране на палитрите. (Обикновено има много малка разлика в производителност между двата метода.) От друга страна, режимът за картиране на груби данни работи малко по-бързо и може да се използва за по-грубо конвертиране на цветовете, когато точното картиране на цветовете не е толкова важно. Например има случаи, когато цветовата палитра на източника е отрязана и може да се конвертира безопасно до по-малко брой битове, тъй като допълнителните битове въобще не са били използвани.
За използване на някои от тез