amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > jpeg's sichern unter OS4? [ - Search - New posts - Register - Login - ]

1 -2- 3 [ - Post reply - ]

2006-09-12, 02:50 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von bubblebobble:
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.


Lese mal den Anfang des Threads, dann siehst du dass ich unter OS3.x die jpeg.lib nutze.

Zitat:
Ich kann nur empfehlen, schreibe den Code zum Speichern selbst oder nutze eine entsprechnde lib.

Ich empfinde das schreiben von eigenen Code als Zeitverschwendung, für mich war das Library-Konzept immer dazu da dieses zu vermeiden.

Z.B. zum Laden von PNG Icons unter OS3.x, jeder der darunter PNG Icons braucht hat den PowerIcons patch, alos frage ich lieber ob man dort ein Interface einführt anstatt den Ganzen Kram selber zu machen mit eigenen Parametern & CO, das gleiche Interface gibts nun auch In AROS und Ich muß nicht mehr herumwurschteln.

[ - Answer - Quote - Direct link - ]

2006-09-12, 02:56 h

DariusBrewka
Posts: 899
[Banned user]
@ZeroG

danke ich werde Oliver mal anschreiben, wenn er keine zeit dazu haben sollte kann ich das ggf. ja machen.

[ - Answer - Quote - Direct link - ]

2006-09-12, 02:58 h

whose
Posts: 2156
User
@DariusBrewka:

Nun ja, thomas hat ja bereits l.main für die jpeg.library erzeugt. Frag ihn halt, ob er Dir die für Deine Zwecke schicken kann, dann kannst Du die zu Deinem Programm dazupacken und OS4-User mögen sich selbige dann nach LIBS: kopieren.

Damit hättest Du (außer AROS) alle AmigaOS-artigen Plattformen abgedeckt.

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

2006-09-12, 03:13 h

DariusBrewka
Posts: 899
[Banned user]
@Whose

wie gesagt unter AROS nutze ich Datatypes zum sichern und speichere dort als JPEG, unter OS4 habe ich zwar auch datatypes Code ob der aber läuft weiß Ich z.Z. nicht.

Ich werde Thomas mal morgen anschreiben, schon alleine wegen der OS4 Includes zur library.

[ - Answer - Quote - Direct link - ]

2006-09-12, 03:14 h

whose
Posts: 2156
User
@DariusBrewka:

Naja, den OS4-Datatype-Code könnte ich testen. Thomas sowieso. Und noch einige andere mehr. Sagst halt Bescheid.

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

2006-09-12, 09:46 h

thomas
Posts: 7721
User

Unter OS4 kann man meines Wissens auch nur IFF mit Datatypes speichern. Eine Funktion zur Auswahl des Speicher-Typs gibt es soviel ich weiß weder unter OS3 noch unter OS4. Das Speichern miz Datatypes geht unter OS4 aber genauso wie unter OS3.

Die Includes für die jpeg.library unter OS4 kann ich dir heute abend heraussuchen. Das jpeg.l.main gibt's auf der PicShow-Homepage http://picshow.ch.to .

Die jpeg.library ist unter OS4 allerdings sehr lahm.

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-12, 10:32 h

DariusBrewka
Posts: 899
[Banned user]
@thomas

ja das wäre nicht schlecht, bin zwar bis heute abend Weg, schreibe dir aber gleiche eine Mail, wegen der Adresse (auch wenn's über meinen Account hier auch geht).

Die Includes wären schon nicht übel, damit Ich das nicht unnötig selber machen muß. Wie gesagt werde Ich versuchen den Autor der lib anzumailen ggf. kann man da was tun.

[ - Answer - Quote - Direct link - ]

2006-09-12, 16:03 h

Blackbird
Posts: 634
User
@thomas:

>Die jpeg.library ist unter OS4 allerdings sehr lahm.

welche Version benutzt du da ?

Ich hatte auch zu kämpfen mit der Lib unter PFPaint...
Ein User brachte dann aber hervor das man keine Lib nehmen sollte ohne FPU-unterstützung (er hatte die quasi bei sich installiert), dann ist die auch recht flott!
--
regards
Blackbird

Have a look at:
http://www.blackbird-net.de

Skins for PlayCD OS3.9
BlackShoot, Zombies Apocalypse, GalagaWars
PerfectPaint

[ - Answer - Quote - Direct link - ]

2006-09-12, 16:09 h

bubblebobble
Posts: 707
User
@Blackbird
Ja, das ist klar. Wenn keine spzeiellen Integer Tricks verwendet werden, ist FPU vs. Integer bei Floats etwa um den Faktor 10-20 langsamer. Und jpeg en/decodieren ist zu 90% Floatingpoint Herumrechnerei.

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


[ - Answer - Quote - Direct link - ]

2006-09-12, 16:56 h

ZeroG
Posts: 1488
User
@thomas:
@DariusBrewka:

Wenn ihr genau wissen wollt ob das "Datatype speichern" unter OS4 funktioniert, fragt Oliver, der hat die OS4-Datatypes geschrieben...

[ - Answer - Quote - Direct link - ]

2006-09-12, 17:29 h

thomas
Posts: 7721
User
@ZeroG:

Das weiß ich, aber hat er auch die datatypes.library geschrieben ? Hat er neue Funktionen eingebaut, die das Speichern von anderen Typen als IFF erlauben ? Wohl kaum, denn in der Doku tauchen sie nicht auf.

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-12, 20:10 h

bubblebobble
Posts: 707
User
@malte2
Den einzigen signifikanten Unterschied, den ich zwischen unseren beiden Sourcecodes sehen kann, ist dass du die Screenbitmap als Friendbitmap angibst, und den Colormap nicht direkt sondern mit GetRGB32 ausliesst (was auch sinn macht, aber im Falle von True Color ja keine Rolle spielt).
Und vielleicht den unterschied, dass du bmhdbmh_Depth fix auf 24 setzt, während ich den Depth Wert aus der Bitmapstruktur nehme.
Ausserdem igbts du einen Screen an.

Ich werde das mal genau testen. Aber ich will Bitmaps speichern, OÄHNE friendbitmaps, d.h. ohne screen. Es geht um ein Graphikprogramm, und ich will ja meine Bitmap nicht auf 16bit herunterrechnen, nur weil ich einen 16bit Screen zum darstellen nutze. Die Grafikdaten sollen selbstverständlich immer 24bit sein, und in einem Format, das ich kenne, da ich viele non-standard grafik Funktionen brauche, und die nicht für jedes Pixelformat implementieren will.

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


[ - Answer - Quote - Direct link - ]

2006-09-12, 23:02 h

DariusBrewka
Posts: 899
[Banned user]
Ich habe Oliver angeschrieben und Antwort erhalten. Ich muß mich aber an Paul wenden wegen den Source, die Adresse hat er mir gegeben, mal sehen was sich machen lässt.

@Thomas

Danke für die Dateien

[ - Answer - Quote - Direct link - ]

2006-09-13, 09:00 h

gni
Posts: 1106
User
Zitat:
thomas:
Hat er neue Funktionen eingebaut, die das Speichern von anderen Typen als IFF erlauben ?

Das muß doch eh der (Sub-)Datatype übernehmen. IFF-Erzeugung macht der picture.datatype, damit haben die (Sub-)DTs nichts zu tun.

[ - Answer - Quote - Direct link - ]

2006-09-13, 09:13 h

thomas
Posts: 7721
User
@gni:

Das Speichern selbst ist kein Problem, es gibt viele DT-Klassen, die speichern können. Das Problem ist, zu bestimmen, welches Format gespeichert werden soll. Beim Anlegen eines Datatype-Objects hat man keine Möglichkeit, zu sagen, welche Subklasse benutzt werden soll. Und bei DTM_WRITE gibt es auch nur IFF oder RAW zur Auswahl.

D.h. du kannst nur dann ein Bild als JPEG speichern, wenn du es vorher aus einer JPEG-Datei geladen hast. Das macht ja keinen Sinn.

Ich möchte eine im Speicher vorhandene Bitmap als JPEG speichern. Und dazu gibt es keine Möglichkeit.

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-13, 11:31 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von thomas:
Das Speichern selbst ist kein Problem, es gibt viele DT-Klassen, die speichern können. Das Problem ist, zu bestimmen, welches Format gespeichert werden soll. Beim Anlegen eines Datatype-Objects hat man keine Möglichkeit, zu sagen, welche Subklasse benutzt werden soll. Und bei DTM_WRITE gibt es auch nur IFF oder RAW zur Auswahl.


Also wie schon mehrmals gesagt geht das mit dem AROS picture-datatype, Ich habe das zwar für mich mal für 68k Compiliert, aber zu speichern habe ich damit noch nicht geschafft, ggf. lags an den anderen Datatypes.

code:
DTImage = NewDTObject((APTR)NULL,
                           DTA_SourceType, DTST_RAM,
                           DTA_BaseName, (IPTR)"jpeg",
                           PDTA_DestMode, PMODE_V43,
                           TAG_DONE);


kennst du ein jpeg.datatype welches speichern können soll?

[ - Answer - Quote - Direct link - ]

2006-09-14, 16:11 h

thomas
Posts: 7721
User
Zitat:
kennst du ein jpeg.datatype welches speichern können soll?

Wenn du so direkt fragst, offenbar nicht. Ich hatte in Erinnerung, daß die Warp-Datatypes alle speichern können, aber dem ist wohl nicht so.

Hier ist eine Liste mit Datatypes, die speichern können: http://www.google.de/search?q=site%3Aaminet.net+DTM_WRITE

Da sind zwei JPEG-Datatypes von Achim Stegemann dabei.

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-15, 02:54 h

DariusBrewka
Posts: 899
[Banned user]
hmm, ich habe jetzt den source zur jpeg.lib und habe diese für OS4 compiliert, aber ich denke nicht dass die Funktionieren wird.

Bzw. mir ist aufgefallen, dass ich ggf. entweder irgendwas Falsch mache oder alles ganz Einfach ist.

Ich denke mal, 68k Apps können auch auf PPC libs zugreifen oder?, dann stellt sich für mich die Frage, woher die Lib wissen soll, welche 68k Register zu welchem Parameter gehören?

Es sei denn 68k Apps können nicht auf PPC libs zugreifen, dann ist's einfach.

Wie gesagt habe ich kein OS4, habe aber für mein Programm schon Libs für OS4 geschrieben, die auch gingen.

[ - Answer - Quote - Direct link - ]

2006-09-15, 09:05 h

thomas
Posts: 7721
User
@DariusBrewka:

Zitat:
Ich denke mal, 68k Apps können auch auf PPC libs zugreifen oder?, dann stellt sich für mich die Frage, woher die Lib wissen soll, welche 68k Register zu welchem Parameter gehören?

Es sei denn 68k Apps können nicht auf PPC libs zugreifen, dann ist's einfach.


Du kannst du Lib nicht einfach so umwandeln, sondern du mußt den Startup-Code so umschreiben, daß die Library mindestens ein Interface hat (meistens "main"). Sonst können PPC-Apps die Library nicht benutzen. Für 68k-Apps muß die Jump-Tabelle auf Stub-Routinen zeigen, die die Register auslesen und in der richtigen Reihenfolge als Parameter an die eigentlichen Funktionen übergeben.

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-15, 10:10 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von thomas:
@DariusBrewka:
Du kannst du Lib nicht einfach so umwandeln, sondern du mußt den Startup-Code so umschreiben, daß die Library mindestens ein Interface hat (meistens "main"). Sonst können PPC-Apps die Library nicht benutzen.


das ist Klar, hab schließlich doch geschrieben, daß ich das schonmal gemacht habe.

Zitat:
Für 68k-Apps muß die Jump-Tabelle auf Stub-Routinen zeigen, die die Register auslesen und in der richtigen Reihenfolge als Parameter an die eigentlichen Funktionen übergeben.

werde's mir mal anschauen für PPC sollte es ggf. schon laufen, was passiert aber wenn die lib diesen 68k Patch nicht hat? denke die LIB kann dann nicht geöffnet werden oder?

Dann gibt's nochwas was gefixt werden muß für 68k, in den Includes gibt's HOOKS die für 68k die Parameter in Registern erwarten, mal sehen wie das gemacht werden kann (Ich glaube nicht, daß die Hooks z.Z jemals genutzt worden).

gruß und danke

Darius

[ Dieser Beitrag wurde von DariusBrewka am 15.09.2006 um 10:10 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]

2006-09-15, 11:41 h

DariusBrewka
Posts: 899
[Banned user]
Ist inzw. erledigt, mal sehen ob's läuft.

[ - Answer - Quote - Direct link - ]

2006-09-15, 19:24 h

ZeroG
Posts: 1488
User
@DariusBrewka:
Was ist den passiert? :dance3: Geistesblitz oder noch mal ins OS4 SDK gesehen?

[ - Answer - Quote - Direct link - ]

2006-09-16, 01:11 h

DariusBrewka
Posts: 899
[Banned user]
nee, nur mal in sources zu anderen combined-libs geschaut, das mit den Hooks, dafür habe ich nun auch eine Idee, d.h. wenn eine 68k APP den Hook nutzt wird mittels Emulate() dieser aufgerufen, ansonsten Nativ, die Frage nur woher wissen ob der Call von einer 68k App herrührt, schliesslich wird der 68k Libaufruf auf den PPC umgeleitet.

D.h. entweder ein Neues TAG hinzufügen für PPC Hooks, oder in den 68k Stubs ein Flag setzen was den 68k Call erzwingt oder anderswie herausfinden ob der Call von einer 68k App stammt? aber wie?

gruß

Darius

[ - Answer - Quote - Direct link - ]

2006-09-16, 09:58 h

thomas
Posts: 7721
User
@DariusBrewka:

Du solltest nicht die Herkunft prüfen, sondern die Hook-Funktion. Herausfinden, ob es sich um PPC-Code handelt kannst du mit TypeOfMem(adresse) & MEMF_EXECUTABLE (habe ich dir auch per Mail geschrieben).

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-16, 12:16 h

ZeroG
Posts: 1488
User
@DariusBrewka:
@thomas:
:dance3: Bin jetzt etwas verwirrt. Bei Hooks kümmert sich doch OS4 selbst darum das es keine 68k <-> PPC probleme gibt.
Siehe SDK:Documentation/Developer Info/General/os4_migration_guide.pdf

[ - Answer - Quote - Direct link - ]

2006-09-16, 12:43 h

thomas
Posts: 7721
User
@ZeroG:

Die jpeg.library benutzt keine richtigen Hooks, sondern erwartet nur die Adresse einer Funktion, die direkt aufgerufen wird (nicht mit CallHookPkt). Deshalb muß die Library sich selbst darum kümmern, ob sie 68K- oder PPC-Code aufruft.

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-16, 12:54 h

ZeroG
Posts: 1488
User
@thomas:
Achso.
Und wie läuft das ganze wenns ein WarpUp-"Hook" ist?

[ - Answer - Quote - Direct link - ]

2006-09-16, 13:02 h

thomas
Posts: 7721
User
@ZeroG:

Keine Ahnung. Aber soviel ich weiß, kümmert sich WarpUp ja auch nicht speziell um Hooks. D.h. du brauchst immer einen 68k-Stub, der dann den PPC-Code aufruft. Das gleiche geht dann auch hier.

Gruß Thomas

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

[ - Answer - Quote - Direct link - ]

2006-09-16, 13:31 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von thomas:
Du solltest nicht die Herkunft prüfen, sondern die Hook-Funktion. Herausfinden, ob es sich um PPC-Code handelt kannst du mit TypeOfMem(adresse) & MEMF_EXECUTABLE (habe ich dir auch per Mail geschrieben).


so habe ich das auch gemeint, schliesslich ist nicht zu erwarten, daß eine PPC Native App einen 68k Hook nutzt, aber man weiß ja nie wenn man alte sources mit ASM code nutzt.

[ - Answer - Quote - Direct link - ]

2006-09-16, 14:39 h

DariusBrewka
Posts: 899
[Banned user]
ist gemacht, aber gibt TypeOfMem() wirklich nur bei PPC Code MEMF_EXECUTABLE aus?

[ - Answer - Quote - Direct link - ]


1 -2- 3 [ - Post reply - ]


amiga-news.de Forum > Programmierung > jpeg's sichern unter OS4? [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2025 by amiga-news.de - all rights reserved.
.