amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > jpeg's sichern unter OS4? [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 3 [ - Beitrag schreiben - ]

10.09.2006, 13:53 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Gibt es eine einfache Möglichkeit unter OS4 jpegs zu specihern?, mit Datatypes wie unter AROS geht's leider nicht und die jpeg.library wie ich die unter OS3.x nutze gehts wohl auch nicht, da es diese für OS4 nicht gibt.

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 14:04 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
Gibt es eine einfache Möglichkeit unter OS4 jpegs zu specihern?, mit Datatypes wie unter AROS geht's leider nicht und die jpeg.library wie ich die unter OS3.x nutze gehts wohl auch nicht, da es diese für OS4 nicht gibt.


Mit der 68K-Variante sollte es aber gehen. PerfectPaint benutzt auch jpeg.library, soweit ich weiß, und das tut unter OOS4 inzwischen. Im Zweifel kannst Du mir ja ein Testprogramm schicken, dann probiere ich das aus.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 14:11 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Ich habe kein OS4, wie greife ich auf 68k libraries zu? ich habe halt nur die 68k Includes und das Programm ist ansonsten PPC native.

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 14:20 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
Ich habe kein OS4, wie greife ich auf 68k libraries zu? ich habe halt nur die 68k Includes und das Programm ist ansonsten PPC native.


Bei 68K-Code wie gewohnt, für PPC-Code muß für die 68K-Library noch eine Datei mit Glue-Code für die Library vorhanden sein (mit Endung .l.main, die stellt das Library Interface "main" für OS4-PPC-Code zur Verfügung).

Ich schau nachher mal, ob ich das Zeug für die jpeg.library irgendwo rumsegeln hab. Ansonsten müßte das mittels idltool erzeugbar sein.

Grüße


--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 14:24 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Wäre nicht Schlecht, ansonsten werde ich auf IFF ausweichen und DataTypes nutzen, wie gesagt unter AROS kann ich auch mit Datatypes JPEGS speichern, wäre schön wenn das auch unter OS4 ginge.

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 14:29 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
Wäre nicht Schlecht, ansonsten werde ich auf IFF ausweichen und DataTypes nutzen, wie gesagt unter AROS kann ich auch mit Datatypes JPEGS speichern, wäre schön wenn das auch unter OS4 ginge.


Das ist eine Frage des Datatypes. Soweit ich weiß, gibts auch für die 68K-Systeme kein Datatype, das JPEG speichern kann. Vielleicht die akDatatypes, aber genau weiß ich das auch nicht. Ich habe immer nur IFF verwendet :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 14:37 Uhr

bubblebobble
Posts: 707
Nutzer
Achtung:
Die OS3.x Datatpyes speichern nur IFF mit <=8 bitplanes.
24bit funzt nicht. Wenn du also speichern willst, mache es lieber selbst, sonst ist nicht garantiert dass es klappt.
IFF speichern ist leicht, auch mit kompression, wenn du willst schicke ich dir den Code in Amblitz.
Wobei ch bei IFF sogar sagen würde, speichere es ohne compression.
Heutzutage hat man genug Platz auf der Platte. Für onlinearchive packt der .lha order .zip wesentlich besser als Runlength in IFF.
Runlength gepackte IFFs werden deutlich grösser als unkomprimierte IFFs, wenn man sie zipped.

Ich habe auch code für die jpeg.library. Für jpeg würde ich die benutzen, da die Qualität des Encoder sehr gut zu sein scheint und man hat viele Möglichkeiten, Progressive, Smooting, Compressionsrate etc.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 16:28 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
@bubblebobble

Für die jpeg.library habe ich auch Code drinne, aber nur für OS3.x und für AROS geht's über die Datatypes nur geht das so nicht auf OS4.

Ich will einen Standardweg haben, nicht irgendwelchen Code selberschreiben oder Fremdcode benutzen.

Das blöde ist immer das Testen, wenn man völlig verschiedenen Code für die Unterschiedlichen Plattformen schreibt und nicht selber diese Plattform besitzt.

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 20:43 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
Ich will einen Standardweg haben, nicht irgendwelchen Code selberschreiben oder Fremdcode benutzen.


Da gibt es keinen "Standardweg" zur Zeit, außer IFF speichern via Datatype. Solange nicht die jpeg-Datatypes auf jedem System in der Lage sind, selbiges zu speichern (was technisch nicht so das Problem wäre), wirst Du Dir einen anderen gemeinsamen Nenner suchen müssen. libjpeg wäre evtl. was.

Zitat:
Das blöde ist immer das Testen, wenn man völlig verschiedenen Code für die Unterschiedlichen Plattformen schreibt und nicht selber diese Plattform besitzt.

Das ist eigentlich das geringste Problem. OS4 kann ich Dir testen oder viele andere auch. Für MOS findet sich sicher auch jemand, falls Du das auch nicht selbst haben solltest.

jpeg.l.main habe ich noch nicht "erschlagen" können, werde heut auch wohl erst spät zu Hause sein. Ich kann mich aber dunkel entsinnen, daß es dazu noch keinen Glue Code gab, also wird sich da jemand dransetzen müssen. Gemacht habe ich das noch nie, also wärs mal an der Zeit :D

Morgen gegen Mittag/früh Nachmittags kann ich Dir dann mehr dazu sagen, falls Dir das nicht zu spät sein sollte.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 20:48 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
@whose

Ich werde das wohl temporär mit IFF und Datatypes machen, irgendwie will ich auch nicht vorraussetzen, daß sich die Leute irgendwelche glues installieren, dazu ist das nicht so wichtig bzw. der ist ja nur nötig um von PPC auf 68k libs zuzugreifen, also wird das kaum ein Programm so nutzen.

Dennoch danke.


[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 21:05 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von DariusBrewka:
@whose

Ich werde das wohl temporär mit IFF und Datatypes machen, irgendwie will ich auch nicht vorraussetzen, daß sich die Leute irgendwelche glues installieren, dazu ist das nicht so wichtig bzw. der ist ja nur nötig um von PPC auf 68k libs zuzugreifen, also wird das kaum ein Programm so nutzen.

Dennoch danke.


Jo, kein Thema. Ich machs trotzdem mal morgen. Gebrauchen kann man das mit Sicherheit irgendwann irgendwie. JPEG speichern kommt ja doch öfter mal als Anforderung vor, da macht eine Library irgendwo schon Sinn. Den Glue-Code braucht man ja nur nach LIBS: zu kopieren, genau wie die jpeg.library selbst, das dürfte niemanden überfordern :D

Weißt Du zufällig, obs die Quellen zur jpeg.library irgendwo gibt? Dann könnte man drangehen, die nativ (eine gute Fingerübung wäre das allemal) für die PPC-OSse und AROS zu machen.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 22:08 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von whose:
Weißt Du zufällig, obs die Quellen zur jpeg.library irgendwo gibt? Dann könnte man drangehen, die nativ (eine gute Fingerübung wäre das allemal) für die PPC-OSse und AROS zu machen.


Leider nicht, man könnte ja den Author anschreiben. Ich habe zwar inzwischen IFF Code eingebaut aber speichern tut er nicht, aber das könnte entweder daran liegen, daß AROS das so nicht tut, oder dass IFF nicht mit 24 Bit geht.


[ - Antworten - Zitieren - Direktlink - ]

10.09.2006, 23:38 Uhr

whose
Posts: 2156
Nutzer
@DariusBrewka:

Nein, 24Bit-IFF geht mit dem "Werks-Datatype" nicht. Ich hoffe, ich erzähle jetzt keinen Quatsch (habe IFF24 nie wirklich benutzt), aber der Standard-Datatype für IFF zeigt meines Wissens nach keine IFF24-Bilder an. Dafür gabs dann ja extra Datatypes. Zwischendurch gabs da ja wohl auch mal mehrere "Standards", wenn ich mich da richtig erinnere. Irgendwas mit IFF-DEEP und eben halt IFF-24.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 02:26 Uhr

ZeroG
Posts: 1486
Nutzer
@DariusBrewka:
Schon gesehen?
http://utilitybase.com/article.php?action=search&title=How+to+create+PPC+stubs+for+M68K+libraries
Ist von Thomas Rapp, und der ist hier im Forum, frag doch mal ob er dir das Teil gibt.
Man muß das Rad ja nicht zweimal erfinden...


[ Dieser Beitrag wurde von ZeroG am 11.09.2006 um 02:30 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 02:41 Uhr

ZeroG
Posts: 1486
Nutzer
@whose:
IFF-24 ist nur ein anderer Name für ein normales IFF-ILBM mit 24 Source Bitplanes ohne CMAP (währe ja quatsch).
Der ilbm.datatype von OS4 liest und schreibt übrigens "IFF24" ohne probleme.

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 03:41 Uhr

whose
Posts: 2156
Nutzer
@ZeroG:

Ja, hast Recht. Ich bin jetzt daheim und konnte es an meinem A4000 mal "authentisch" testen. IFF24 wird auch von dem OS3.9-Datatype einwandfrei gelesen (hab ein jpg mittels ArtEffect4 als IFF-24 gespeichert).

Schreiben sollte demnach auch gehen. Das dürfte dann der gemeinsame Nenner sein, den Darius sucht.

IFF-DEEP existiert als Format (und als Datatype) aber tatsächlich. War wohl ein reines 24/32-Bit-Format, IFF24 bezeichnete die Erweiterung des ILBM auf 24 Bit(Planes) statt wie ursprünglich 8Bit(Planes).

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 11.09.2006 um 03:44 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 11:38 Uhr

ZeroG
Posts: 1486
Nutzer
Zitat:
Original von whose:
@ZeroG:
IFF-DEEP existiert als Format (und als Datatype) aber tatsächlich. War wohl ein reines 24/32-Bit-Format, IFF24 bezeichnete die Erweiterung des ILBM auf 24 Bit(Planes) statt wie ursprünglich 8Bit(Planes).

Deswegen hatte ich nichts zu IFF-DEEP geschrieben :D

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 11:47 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von ZeroG:
@DariusBrewka:
Schon gesehen?
http://utilitybase.com/article.php?action=search&title=How+to+create+PPC+stubs+for+M68K+libraries
...


Noch nicht, aber Ich habe inzw. IFF Code für OS4 eingebaut, kann aber natürlich nicht testen, wenn das nicht gehen sollte, dann werde ich mich nach dem Source für die jpeg.library umsehen aber bei Thomas anfragen sollte Ich auch, schliesslich läufts dann auch nativ mit gleichem Code wenn ich den library source bekomme.

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 12:10 Uhr

ZeroG
Posts: 1486
Nutzer
@DariusBrewka:
Äh... Eigendlich hat Thomas nur den Stub (jpeg.l.main) für PPC -> 68k aufrufe für die jpeg.library geschrieben (für PicShow).
Und dann darüber ein "How to..." geschrieben.

Die eigendliche library ist von Paul Huxham und die WarpUp version von Oliver Roberts.
Der Originalauthor schein ja kein PPC Amiga zu haben, deshalb sollte man vielleicht einfach mal bei Oliver nachfragen ob er ne OS4 Version macht (wenn er gerade Zeit hat, muß sich ja auch noch um die WarpDTs, IBrowse und OS4 kümmern).

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 12:38 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
@ZeroG

Hast du zufällig eine gültige Adresse von einem der beiden?

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 13:11 Uhr

bubblebobble
Posts: 707
Nutzer
Nochmal:

Mit Datatpyes kann man nur IFF speichern, und nur bis zu 8bit.

Vielleicht geht hier oder dort ein bisschen mehr, aber das ist (leider) der kleinste gemeinsame Nenner. Wenn du z.B. 24bit Bilder per Datatype speicherst, kann du davon ausgehen das bei den meisten OS3.x Usern das Program abstürzt beim Speichern.

Ich kann nur empfehlen, schreibe den Code zum Speichern selbst oder nutze eine entsprechnde lib.
Du kannst für IFF ILBM und PNG gerne meinen Code benutzen, sollte einfach sein das nach C zu portieren, ich benutze keine Amiblitz spezifischen Tricks.

PNG und IFF speichern ist einfach, JPEG geht über die jpeg.library, die recht verbeitet ist. Ob es einen PPC port gibt weiss ich nicht, sollte aber einfach zu machen sein, es sind ja nur arithmeitsche Operationen und kaum OS Aufrufe wo was schief gehen könnte.

Die jpeg.library ist übrigends sehr schnell, dürfte also auch unter OS4 emuliert schnell sein.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 13:45 Uhr

thomas
Posts: 7675
Nutzer
Zitat:
Wenn du z.B. 24bit Bilder per Datatype speicherst, kann du davon ausgehen das bei den meisten OS3.x Usern das Program abstürzt beim Speichern.

Das ist Blödsinn. Bei den normalen 3.1er Datatypes werden 24bit-Bilder einfach nicht gespeichert, genauso wie sie nicht geladen werden können. Da stürzt nichts ab.

Und auf allen Systemen, mit denen du 24bit-Bilder laden kannst, kannst du sie auch speichern (z.B. OS3.1 mit Grafikkartensoftware).

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 14:00 Uhr

bubblebobble
Posts: 707
Nutzer
@Thomas:

Da habe ich andere Erfahrungen gemacht.
Bitmaps <=8 planes gingen problemlos, also ist mein Speichercode ok.
Sobald ich eine Bitmap >8 planes genommen habe, wurde eine Datei angelegt mit ein paar Bytes, aber der Rechner ist dann gecrashed.

Einziger Unterschied in den beiden Varianten war statt einer "8" eine "24" bei AllocBitmap, der Rest war identisch.

Das war bei OS3.9. Mit AfA ging speichern überhaupt nicht. Vielleicht ist das aber jetzt anders, muss ich mal testen.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 14:05 Uhr

thomas
Posts: 7675
Nutzer

Zitat:
Einziger Unterschied in den beiden Varianten war statt einer "8" eine "24" bei AllocBitmap, der Rest war identisch.

Wenn du eine Bitmap mit einer Tiefe größer als 8 anlegst, mußt du das Pixelformat mit angeben (siehe cybergraphx/cybergraphics.h). Oder eine existierende Friend-Bitmap mit gleicher Tiefe.

Im Prinzip müßte dir schon AllocBitmap um die Ohren fliegen, wenn du "einfach so" mehr als 8 angibst.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 14:35 Uhr

bubblebobble
Posts: 707
Nutzer
@Thomas

Hab es gerade nochmal mit und ohne AfA ausprobiert. Geht nicht.
Mit AfA schlägt DoDTmethod fehl (Rückgabewert 0), und es crashed nicht.
Ohne AfA meldet DoDTMethod ok und der Rechner stürzt etwas später ab.

Ich habe beides versucht, mit friend Bitmap und mit Pixelformat.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 14:59 Uhr

ZeroG
Posts: 1486
Nutzer
Zitat:
Original von DariusBrewka:
@ZeroG

Hast du zufällig eine gültige Adresse von einem der beiden?


Paul kriegst du vielleicht hier:
Der Link funktioniert nicht mehr, wie es mit der email-adresse aussieht was ich nicht.

paulhuxham(äht)yahoo.com
http://mafeking.scouts.org.au/steeplesoftware

Oliver kriegst du aber auf jeden Fall per email, hab erst letzten Monat ein Bugreport zu den WarpDTs geschrieben.
Ist sowieso die bessere wahl von den beiden.
Er hat sich schon mal durch den Quelltext gearbeitet, hat ein passendes OS4-Library Gerüst, und die möglichkeit das ganze gleich unter OS4 zu testen.

oliver(äht)futaura.co.uk
http://www.futaura.co.uk/

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 15:44 Uhr

gni
Posts: 1106
Nutzer
Zitat:
bubblebobble:
Mit Datatpyes kann man nur IFF speichern, und nur bis zu 8bit.

Defintiv falsch. Einem meiner Datatypes habe ich vorlanger Zeit Speichern beigebracht, und da werden auch 24Bit Bilder erzeugt (zb. wenn es sich um HAM-Daten handelt). Der Quellcode (in C ;-) ist dabei. Schau ruhig rein.

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 16:04 Uhr

malte2
Posts: 148
Nutzer
DoGadgetMethod bzw. DoDTMethod nur verwenden, wenn die Msg Struktur eine GadgetInfo hat ansonsten DoMethod nutzen.

[ - Antworten - Zitieren - Direktlink - ]

11.09.2006, 16:33 Uhr

bubblebobble
Posts: 707
Nutzer
Und wie sieht der korrekte Quellcode zum Speichern via Datatypes aus?
(also für den Anwender des Datatypes ?)

Beide, DoDTMethod und DoMethod funktioniert bei mir nicht.
Die Message hat eine "dtWrite" Strukur.

Grundsätzlich funktioniert es aber, wenn ich auf 8bit gehe.
Das geht sogar mit identischem Code, wenn ich eine Bitmap anlege mit der WB als Friendbitmap. Dann läuft mein Program auf einer 256 Fabren WB; aber nicht unter 24bit WB.

Der Code sieht so aus:

code:
Function.l image_saveDT {image.l,filename.s}
succ.l=False
;*newbm.BitMap = AllocBitMap_(320,200,8,#BMF_CLEAR,0)
*newbm.BitMap =\ARGBbitmap_ptr ; kommt von meinem ARGB Bild

w.l = GetBitMapAttr_(*newbm,#BMA_WIDTH)
h.l = GetBitMapAttr_(*newbm,#BMA_HEIGHT)
d.l = GetBitMapAttr_(*newbm,#BMA_DEPTH)

If d <= 8 Then ncols.l = 1 LSL d : Else ncols = 0

*DTPic._Object = NewDTObjectA_ (0,Tags(#DTA_SourceType,#DTST_RAM,@@
                                       #PDTA_DestMode,#PMODE_V43,@@
                                       #DTA_GroupID,#GID_PICTURE,@@
                                       #PDTA_Remap,0,@@
                                       #PDTA_ModeID,0,@@
                                       #PDTA_NumColors,ncols,@@
                                       #PDTA_BitMap,*newbm)   )
If *DTPic
  GetDTAttrsA_ *DTPic,Tags(#PDTA_BitMapHeader,&*bmhdp.BitMapHeader )
  If *bmhdp
    *bmhdp\bmh_Width  = w    
    *bmhdp\bmh_Height = h
    *bmhdp\bmh_Depth  = d
  End If

  ; ermitteln der Farben
  If ncols
    GetDTAttrsA_ *DTPic,Tags(#PDTA_ColorRegisters,&cmap.l,#PDTA_CRegs,&cregs.l)
    For i.l = 3*ncols-1 To 1 Step -1
      Poke.l cregs+i*4 , 128 LSL 24
      Poke.b cmap +i   , 128
    Next
  EndIf

  fh.l = Open_ (&filename.s,#MODE_NEWFILE)
  If fh
      DTMW.dtWrite\MethodID            = #DTM_WRITE
      DTMW\dtw_GInfo           = 0
      DTMW\dtw_FileHandle      = fh
      DTMW\dtw_Mode            = #DTWM_IFF
      DTMW\dtw_AttrList        = 0
      succ = DoDTMethodA_(*DTPic,0,0,&DTMW)
 ;     succ = DoMethodA (*DTPic,&DTMW)
      Close_ fh
      If succ = False
        error {"Unable to write IFF !"}
        ;DeleteFile_ &filename.s
      EndIf
    EndIf
    DisposeDTObject_ *DTPic
    \ARGBbitmap_ptr = 0 ; hack, because DisposeDTObject frees our bitmap!
Else
  error {"Unable to create Datatype Object out of the bitmap !"}
EndIf
Function Return succ
End Function

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 00:41 Uhr

malte2
Posts: 148
Nutzer
#include <intuition/intuition.h>
#include <datatypes/datatypesclass.h>
#include <datatypes/pictureclass.h>

#include <proto/datatypes.h>
#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/graphics.h>
#include <proto/intuition.h>

int main(int argc, char **argv)
{
struct Screen *scr;
struct BitMap *bm = NULL;
Object *dto;

if (argc < 2) return 0;

if ((scr = LockPubScreen(NULL)))
{
if ((bm = AllocBitMap(
GetBitMapAttr(scr->RastPort.BitMap, BMA_WIDTH),
GetBitMapAttr(scr->RastPort.BitMap, BMA_HEIGHT),
GetBitMapAttr(scr->RastPort.BitMap, BMA_DEPTH),
BMF_MINPLANES, scr->RastPort.BitMap)))
{
BltBitMap(scr->RastPort.BitMap,0,0,
bm,
0,0,
GetBitMapAttr(scr->RastPort.BitMap, BMA_WIDTH),
GetBitMapAttr(scr->RastPort.BitMap, BMA_HEIGHT),
0xc0, 0xff, NULL);
}
}

if (bm != NULL)
{
if ((dto = NewDTObject(0,
DTA_SourceType, DTST_RAM,
DTA_GroupID, GID_PICTURE,
PDTA_DestMode, PMODE_V43,
TAG_END)))
{
struct BitMapHeader *bmh;
BPTR fh;

GetDTAttrs(dto,PDTA_BitMapHeader,&bmh,TAG_END);

bmh->bmh_PageWidth =
bmh->bmh_Width = GetBitMapAttr(bm, BMA_WIDTH);
bmh->bmh_PageHeight =
bmh->bmh_Height = GetBitMapAttr(bm, BMA_HEIGHT);

if ((bmh->bmh_Depth = GetBitMapAttr(bm, BMA_DEPTH)) >= 15)
{
bmh->bmh_Depth = 24;

SetDTAttrs(dto,0,0,
PDTA_NumColors, 0,
PDTA_ModeID, GetVPModeID(&scr->ViewPort),
PDTA_BitMap, bm,
TAG_END);
}
else
{
ULONG *cregs = NULL;
UBYTE *cmap = NULL, modeid;
int i, ncols;

modeid = GetVPModeID(&scr->ViewPort);

if (modeid & HAM_KEY)
ncols = (1 << (bmh->bmh_Depth-2));
else if (modeid & EXTRAHALFBRITE_KEY)
ncols = 32;
else
ncols = (1 << bmh->bmh_Depth);

SetDTAttrs(dto,0,0,
PDTA_NumColors, ncols,
PDTA_ModeID, modeid,
PDTA_BitMap, bm,
TAG_END);

GetDTAttrs(dto,
PDTA_ColorRegisters, &cmap,
PDTA_CRegs, &cregs,
TAG_DONE);

if (cmap && cregs)
{
for (i = 0; i < ncols; i++)
{
ULONG tab[3];

GetRGB32(scr->ViewPort.ColorMap, i,1, tab);

*cmap++ = tab[0] >> 24;
*cmap++ = tab[1] >> 24;
*cmap++ = tab[2] >> 24;

*cregs++ = tab[0];
*cregs++ = tab[1];
*cregs++ = tab[2];
}
}
}

if ((fh = Open(argv[1], MODE_NEWFILE)))
{
if(!DoDTMethod(dto,0,0,DTM_WRITE,0,fh,DTWM_IFF,0))
{
}

Close(fh);
}

DisposeDTObject(dto);
}
}

UnlockPubScreen(NULL, scr);

return 0;
}

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 3 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > jpeg's sichern unter OS4? [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.