What program language are you using? You need to expect more then one line of code to write a file. If I was you lookup and read about picture datatype in autodocs.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Yes, I saw DTM_WRITE but I'm afraid that it will change the type of picture...
DTM_WRITE -- Write the selected area of the picture to a file as an ILBM. If no area is selected, then the entire picture is saved.
I don't think so. DTM_WRITE is a general datatype method, so if the jpeg.datatype has this method implemented, it should save your image as JPEG. My guess at least.
As that topic about saves in datatypes brings from time to time (i remember in last year or two about 3-4 times with big-fat topics where ppls realise that there is no proper savers in most of datatypes), maybe it worth at least add BZ for enhancements ?
As i see, we have those default image datatypes in os4: bmp, gif, ilbm, jpeg, picture, png and tiff. I assume we can create just simple test case which should save an image in datatypes of our choice, and so i can add it to BZ as enhancement.
Till it not in BZ, no one will worry for sure, and topic will come up all the time.
Can you try plz from all the list of datatypes which i show, if any of them do have savers ? (i.e. test bmp, gif, ilbm, jpeg, png and tiff datatypes). Because i will go through all of them and post the same BZ, but will be not good if some of them already have savers.
And some test code also will be nice (using directly need it datatypes, without involving picture.datatype as i assume if it involved saving always will be in ILBM).
I will do it tomorrow but by curiosity, you said that it's a old discussion/problem therefore the datatype dev(s) must still know the problem, no ?
Nevertheless, I plan to make you a sample who : 1) load a picture by datatype 2) print his format 3) save the datatype as RAW in a new file 4) load this new file 5) print his format
Is it what you want, because I didn't understand the 2nd part of your reply "without involving picture.datatype" ?
but by curiosity, you said that it's a old discussion/problem therefore the datatype dev(s) must still know the problem, no ?
There is tons enhancement request in BZ, to works on which devs can spend next 100 years. How they will even think or remember about anything else, if it not in BZ ? Of course, savers in datatypes its something which you may think necessary, and so they all maybe too. But till its not in BZ, its all only will be talks and "yes, good to have".
Quote:
Nevertheless, I plan to make you a sample who : 1) load a picture by datatype 2) print his format 3) save the datatype as RAW in a new file 4) load this new file 5) print his format
Is it what you want ?
Yep
Quote:
because I didn't understand the 2nd part of your reply "without involving picture.datatype" ?
I am not in datatypes at all, but i about Andy's reply "If you create your data type as an picture.datatype to start with (rather than some subclass) then it'll get saved as a ILBM". So i assume from that reply there is some ways when you will always have save in ILBM does not matter what (even if you will have savers in another datatypes).
Forget Datatypes. They work only for loading. Saving is broken on most systems, and will result in crash, broken IFF file or sonmething else unpredicatable. Believe me, I have tried this. Even if saving works (it works with *some* datatype), it will be only IFF, and often only color index. Still, you functionality is heavily dependent on what the user has installed, and you cannot verify it for correctness.
So again, dont even try to mess with datatypes.
If you want to save jpeg, use the jpeg.library. This is relatively easy, reliable and fast, and you can make your programm complain about it if not installed.
If you use Amiblitz3, you have savers for IFF, PNG, JPEG and BMP build in. You could also write your own BMP saver, which is rather trivial, and then call an external image converting tool to produce the desired format.
I finished to test all the formats. As suspected all formats are saved as ILBM. BMP : test.BMP is a picture (BMP) new file test.BMP.BMP is a ILBM picture DTM_WRITE KO for Datatype BMP
GIF : test.GIF is a picture (GIF) new file test.GIF.GIF is a ILBM picture DTM_WRITE KO for Datatype GIF
ILBM : test.ILBM is a picture (ILBM) new file test.ILBM.ILBM is a ILBM picture DTM_WRITE OK for Datatype ILBM
JPG : test.JPG is a picture (JPEG) new file test.JPG.JPEG is a ILBM picture DTM_WRITE KO for Datatype JPEG
PNG : test.PNG is a picture (PNG) new file test.PNG.PNG is a ILBM picture DTM_WRITE KO for Datatype PNG
TIFF : test.TIFF is a picture (JPEG) (shown as JPEG ??? ) new file test.TIFF.JPEG is a ILBM picture DTM_WRITE KO for Datatype JPEG
file_name is open and rewritte as file_name.TYPE (test.BMP will be saved as test.BMP.BMP)
@Wanderer Thank you, The results pictures are ILBM but they are fine, no color alteration for waht I see. But your idea to use libPNG (for example) to save picture seems nice.
Is it possible to use libPNG to create picture file from a Bitmap structure ?
Would be nice to use a thing like that for my FastView program ;)
If it works for your setup, it doesnt mean it works on others setups. E.g. on OS3.x it wont save 24bit bitmaps. Under AfAOS (and AROS) it is (at least was some time ago) completely broken and crashes. There are also various pictrue.datatype implementations/updates/sidegrades etc. out there with different behaviour. So if you want to relase your program to the public, avoid datatypes for saving.
If you code in C, there are many PNG and jpeg libs out there, I would use them. You can not save the bitmap structure as-is, in most cases you will need to create PixelArray out of the bitmap that has a well-defined pixel format, such as PFMT_ARGB, depending on what the lib needs. You typically need a RastPort on the bitmap and then call ReadPixelArray().
Wanderer wrote: If it works for your setup, it doesnt mean it works on others setups. E.g. on OS3.x it wont save 24bit bitmaps. Under AfAOS (and AROS) it is (at least was some time ago) completely broken and crashes.
This is the "AmigaOS4" section so what other platforms do is not really relevant here.
Quote:
There are also various pictrue.datatype implementations/updates/sidegrades etc. out there with different behaviour. So if you want to relase your program to the public, avoid datatypes for saving.
If there are replacements for the AmigaOS 4.x picture.datatype, I'd like to work with those authors to make them obsolete.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
