PIL i 32 bity
python...@nospam.gazeta.pl
czy mógłby mi ktoś zdradzić w jaki sposób zmusić PIL do pracy z plikami o
32bitowej głębi koloru na kanał? Chodzi o i odczyt oraz zapis na przykład
tiffa (zdaje się tylko tiff i sgi z zestawu PIL, może mieć zapis 32bitowy).
Nie jestem w stanie tego rozgryźć. PIL nie odczytuje w ogóle takich plików a
zapisując zamienia wszytko na int.
Dziękuje i pozdrawiam,
skk.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Bart Ogryczak
> Witam,
> czy mógłby mi ktoś zdradzić w jaki sposób zmusić PIL do pracy z plikami o
> 32bitowej głębi koloru na kanał?
32-bitowe głębi koloru *na kanał*? Znaczy np. 128-bitowy CMYK?
Myślałem, że 128-bitowe kolory, to tylko formaty typu EXR mają.
A do zdjęć HDR, to będziesz musiał ImageMagick użyć.
> Chodzi o i odczyt oraz zapis na przykład
> tiffa (zdaje się tylko tiff i sgi z zestawu PIL, może mieć zapis 32bitowy).
TIFF == Thousands of Incompatible File Formats ;-P
bart
--
"Security issues are not discussed in this memo, but then again, no
other issues of any importance are discussed in this memo either." [RFC1438]
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
pythonlog...@gazeta.pl
> 32-bitowe głębi koloru *na kanał*? Znaczy np. 128-bitowy CMYK?
> Myślałem, że 128-bitowe kolory, to tylko formaty typu EXR mają.
> A do zdjęć HDR, to będziesz musiał ImageMagick użyć.
>
> bart
Tak, na 32bity kanał. Tiff, podobnie jak Shake/Maya iff, sgi, rla(?), Houdini
pic, no i oczywiście exr, może mieć 32bity na kanał. Muszę mieć w miarę dobre
wsparcie dla obrazów 32bit w Pythonie (niekoniecznie HDR). Próbuje właśnie
skompilować bibliotekę OpenEXR na swoim systemie (Ubuntu), ale to również
zawodzi. Tymczasem istnieje moduł Pythona do OpenEXR.
ImageMagick chciałem uniknąć... ale pewnie na tym się skończy.
Bart Ogryczak
>
>> 32-bitowe głębi koloru *na kanał*? Znaczy np. 128-bitowy CMYK?
>> Myślałem, że 128-bitowe kolory, to tylko formaty typu EXR mają.
>> A do zdjęć HDR, to będziesz musiał ImageMagick użyć.
>
>> TIFF == Thousands of Incompatible File Formats ;-P
>
> pic, no i oczywiście exr, może mieć 32bity na kanał. Muszę mieć w miarę dobre
> wsparcie dla obrazów 32bit w Pythonie (niekoniecznie HDR). Próbuje właśnie
> skompilować bibliotekę OpenEXR na swoim systemie (Ubuntu), ale to również
> zawodzi.
Nie mam w tej chwili Ubuntu pod ręką, ale czy przypadkiem nie wystarczy
apt-get install openexr?
> Tymczasem istnieje moduł Pythona do OpenEXR.
Ale póki co pozwala tylko odczytać i zapisać.
> ImageMagick chciałem uniknąć... ale pewnie na tym się skończy.
Ale dlaczego? Moim zdaniem bardzo dobra bilioteka.
bart
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
pythonlog...@gazeta.pl
>
> Nie mam w tej chwili Ubuntu pod ręką, ale czy przypadkiem nie wystarczy
> apt-get install openexr?
Również nie mogę teraz sprawdzić, ale udało mi się skompilować starszą wersję
1.4. Dzięki.
> > Tymczasem istnieje moduł Pythona do OpenEXR.
>
> Ale póki co pozwala tylko odczytać i zapisać.
A co więcej powinien umieć moduł dostępu do pliku? Ciekawostki typu
filtrowanie zostawiam bardziej zaawansowanym narzędziom, operacje per pixel
(korekcja koloru) wolę robić samemu. Nie znam darmowej biblioteki, która
potrafiłaby to naprawdę dobrze. Jedyny bój z mojego punktu widzenia to ten
binarny string, który muszę przerobić na tablice numpy. Może ktoś zna jakiś
szybki sposób na zrobienie tego? Ten pokazany na stronie PythonOpenEXR robi to
za pomocą PILa, fromstring() - co jest powolne.
> > ImageMagick chciałem uniknąć... ale pewnie na tym się skończy.
>
> Ale dlaczego? Moim zdaniem bardzo dobra biblioteka.
Co to znaczy dobra? Bogata, zaawansowana, dojrzała, ale czy wygodna,
elastyczna, szybka? Nie chcę się wdawać w dyskusję, wydaje mi się to po prostu
mało oczywiste.
Ja potrzebuję tylko szybki sposób na zapisywanie 32 bitowych tablic do pliku
graficznego, który odczytują inne aplikacje. Dlatego exr wydaje się dobrym
rozwiązaniem. PIL z 32bitowym wsparciem też byłby rozwiązaniem.
W między czasie udało mi się ustalić, że PIL wspiera 32bitowe pliki tylko w
BW, jednokanałowe, czyli w trybie "L".
Sulsa
> Ja potrzebuję tylko szybki sposób na zapisywanie 32 bitowych tablic do pliku
> graficznego, który odczytują inne aplikacje. Dlatego exr wydaje się dobrym
> rozwiązaniem. PIL z 32bitowym wsparciem też byłby rozwiązaniem.
>
> W między czasie udało mi się ustalić, że PIL wspiera 32bitowe pliki tylko w
> BW, jednokanałowe, czyli w trybie "L".
zglos jako buga, moze w nastepnych wersjach poprawiom.
Bart Ogryczak
>> > ImageMagick chciałem uniknąć... ale pewnie na tym się skończy.
>>
>> Ale dlaczego? Moim zdaniem bardzo dobra biblioteka.
>
> Co to znaczy dobra? Bogata, zaawansowana, dojrzała, ale czy wygodna,
> elastyczna, szybka? Nie chcę się wdawać w dyskusję, wydaje mi się to po prostu
> mało oczywiste.
> Ja potrzebuję tylko szybki sposób na zapisywanie 32 bitowych tablic do pliku
> graficznego, który odczytują inne aplikacje. Dlatego exr wydaje się dobrym
> rozwiązaniem. PIL z 32bitowym wsparciem też byłby rozwiązaniem.
Ok, ja używałem w zupełnie inny sposób. Wczytywałem pliki i generowałem z nich
miniatury w 3 rozmiarach ze znakiem wodnym. Poza tym mam bardzo pozytywną opinię
o ImageMagick, bo kiedy lata temu okazało się, że nie wspiera JPEG z CMYK,
napisałem do autora i już następnego dnia była wersja to wspierająca :-)
> W między czasie udało mi się ustalić, że PIL wspiera 32bitowe pliki tylko w
> BW, jednokanałowe, czyli w trybie "L".
Chyba raczej I albo F.
http://www.pythonware.com/library/pil/handbook/concepts.htm
bart
--
"Big Duke Six to Eagle Thrust, put on heading 270, assume attack formation"
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
pythonlog...@gazeta.pl
> zglos jako buga, moze w nastepnych wersjach poprawiom.
>
To nie bug, ale ograniczenie architektury tej biblioteki (najwyraźniej). PIL
potrafi po prostu zapisać do 32 bitów na piksel, co się rozkłada na 8 bitów na
4 kanały, albo jeden kanał 32bitowy. Poza tym nowe wersje pojawiają się raz na
2-3 lata... Bardzo lubię ten moduł (kto nie lubi), ale jest to solidy acz ramol.
@Bart:
> Chyba raczej I albo F.
> www.pythonware.com/library/pil/handbook/concepts.htm
Tak, oczywiście miałem na myśli "F".
Sulsa
" " <pythonlog...@gazeta.pl> wrote:
> >
> > zglos jako buga, moze w nastepnych wersjach poprawiom.
> >
>
> To nie bug, ale ograniczenie architektury tej biblioteki (najwyraźniej). PIL
> potrafi po prostu zapisać do 32 bitów na piksel, co się rozkłada na 8 bitów na
> 4 kanały, albo jeden kanał 32bitowy. Poza tym nowe wersje pojawiają się raz na
> 2-3 lata... Bardzo lubię ten moduł (kto nie lubi), ale jest to solidy acz ramol.
Wiem ze to nie bug ale jak bedzie regularnie zglaszany jako bug to moze
to zmienia, jezeli maja jakis formularz z feature requestami to mozna
tez zglosic za jego pomoca.
> @Bart:
> > Chyba raczej I albo F.
> > www.pythonware.com/library/pil/handbook/concepts.htm
>
> Tak, oczywiście miałem na myśli "F".
to nie forum powinienes odpowiedziec pod postem Barta
Daniel Mróz
> czy mógłby mi ktoś zdradzić w jaki sposób zmusić PIL do pracy z plikami o
> 32bitowej głębi koloru na kanał? Chodzi o i odczyt oraz zapis na przykład
> tiffa (zdaje się tylko tiff i sgi z zestawu PIL, może mieć zapis 32bitowy).
ENOTIME.
Zainteresuj się GEGLem. Google udzieli bardziej szczegółowych informacji.
I nie boj się ImageMagicka. Zacna biblioteka.
Pozdrawiam
Beorn
--
Daniel 'Beorn' Mróz <be...@alpha.pl> http://127.0.0.1/beorn
[GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---]
[O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*]
[ r++ y+ ]