New Picture Datatypes

[Amiwell]

great miker thank you

[AMIGASYSTEM]

miker i noticed that on AROS x86 all the Graphics Descriptors point to "def_Picture.info" and don't recognize the single def (def_JPG, def_BMP, def_PNG etc..), to make them recognize I had to make a small change to many of the Descriptors, even to your Targa Datatype.

Also on AROS 68k there is the same problem, on this OS I didn't succeed because the Descriptors created with "Createdtd" are not supported on 68k, I tried also "dtmake" native OS3, "dtmake it works well on AROS 68k but its Decryptors are not supported.

In the end I solved on AROS 68k using Deficons OS3, in this way also on OS3 image files are recognized by single format

[miker1264]

I'm sure x86 was set up to use def_Picture.info.

But you can certainly customize it how you'd like. 

[AMIGASYSTEM]

I customized it because I'm used to see it on OS3, OS4 and MOS, of course it's not important and it brings more work.

Once it was important to have this kind of recognition because a lot of images or other kind of files on Amiga were without extensions, so it was useful to understand what was really a File, now it's more difficult to find files without extensions.

[miker1264]

That's one of the things I like about AROS & Amiga - the ability to read the file signature rather than just the extension.

In Windows apps especially the file extension is used extensively without checking the file signature. If the user changes the file extension that messes with the graphics app. So it won't open!

[AMIGASYSTEM]

In fact on Windows it was a technique to infect operating systems, in practice in some cases an executable was disguised as an image with the double extension (.exe.jpg), in this way the user clicked believing to see an image instead executed a malicious executable.
Windows, if there are two extensions, sees only the last one.

On AROS One even if you remove the extensions many formats are recognized individually for the true graphics format.


No Extension file:

[AMIGASYSTEM]

Regarding archives without extension you have to be careful, even if Wanderer recognizes the archive, the application will have to do it too.

For example for Multiview Images it has no problem to recognize and display an image without extension.
 
For archives I have noticed that even though the archive without extension is recognized, ZuneARC and RNOArchive do not recognize the archive while UnARC recognizes and unzip it without problems.


On Windows there are applications like Word that recognize files without extension, to do this just drag the file to its GUI.

[AMIGASYSTEM]

Finally I managed to get Wanderer to recognize "LHA, LZH, LZX, RAR, TAR, TAR.GZ, TGZ, ZIP, TAR.BZ2" atchive formats even without an extension, i will make a comprehensive video

Even MOS can't recognize some of these formats if they don't have an extension

[miker1264]

Over the last few days I've finished up WriteTarga for Targa Datatype, updated BMP Datatype, and started writing an internal decoder for TIFF Datatype.

Yesterday and last night I wrote a Run Length Encoding Algorithm for PCX Datatype for the WritePCX function. It's coming along nicely and it should be ready to upload soon.

So I've been slacking lately as you can tell. 

[miker1264]

Saving my first 8bit PCX image with my new RLE Compression Algorithm.

It may be small but it's very significant. 

[Amiwell]

great miker 

[miker1264]

It seems the RLE Compression Algorithm for PCX Datatype works great for small images. But for larger images there are random errors in the output image data.

So I set up a debug log that prints every runcount for each byte for each scanline. Then I saved it to a text file. When compared to the output data sure enough there were random errors in the data. But when I looked at the log all the runcounts were correct.

So the PCX RLE Compression Algorithm works great. But the write method introduces errors.

I've been using FWrite because it saves time and effort. I will use my own WriteBytes function instead but I will need to manually keep track of offsets.

I suspected FWrite was causing problems because the colormap of 256 colors gets written at the end of the pixel data. But the colormap also had random errors. So I substituted my WriteBytes function to write the colormap to file. After that the colormap data looked great. No errors!

So my honest conclusion is that...using FWrite is easier but it may be better to make your own write function. 

[miker1264]

Ah! Success at last.

It seems that FWrite was wrongfully accused. It was programmer error! 

At first I had the alignwidth of the scanline length set to (width + 3) & ~3UL  which was modulus 4.
But I couldn't figure out why I was getting extra bytes at the end of my scanlines! It didn't match the original.
But then I remembered that the file spec said pcx was modulus 2, so I changed it: (width + 1) & ~1UL

The Tatoosh Mountain photo had a size of 513x405. When I examined the data I still had an extra byte at the end.
But then I realized...513 modulus 4 is 516 which add 3 extra bytes. 513 modulus 2 is 514 which adds 1 byte at the end.

So I removed the padding bytes making it alignwidth = width; for 8bit and alignwidth = (width*3) for 24bit rgb. Saving 8bit works great.

My padding bytes caused what I thought was "random errors". FWrite is not to blame! 

[AMIGASYSTEM]

In the end you always find the right way when you have a lot of will and passion !

[miker1264]

In the end you always find the right way when you have a lot of will and passion !

Not a lot of free time for programming.

But lots of determination and passion for AROS.