AROS Picture DataTypes

miker1264 · 4934

miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #75 on: September 22, 2019, 10:19:15 PM
ok thank's

Sure! But I'm done yet.

Load_ BMP (though it wasn't written by me) doesn't meet my three main criteria for picture datatypes:

It should be "Coherent, Concise & Effective".

It isn't Coherent with Buffered Read Operations that are difficult to follow if there's a problem. There is definitely a problem here!

It is Concise. Other than "Buffered Reads" it has the minimal amount of code for the desired effects.

It's not effective because it's not "inclusive". Saying "if( depth != 24 )" //get colormap isn't effective. What if depth is 32? Instead it shoud say "if( depth <= 8 )" //get colormap. That's more effective. Reading one scanline at a time is a Buffered Read. That's enough for C code that is already fast.

Having said all that, I do admire the style in which Load_ILBM is written for the ILBM datatype. Its Coherent, Concise, Well-Organized, Effective & All-Inclusive.  ;)

With that in mind I will re-write the entire Load_BMP function with Direct Read Methods which I have already proven to be effective with Alpha Transparency for BMPX files.

(Sorry - salvatore didn't get the last word again) 😛
« Last Edit: September 22, 2019, 10:54:44 PM by miker1264 »



Samurai_Crow

  • Junior Member
  • **
    • Posts: 60
    • Karma: +1/-0
  • Hobby coder
Reply #76 on: September 23, 2019, 12:59:55 AM
The reversed byte ordering probably means you're running big endian code on a little endian PC.  There should be a macro in the developer kit with byte swapping.  That way it only takes a BSWAP opcode on 486.



miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #77 on: September 23, 2019, 05:16:51 AM
The reversed byte ordering probably means you're running big endian code on a little endian PC.  There should be a macro in the developer kit with byte swapping.  That way it only takes a BSWAP opcode on 486.

That's a very good point.

I thought perhaps there was a problem in Load_BMP but that may not be the case.

Here is the situation:
I re-wrote Load_BMP to read the file directly. But the Alpha bytes are still 0xFF. I'm back to my original suspicion that READPIXELARRAY works fine when the PBPAFMT of source matches destination such as PNG stored as ARGB and read as ARGB. But BMPX is RGBA.

When I Save BMPX from PNG the soure pixel format for PNG is ARGB. That works fine.

When using the datatype in my graphics program I must use READPIXELARRAY with PBPAFMT_ARGB. So the datatypes system (READPIXELARRAY) is forced to convert RGBA to ARGB. Something happens in the conversion process and the Alpha in RGBA doesn't get copied from source to destination.

I may be going far out on a limb making assumptions without enough information. But it seems very strange that the initial values in READPIXELARRAY are: r=0, g=0, b=0, a=0xff. I'll keep testing the datatype. The problem with RGBA converting Alpha bytes to 0xff seems to be internal. I will direct my question to the Developers Mailing List to see if anyone there has an idea as to why alpha bytes are not being copied correctly from the source to the destination byte arrays.

The Endianess should be handled when the bytes are swapped around. But I'll consider that also as a probable cause.


« Last Edit: September 23, 2019, 07:13:33 AM by miker1264 »



salvatore

  • Guest
Reply #78 on: September 23, 2019, 08:38:50 AM
good job miker :)



miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #79 on: September 26, 2019, 07:14:48 PM
I am currently working on Save_ILBM for the ILBM datatype. Note: I am not altering the Load_ILBM. I'm just adding save functions so we can finally save as iff in MuliView.

I'm working on Save_BitMapPic first to save ILBM images of 8 bitplanes and below.
« Last Edit: September 28, 2019, 08:04:37 AM by miker1264 »



miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #80 on: September 28, 2019, 08:13:38 AM
I'm revising the SaveBitMapPic code to be used in the ilbm datatype. I'm testing it on Icaros Desktop Native.



miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #81 on: December 16, 2019, 03:33:48 AM
I have successfully compiled the TGA and PCX datatypes for AROS 64bit (ABIv1). TGA and PCX are currently missing their save functions.

I have also started the PCX Save function and I will soon start the TGA (targa) Save function and then work on ILBM Save functions after.

Here is the current version of the PCX datatype. Note: it currently saves a valid PNM file not a PCX yet. That's my starting point to work on.



salvo

  • Senior Member
  • ****
    • Posts: 498
    • Karma: +7/-0
  • Invalid Civil
    • Youtube Music Channel
Reply #82 on: December 16, 2019, 02:55:26 PM
well miker thank's ;)

TinyAros on Lenovo M70 intel dual core 3.20 Ghz, SSD 120 Gb, 4 Gb Ram DDR3, Nvidia Geforce 8400 GS 512 Mb DDR3


miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #83 on: January 01, 2020, 09:48:06 PM
As far as AROS Picture Datatypes, PCX, TGA & ILBM now use temporary save functions to save valid PNM files!  That is the starting point so that I can now insert my save functions. I am especially pleased about the ILBM datatype. It was very elusive for a while now. Nothing seemed to work till I realized that the error message on Hosted on Linux is displayed in the terminal output. The error for ILBM was: "DTM_Write not implemented". So I checked the ilbm.conf file and sure enough it wasn't there. So I enabled DTM_Write and recompiled ILBM.datatype. Now the MultiView Save As will save a valid PNM when a 24bit ILBM is opened. Save As IFF from the menu still isn't working for MultiView on 64bit but that probably has to do with DTM_Write_IFF or it expects an IFFHandle instead of BPTR. But that will be worked out soon.



miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #84 on: February 11, 2020, 06:46:37 AM
ILBM datatype can save 8 bitplanes and below.



aha

  • Newbie
  • *
    • Posts: 47
    • Karma: +0/-0
Reply #85 on: February 11, 2020, 12:46:55 PM
Very good!  :D
Keep up the great work!



salvo

  • Senior Member
  • ****
    • Posts: 498
    • Karma: +7/-0
  • Invalid Civil
    • Youtube Music Channel
Reply #86 on: February 11, 2020, 03:46:43 PM
thank's miker :)

TinyAros on Lenovo M70 intel dual core 3.20 Ghz, SSD 120 Gb, 4 Gb Ram DDR3, Nvidia Geforce 8400 GS 512 Mb DDR3


miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #87 on: February 14, 2020, 06:55:20 PM
As of yesterday ILBM datatype can also save IFF24 (ILBM Deep Image with 24 bitplanes). ILBM save functions are complete.



salvo

  • Senior Member
  • ****
    • Posts: 498
    • Karma: +7/-0
  • Invalid Civil
    • Youtube Music Channel
Reply #88 on: February 16, 2020, 01:06:54 PM
well miker :)

TinyAros on Lenovo M70 intel dual core 3.20 Ghz, SSD 120 Gb, 4 Gb Ram DDR3, Nvidia Geforce 8400 GS 512 Mb DDR3


miker1264

  • Senior Member
  • ****
    • Posts: 422
    • Karma: +14/-1
Reply #89 on: February 17, 2020, 04:05:38 AM
Just submitted ILBM Datatype to AROS Repository. I'll try to upload the 64bit version to AROS Archives as soon as I can. Followed by the 32bit version.