AROS Picture DataTypes

miker1264 · 19967

« previous next »
Pages: 1 ... 4 5 6 7 8   Go Down

miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #75 on: September 22, 2019, 03:19:15 PM
Quote from: salvatore on September 22, 2019, 02:11:30 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, 03:54:44 PM by miker1264 »


Samurai_Crow

  • Junior Member
  • **
    • Posts: 88
    • Karma: +32/-0
  • Hobby coder
Reply #76 on: September 22, 2019, 05:59:55 PM
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

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #77 on: September 22, 2019, 10:16:51 PM
Quote from: Samurai_Crow on September 22, 2019, 05:59:55 PM
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, 12:13:33 AM by miker1264 »


salvatore

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


miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #79 on: September 26, 2019, 12: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, 01:04:37 AM by miker1264 »


miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #80 on: September 28, 2019, 01: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

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #81 on: December 15, 2019, 08:33:48 PM
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.


Amiwell

  • Legendary Member
  • *****
    • Posts: 2616
    • Karma: +35/-4
  • Peace
Reply #82 on: December 16, 2019, 07:55:26 AM
well miker thank's ;)


miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #83 on: January 01, 2020, 02: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

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #84 on: February 10, 2020, 11:46:37 PM
ILBM datatype can save 8 bitplanes and below.


aha

  • Junior Member
  • **
    • Posts: 66
    • Karma: +41/-0
Reply #85 on: February 11, 2020, 05:46:55 AM
Very good!  :D
Keep up the great work!


Amiwell

  • Legendary Member
  • *****
    • Posts: 2616
    • Karma: +35/-4
  • Peace
Reply #86 on: February 11, 2020, 08:46:43 AM
thank's miker :)


miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #87 on: February 14, 2020, 11:55:20 AM
As of yesterday ILBM datatype can also save IFF24 (ILBM Deep Image with 24 bitplanes). ILBM save functions are complete.


Amiwell

  • Legendary Member
  • *****
    • Posts: 2616
    • Karma: +35/-4
  • Peace
Reply #88 on: February 16, 2020, 06:06:54 AM
well miker :)


miker1264

  • Legendary Member
  • *****
    • Posts: 1827
    • Karma: +84/-6
Reply #89 on: February 16, 2020, 09:05:38 PM
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.


Pages: 1 ... 4 5 6 7 8   Go Up
« previous next »