AROS Exec

Distros => Icaros Desktop => Topic started by: miker1264 on February 22, 2020, 05:37:47 AM

Title: New Picture Datatypes
Post by: miker1264 on February 22, 2020, 05:37:47 AM
I have made so much progress in the last few weeks while writing Save Functions for existing Picture Datatypes. I have finished BMP datatype, ILBM datatype, Targa datatype and I'm now working on PCX datatype. Maybe I'll add a Save_SVG for SVG datatype. But after that I might try my hand at writing a few new picture datatypes including TIFF datatype which will then become the AROS TIFF Datatype.

Over the last few days I modified AROS JPEG datatype to allow it to Load 8bit JPEG (Greyscale) which is popular among Comic Strip Websites such as AlphaLuna and others. It works for 8bit JPEG now!

@paolone
After I finish Save_PCX I'll send you the 64bit versions of the new datatypes, provide the source code for anyone else who may want to compile them, and I'll compile datatypes for 32bit Icaros Desktop.
Title: Re: New Picture Datatypes
Post by: salvo on February 22, 2020, 12:28:46 PM
great news miker :)
Title: Re: New Picture Datatypes
Post by: miker1264 on March 01, 2020, 04:45:02 PM
Several picture datatypes have been fixed up. I'll send them to paolone soon for IcarosDesktop.
Title: Re: New Picture Datatypes
Post by: miker1264 on March 01, 2020, 06:35:30 PM
paolone

Here are the sources and 64bit binaries for the newest picture datatypes if you'd like to include them in IcarosDesktop x86-64.

The 32bit versions will follow soon when I compile them using Yannick's PicDtCreationTool on IcarosDesktop 32bit. I've included sources if you'd like to try compiling them.
Title: Re: New Picture Datatypes
Post by: miker1264 on March 01, 2020, 06:43:11 PM
paolone

I have included BMP which is much more compatible now, GIF which is more stable on 64bit, ILBM with Save Functions, JPEG which can now Load 8bit and 24bit JPEG, and Targa which can now Save TGA (24bit).

 I'm especially pleased that BMP datatype can now show 32bit BMP files with transparency.I wrote the Save BMP function for it and Kalamatee helped to fine tune Load BMP! Thanks to Kalamatee!!

I'm still working on Save PCX for PCX datatype. Note: Only the new versions of BMP and GIF have been submitted to AROS Main Repository. So these are all new picture datatypes - Hot off the presses!

Title: Re: New Picture Datatypes
Post by: salvo on March 01, 2020, 07:00:27 PM
great miker :)
Title: Re: New Picture Datatypes
Post by: paolone on March 02, 2020, 05:51:03 PM
paolone

I have included BMP which is much more compatible now, GIF which is more stable on 64bit, ILBM with Save Functions, JPEG which can now Load 8bit and 24bit JPEG, and Targa which can now Save TGA (24bit).

 I'm especially pleased that BMP datatype can now show 32bit BMP files with transparency.I wrote the Save BMP function for it and Kalamatee helped to fine tune Load BMP! Thanks to Kalamatee!!

I'm still working on Save PCX for PCX datatype. Note: Only the new versions of BMP and GIF have been submitted to AROS Main Repository. So these are all new picture datatypes - Hot off the presses!


Thank you for all your efforts, Miker! I can't wait for 32bit versions as well (which are still my priority).
Title: Re: New Picture Datatypes
Post by: miker1264 on March 02, 2020, 06:19:32 PM
I should be able to compile 32bit versions today or tomorrow using PicDtCreation tool depending on my schedule.
Title: Re: New Picture Datatypes
Post by: paolone on April 02, 2020, 07:04:35 PM
Just a little thank you: thanks to the latest bmp.datatype you gave me, the program SnapShoter finally worked on ICAROS! I've had issues with it before, but now it loads and works like a charm.


It failed loading its own skin, before.
Title: Re: New Picture Datatypes
Post by: miker1264 on April 12, 2020, 11:07:09 PM
No problem.

I included the sources as far as I recall so that you or someone else could compile for IcarosDesktop.
Title: Re: New Picture Datatypes
Post by: salvo on April 13, 2020, 01:09:24 PM
Paolone has always worked for me snapshorter and I don't seem to have the new updates, I only compiled the alt-abiv0 branch
Title: Re: New Picture Datatypes
Post by: salvo on April 13, 2020, 08:34:22 PM
miker it is possible to have the new pictureDT for my distribution
Title: Re: New Picture Datatypes
Post by: miker1264 on April 13, 2020, 09:35:14 PM
Yes. I will make a definite effort to compile all the revised datatypes for 32bit in the next two days. Ill post them here.
Title: Re: New Picture Datatypes
Post by: miker1264 on April 14, 2020, 03:45:56 AM
New 32bit.
Title: Re: New Picture Datatypes
Post by: miker1264 on April 14, 2020, 03:53:45 AM
I'll try to compile the other revised datatypes for 32bit tomorrow or by Wed.
I have updated sources for gif and ilbm and jpeg as well as picture datatype to compile for IcarosDesktop.
Title: Re: New Picture Datatypes
Post by: paolone on April 14, 2020, 10:11:30 AM
I'll try to compile the other revised datatypes for 32bit tomorrow or by Wed.
I have updated sources for gif and ilbm and jpeg as well as picture datatype to compile for IcarosDesktop.
Thanks. I'd need for them as well.
Title: Re: New Picture Datatypes
Post by: salvo on April 14, 2020, 02:42:22 PM
thank you again miker :)
Title: Re: New Picture Datatypes
Post by: miker1264 on May 04, 2020, 04:37:43 PM
I have an updated GIF datatype that now works on 32bit and 64bit. I also have an updated JPEG datatype that can load 8bit grayscale and 24bit rgb. And I have nearly completed ILBM datatype and an updated picture datatype which will allow to use "Save As IFF" in MultiView to save images as an ILBM.

These are all coming soon for AROS 32bit.
Title: Re: New Picture Datatypes
Post by: salvo on May 04, 2020, 07:05:23 PM
thank you miker
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on May 04, 2020, 11:18:55 PM
I have an updated GIF datatype that now works on 32bit and 64bit. I also have an updated JPEG datatype that can load 8bit grayscale and 24bit rgb. And I have nearly completed ILBM datatype and an updated picture datatype which will allow to use "Save As IFF" in MultiView to save images as an ILBM.

These are all coming soon for AROS 32bit.

Ciao miker, are there also 68k versions for AROS 68 and OS3?
Title: Re: New Picture Datatypes
Post by: miker1264 on May 05, 2020, 12:23:19 AM
Yes. There are compiled 68k versions as well. The GIF datatype hasn't changed for 68k only compatibility for 64bit. The JPEG datatype doesn't read 8bit grayscale correctly on 68k yet for some reason so it isnt quite ready yet. There are experimental 68k versions of ILBM datatype and picture datatypes for 68k.

I'm not sure AROS 68k datatypes work on OS3.
Title: Re: New Picture Datatypes
Post by: miker1264 on May 07, 2020, 04:47:29 PM
I forgot to mention that I'm also working on Save Functions for TARGA and PCX datatypes. TARGA dataype works so I'll compile it for 32bit and 64bit and 68k soon.

I was told previously that if my sources have been committed then I don't need to post the binaries. But I disagree. So I will make an effort to post all the modified datatype files to AROS Archives?

I also have a version of MultiView that uses Save As PNG as well as Save As IFF. I'll post that one as well for you all.
Title: Re: New Picture Datatypes
Post by: salvo on May 07, 2020, 05:48:58 PM
thank you miker
Title: Re: New Picture Datatypes
Post by: aha on May 10, 2020, 01:23:41 PM
This is brillant. Thank you, miker1264!
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on March 05, 2021, 05:27:25 PM
Hi miker, is there any news about TIFF datatype 32Bit? TIFF images are not supported by Multiview and PicShow on AROS.

With BMP Datatypes, does saving files in IFF work on 32Bit systems?

Thanks again for everything you do :)
Title: Re: New Picture Datatypes
Post by: miker1264 on March 05, 2021, 06:34:45 PM
Hi miker, is there any news about TIFF datatype 32Bit? TIFF images are not supported by Multiview and PicShow on AROS.

With BMP Datatypes, does saving files in IFF work on 32Bit systems?

Thanks again for everything you do :)

Not sure about TIFF datatype. I'll look into that. I suppose I would start by supporting Baseline TIFF 6.0 then add to it. I will start a TIFF datatype. But I will need some good TIFF Images for testing the datatype.

I might also look at adding "WhichPicture" & "NumPictures" Tags to picture datatype so that INFO datatype may work as intended.

When you mention BMP datatype you have to be more specific. There is Windows Bitmap (BMP) and Amiga ILBM.

I added DT_WRITE to picture datatype so it is now possible to use MultiView to Save As IFF. At the moment it is limited to ILBM images of 8bitplanes and below. I haven't yet added the code for ILBM Deep Images of 24bitplanes. That will be added.

I haven't committed the changes for this yet. I had a disagreement about the format of the BMHD whether it should be an array of 10 WORD values or as I originally had it an array of 20 bytes using bit shifting. I can compile it as is. It works.

It also works to Save As IFF in 68k.  ;)

P.S. - As soon as I make a new png app icon and ss soon as I set up my ABIv0 Build System I will compile my version of MultiView that can Save As IFF and Save As PNG. Some developers feel that MultiView should be "Pure" and not contaminated with new features. So this version will be the "Unofficial SuperMultiView.

Title: Re: New Picture Datatypes
Post by: miker1264 on March 07, 2021, 08:27:15 PM
I have started a project for TIFF Datatype.

Initially it will support Baseline TIFF then Extended TIFF.

TIFF File Format supports storing multiple images.

This should be fun!  :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on March 07, 2021, 10:16:31 PM
Thanks miker, since you are so good in graphics, can you tell me why a TGA image saved by XnViewMP I see it upside down (opposite) see screenshot, if instead I save the TGA image with IrfanView is instead perfect!
Title: Re: New Picture Datatypes
Post by: miker1264 on March 08, 2021, 04:02:42 AM
Thanks miker, since you are so good in graphics, can you tell me why a TGA image saved by XnViewMP I see it upside down (opposite) see screenshot, if instead I save the TGA image with IrfanView is instead perfect!

AMIGASYSTEM

As far as I recall the Targa File Format is very similar to Windows Bitmap. The scanlines are stored upside down so that the first line in the image is on the bottom. I believe the pixel elements are also swapped so that RGB becomes BGR.

So if the graphics program saving the Targa File neglects to Flip the Image then the first scanline will be on top now instead of on the bottom. Any other graphics app trying to read that Targa file will naturally expect to read from bottom to top. So the bad Targa Image will appear to be upside down.

AROS Targa Datatype can save Targa Images. Well, at least mine can. Did I commit my changes for Save Targa? I will commit it.  :)

The Targa Datatype and PCX Datatype are both part of Contribs so I may simply release the revised dataypes on AROS Archives and Aminet for AROS 32bit, 64bit, and 68k. I may do the same with the revised JPEG Datatype I have. It can load 8bit black and white JPEG Images as well as 24bit RGB. But it can only save 24bit RGB. I suppose I could allow it to save 8bit JPEG if we have an 8bit Image to save. But I believe loading 8bit is good.

Title: Re: New Picture Datatypes
Post by: miker1264 on March 08, 2021, 05:38:51 AM
AMIGASYSTEM

The AROS TIFF Datatype is coming along nicely.

TIFF Files contain multiple IFD's which are Image Directories. But AROS can't display multiple images using datatypes.

To limit the scope TIFF Datatype will only Read RGB TIFF Images and it will only Read the First IFD. It will only Write RGB and only the First IFD. TIFF File Format cam be rather complicated. It seems about as complicated as JPEG File Format is to me. But I have good sources of information.

I have started writing TIFF Datatype the way I usually do. I set up the directory for TIFF in my build system umder "Classes/Datatypes". I copied all files from PNM Datatype which seems like the most basic, simplistic datatype. I'm only using the structure of PNM as a starting framework. I modified all the files to comply with building TIFF though internally it's still PNM. I also changed the TIFF.dtd datatype descriptor. Then I did a make for tiff datatype and it built correctly.

Now I can just focus on LoadTIFF and SaveTIFF functions.  :)

Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on March 08, 2021, 08:44:32 AM
Thank you for the information and thank you for all you do to improve AROS.
Title: Re: New Picture Datatypes
Post by: salvo on March 08, 2021, 01:48:44 PM
miker thank you for your precious job :)
Title: Re: New Picture Datatypes
Post by: miker1264 on March 18, 2021, 08:06:24 AM
The new TIFF Datatype is working nicely.  8)
Title: Re: New Picture Datatypes
Post by: paolone on March 18, 2021, 10:21:32 AM
Great!!!
Title: Re: New Picture Datatypes
Post by: aha on March 18, 2021, 12:12:22 PM
Thank you!  :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on March 18, 2021, 03:05:41 PM
Geazie miker, great job !
Title: Re: New Picture Datatypes
Post by: miker1264 on March 18, 2021, 04:47:29 PM
AMIGASYSTEM

Grazie! Prego !!

I've taken a short break from Icons to work on datatypes. Actually, I started working on TIFF Datatype because you asked for it. I've been working on the new datatype for about 10 days.

It supports loading and saving Single 24bit RGB Tiff Images. It will ultimately support loading and saving 8bit, 24bit, 32bit and greyscale images. But we must start somewhere.  :)
Title: Re: New Picture Datatypes
Post by: salvo on March 18, 2021, 08:25:34 PM
good job miker :D
Title: Re: New Picture Datatypes
Post by: mmartinka on March 19, 2021, 12:35:07 PM
Amazing...  8)
Title: Re: New Picture Datatypes
Post by: miker1264 on March 21, 2021, 07:54:32 PM
Mostly for use with TIFF Datatype but useful for other datatypes for image files that can store multiple images such as INFO, ICO, ICNS, etc. I have added "WhichPicture" & "GetNumPictures" PDTA Methods to the AROS picture datatype.

So now we can display multiple images using picture datatypes!

I will be interested in testing with TIFF Datatype. It would be easy to add a function to Count Image Directories (IFD's) for GetNumPictures. I can use "bmp2tiff" to add multiple images to a test tiff file for that purpose.

I will be releasing the first version of TIFF Datatype very soon.  :)
Title: Re: New Picture Datatypes
Post by: miker1264 on March 23, 2021, 06:52:26 AM
This will be a first for AROS.

TIFF Datatype can count directories using PDTA_GetNumPictures and it can set a directory current using PDTA_WhichPicture. So now it can display Multiple Images.

This colorful gameplay image from "Anno 1404: Venice" is actually the second image in a TIFF file containing two images.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on March 23, 2021, 12:05:16 PM
Thanks miker you are doing a great job for the community !
Title: Re: New Picture Datatypes
Post by: aha on March 23, 2021, 01:01:27 PM
It looks great, miker! Great job with the datatype as well.  :)
Title: Re: New Picture Datatypes
Post by: miker1264 on March 24, 2021, 06:08:34 PM
I have updated Picture Datatype with DT_Write for Save As IFF.

It can now write ILBM with 8bitplanes & below, as well as ILBM Deep Images with 24bitplanes.

I will update ILBM Datatype soon and compile both datatypes for 32bit. I will post the binaries here & source code for both as well as TIFF Datatype.

@deadwood

I have submitted a PR for TIFF Datatype for ABIv1 but as far as I know only Mazze is handling Pull Requests atm. The other two, Picture & ILBM Datatypes will soon follow.

Should I submit a PR for each for ABIv0 ?
Title: Re: New Picture Datatypes
Post by: salvo on March 31, 2021, 01:24:24 PM
miker maybe and better suggest here to deadwood of your changes thanks

https://ae.amigalife.org/index.php?topic=681.0

ciao
Title: Re: New Picture Datatypes
Post by: miker1264 on April 07, 2021, 04:20:37 AM
Hello again.

Update. My additions to Picture Datatype have been committed to the ABIv1 sources.

Now Save As IFF in MultiView will allow saving ILBM images.

Also two new methods "WhichPicture" and "GetNumPictures" have been added.

Maybe we can also bring this to IcarosDesktop for ABIv0.
Title: Re: New Picture Datatypes
Post by: deadwood on April 07, 2021, 09:31:32 AM
I'll see if I can integrate these changes over weekend. Do I only need to bring changes from 31.03, 4.04 and 5.04?
Title: Re: New Picture Datatypes
Post by: miker1264 on April 07, 2021, 02:31:09 PM
@deadwood

There were changes in methods.h pictureclass.h and pictureclass.c modules. Also "STATIC" was dropped from function names. So the new function is "IPTR DT_Write".

We tested the picture datatype after committing changes. It was working well with MultiView. I will post a few test images here.

For Save As IFF it can save ILBM images with 8bitplanes and below and also 24bitplanes.
Title: Re: New Picture Datatypes
Post by: deadwood on April 07, 2021, 05:06:15 PM
Where there any changes needed in Multiview? If so, when were they comitted?
Title: Re: New Picture Datatypes
Post by: miker1264 on April 07, 2021, 05:33:14 PM
@deadwood

MultiView automatically detects if DTWM_IFF is enabled in Picture Datatype.

But DTM_Write needs to be enabled in picture.conf file just below DT_PRINT on line 43. Add:

DTM_WRITE
.function DT_Write

If it isn't already enabled.

I was looking at your repository at:
github.com/deadwOOd/AROS
if that is the correct location for the current ABIv0 sources.

It seems DTM_WRITE is enabled. Mazze had enabled it in ABIv1 some time ago but he didn't have the Save ILBM for DT_Write. The current version of Picture Datatype for ABIv1 is 41.6 and yours is 41.5 so they are very similar. Just add the new DT_Write and two new methods (attributes). WhichPicture, GetNumPictures. DT_Write is already present at line 1604.

I included IFF Sample Images here as attached file.
You can also open 8bit or 24bit images in MultiView and Save As IFF. I can help test Picture Datatype and MultiView after you integrate the changes.
Title: Re: New Picture Datatypes
Post by: deadwood on April 07, 2021, 06:37:37 PM
Ok, thanks
Title: Re: New Picture Datatypes
Post by: miker1264 on April 07, 2021, 06:55:40 PM
@deadwood

Is that the correct location for the current ABIv0 repository ?

github.com/deadwOOd/AROS

I see from a previous post that it is the correct location.

It may save you some effort if I simply fork your repo and make a new branch to submit a PR for changes to your Picture Datatype. I have a few other changes to submit also.
Title: Re: New Picture Datatypes
Post by: deadwood on April 07, 2021, 10:14:27 PM
Here is ABI_V0 branch:

https://github.com/deadw00d/AROS/tree/alt-abiv0
Title: Re: New Picture Datatypes
Post by: miker1264 on April 18, 2021, 04:40:21 AM
This isn't really a datatype, but it is datatype related.

A newer version of MultiView can Save As IFF and Save As PNG.

Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 18, 2021, 09:42:32 AM
Thanks, Multiview is definitely the best viewer.

On my AROS One i associated images to PicShow because to see all the images in a folder you only need to click one.

However there is the excellent LoView that also allows SlideSow and image saving in IFF, JPG, PNG and BMP formats.
LoView doesn't seem to work well on AROS because the association doesn't work, only the Request for path selection appears, on OS3 it works fine instead.
Title: Re: New Picture Datatypes
Post by: miker1264 on April 20, 2021, 05:04:27 AM
Testing the New Picture Datatype and Super-MultiView with Save As IFF & Save As PNG in my "AROS Vanilla" 68k Version...
Title: Re: New Picture Datatypes
Post by: miker1264 on April 20, 2021, 05:06:14 AM
Here is S-MultiView compiled for X86_64 as well as 68k.
Title: Re: New Picture Datatypes
Post by: miker1264 on April 20, 2021, 05:09:31 AM
Here is New Picture Datatype compiled for X86_64 as well as 68k.
Title: Re: New Picture Datatypes
Post by: miker1264 on April 20, 2021, 05:19:15 AM
Darn!!

My JPEG Datatype Update to Load 8bit Grayscale JPEG Images actually works in AROS 68k...

I thought for sure I would need to enable Serial Debug in WinUAE to do hours of troubleshooting.
Now I have to play with something else.  8)
Title: Re: New Picture Datatypes
Post by: miker1264 on April 20, 2021, 05:25:03 AM
Here is the New Jpeg Datatype compiled for x86_64 & AROS 68k...

The 64bit folder contains the source code as well if you're curious about how it is done!

Same for S-MulitView & New Picture Datatype. The source code is included.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 20, 2021, 09:40:18 AM
Here is S-MultiView compiled for X86_64 as well as 68k.
Thanks miker Datatypes and S-MultiView work fine on my AROS One 68k, only one small problem, S-MultiView does not allow to resize the window, the old Multiview has this function !
Title: Re: New Picture Datatypes
Post by: OlafS3 on April 20, 2021, 10:40:40 AM
This isn't really a datatype, but it is datatype related.

A newer version of MultiView can Save As IFF and Save As PNG.

Thanks... I will test it too
Title: Re: New Picture Datatypes
Post by: miker1264 on April 20, 2021, 04:44:59 PM
OlafS3 and AMIGASYSTEM

Thank you both for your enthusiasm and for feedback.

Yes. S-MultiView (Super-MultiView) is experimental. Window resizing was disabled a while ago for testing. That will be fixed.

Please test Save As IFF for 8bitplanes and below and for saving 24bitplanes. Please also test Save As PNG.

For testing the updated Jpeg Datatype with Load 8bit Black and White Jpeg my sample image is too large to post here. So simply go to any online comic strip such as AlphaLuna and download a sample 8bit Jpeg to test. Or use Photoshop to save an 8bit Jpeg.GIMP and IrfanView are also conversion options.

Hmmm...
Why can't AROS JPEG Datatype Load AND Save 8bit Black and White Jpeg Images ? As long as the input is a 8bit B&W image.
That shouldn't be too difficult to achieve. Maybe I'll work on that.Then something like Lunapaint can save as 8bit Jpeg too!

Thank you for the positive feedback.
Title: Re: New Picture Datatypes
Post by: OlafS3 on April 20, 2021, 10:41:09 PM
I have converted a jpg to 8bit and sucessfully saved it as iff and png

24bit also works

great job  ;)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 20, 2021, 11:10:14 PM
Uploaded 8Bit JPG image and saved as IFF and PNG
Title: Re: New Picture Datatypes
Post by: miker1264 on April 20, 2021, 11:48:35 PM
OlafS3 and AMIGASYSTEM

Thank you very much for testing.

I'll upload a new S-MultiView after I clean up the code a bit and re-enable window resize. The only change from previous MultiView will be that Save As IFF works with the new Picture Datatype and Save As PNG was added.

The x86 version of the newer Picture Datatype is included in the ISO that deadwood released. AMIGASYSTEM you may include that in your distro if you'd like. You also have the 68k version.

After I add an updated save function for JPEG Datatype I'll upload that one as well for testing for Load & Save 8bit Jpeg.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 21, 2021, 02:47:40 AM
Thank you miker, AROS One x86 and AROS One 68k will be updated as soon as possible with the deadwood ISO and software updates released on archives.aros.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 23, 2021, 10:49:50 AM
Sorry miker, i don't want to miss something, but are your S-Multiview and your new datatypes also available for x86 ABIv0 ?
Title: Re: New Picture Datatypes
Post by: miker1264 on April 23, 2021, 01:34:54 PM
They will be available soon.  :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 23, 2021, 03:10:50 PM
Thanks miker, the new AROS One v1.6 with deadwood updates, will be in download as soon as your updates are available :)
Title: Re: New Picture Datatypes
Post by: miker1264 on April 27, 2021, 06:48:47 PM
AMIGASYSTEM

And anyone else interested, I plan to update the JPEG Datatype and it should be available in about a week from this Friday.

In the course of doing some research regarding color quantizing I discovered that JPEG Library does its own internal quantizing.

While I'm working on save 8bit for jpeg datatype I will experiment with a modified test version to use jpeg library to quantize and save 24bit jpeg as 8bit bmp or gif. The small utility called djpeg can successfully do that. If the experiment works then AROS maybe can use jpeg library for quantizing images!

What a crazy idea! But it might work. And image quality is good.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 27, 2021, 07:36:34 PM
Thanks i will be happy to install it on my distribution !
Title: Re: New Picture Datatypes
Post by: miker1264 on April 27, 2021, 09:30:09 PM
Here is sample jpeg image.
Title: Re: New Picture Datatypes
Post by: miker1264 on April 27, 2021, 09:32:58 PM
The utility called "djpeg" from Jpeg Library was used to quantize the Jpeg image and save it as 8bit Bmp. I had to zip the image because of file size for posting.

You can see that the 8bit image is very similar to the original.  :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on April 27, 2021, 10:42:42 PM
I'm not an expert in this but I find the image of very good quality despite being 256 colors.

On OS3.9 BB4 "Standard" your image is not supported, probably due to datatypes

On my AfA One (OS 3.9 BB4 + AfA OS) instead you can see very well with Multiview also the "Miniature" created by "Eastern" and well managed
Title: Re: New Picture Datatypes
Post by: miker1264 on April 28, 2021, 05:20:40 AM
Actually, it wasn't difficult to modify JPEG Datatype to Save 8bit B&W images. It only took a few hours.  :)

Here is the 64bit version and the source code.

I will compile and test the 68k version tomorrow then upload it as well for testing.
Title: Re: New Picture Datatypes
Post by: miker1264 on May 11, 2021, 06:03:55 PM
I've been a little busy in the past couple of weeks building a new computer and rebuilding a couple laptops. Whew!  :)

More AROS work coming soon.
Title: Re: New Picture Datatypes
Post by: miker1264 on May 13, 2021, 05:49:11 AM
Testing the 32bit version of the updated Jpeg Datatype on x86-64...
Title: Re: New Picture Datatypes
Post by: miker1264 on May 13, 2021, 07:24:59 AM
Here is the results of compiling the "official" Linux x86_64 jpeg datatype...

Other than the increased version number 41.2 there is no difference. That means it compiled correctly.  :)
Title: Re: New Picture Datatypes
Post by: salvo on May 13, 2021, 03:26:39 PM
thanks miker :)
Title: Re: New Picture Datatypes
Post by: miker1264 on May 14, 2021, 09:10:01 PM
I'm finishing up modifications to Jpeg Datatype.

Started adding LoadTarga & SaveTarga for new Targa Datatype.

My SaveTarga function already works for 24bit images. So I will expand on that to add more bitdepths. Working on LoadTarga.

After completing Targa Datatype I'll take on the task of writing a new PCX Datatype. The PCX RLE (runlength encoding) is a bit tricky to implement. But again SavePCX is already working in one of my test programs. So I'll expand on that as well.

I still have to add Load/Save 8bit images to Tiff Datatype. Ultimately for Tiff Datatype I'd like to convert it to use an internal decoder to remove dependency on libtiff, reading/writing tiff.

Ultimately I plan to update the SaveILBM function in ILBM Datatype based on my recent work on DT_Write in Picture Datatype. Did I miss anything??

Much work to do.  ;)
Title: Re: New Picture Datatypes
Post by: salvo on May 15, 2021, 04:13:20 AM
 :D
Title: Re: New Picture Datatypes
Post by: miker1264 on May 19, 2021, 11:56:50 PM
I've been working on my new Targa Datatype over the last few days. It's coming together nicely.

The updated Jpeg Datatype Save function is ready to upload. That one will be available soon.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on May 20, 2021, 08:08:59 AM
Thank you
Title: Re: New Picture Datatypes
Post by: miker1264 on May 27, 2021, 08:41:58 PM
The new Targa Datatype is almost ready.

It can load and save 8bit, 24bit & 32bit targa images.

I'm working on functions for loading & saving 16bit targa.

Title: Re: New Picture Datatypes
Post by: miker1264 on May 28, 2021, 07:20:39 PM
While trying to write code to support loading 16bit files for targa datatype I realized two things. First, I've never tried working with 16bit so I know very little other than bit shifting is required. And second, I didn't have any valid 16bit targa image data for testing.

I discovered that there are two basic types of 16bit rgb data. There is rgb555 and rgb565 respectively. Apparently targa uses the rgb555 variety where red, green and blue are each 5bits. The remaining 1 bit can be discarded during decoding.

So I had the basic method but no sample data. Then I realized two things. Windows bitmap images can be 16bit and our bmp datatype can decode 16bit data. However, bmp is supposed to use rgb565.

But I had a graphics utility that could import and export a few image types but it provided bitdepth and conversion options. For exporting 24bit bmp it provided 3 options: rgb555 or rgb565 or 24bit. So I chose to export the 16bit bmp as rgb555 to match the supposed targa format.

When importing 24bit then exporting targa no options were provided. It simply saved 24bit targa. But when I imported the 16bit bmp I just converted then tried to export as targa it gave the same three options as for bmp. So I chose rgb555 to be consistent.

So here's the interesting part if you enjoy this type of thing. Using my favorite hex editor I compared the two files. The 16bit pixel data was identical. So now I could make 16bit test files.

Microsoft provided some code for converting 16bit to 24bit rgb. Now the rest is just writing the 16bit conversion code then inserting it into the datatype and testing it. Fun stuff.  ;)

BTW it seems PaintDotNet can't display 8bit and 16bit targa images correctly. It forgets to swap the red and blue pixel elements per scanline for 16bit to make BGR into RGB. For 8bit it also fails to swap red and blue for colormap values with the same result. The images appear blue or oddly colored. But GIMP displays 8bit and 16bit targa images just fine. And soon our MultiView will display them as well using the targa datatype.
Title: Re: New Picture Datatypes
Post by: miker1264 on May 28, 2021, 08:38:01 PM
Here's something else that is interesting if you're into c programming, although it's a little geeky!

As noticed with PaintDotNet even for 16bit pixel data we must remember to swap red and blue pixel elements for targa and bmp formats or the colors will be wrong when they are displayed.

Microsoft provided direct conversion code to convert 16bit pixels to 24bit pixels. It uses WORD masking and a WORD pixel. But first the data must be in a WORD array.

According to my research in order to convert 2 bytes to WORD we do this:

short val = ((left_byte & 0xff) << 8 ) l (right_byte & 0xff);

But the code in the AROS bmp datatype to convert 16bit to 24bit is slightly different.

It starts with:
WORD pixel;
pixel = *(buf1)++;
pixel l= (*(buf1)++) << 8;

So it is using WORD = right_byte l left_byte;

It swaps the bytes while bit shifting. So that when converted from 16bit to 24bit instead of a direct conversion to BGR it becomes RGB.

Even for 16bit data you swap the bytes before or after conversion but don't forget to make BGR into RGB.

The bit shifting and swapping method seems more elegant. But this is all theory till I actually test it.  ;)
Title: Re: New Picture Datatypes
Post by: salvo on May 29, 2021, 01:10:33 PM
thank you miker for your effort :)
Title: Re: New Picture Datatypes
Post by: miker1264 on May 29, 2021, 10:24:46 PM
Hmm...

Loading 16bit Targa Image...almost.

Someone forgot to flip the scanlines!  :)

Oooops!!!
Title: Re: New Picture Datatypes
Post by: miker1264 on May 29, 2021, 10:58:03 PM
Ah...much better.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on May 30, 2021, 12:27:32 AM
Ah...much better.

Thank goodness, you saved the wine  :D
Title: Re: New Picture Datatypes
Post by: miker1264 on May 30, 2021, 03:50:06 AM
Simple physics!

When the glass is upside down, acceleration due to gravity, the wine falls out.

But the wine is safe now!  :D


Targa on the left, Bmp on the right.
Next I should focus on "saving" 16bit Targa.

Here is the gist of converting a 16bit scanline to 24bit.
Note: It took three days of research and experimentation to get this far...


for(x = 0; x < bmh->bmh_Width; x++)      
{
    /* Expand 16bit pixels to 24bit pixels */
   red = ((buf1[(x*2)+1] << 1) & 0xf8);
   red += red >> 5;
   green = ((buf1[x*2] & 0xe0) >> 2) | ((buf1[(x*2)+1] & 0x03) << 6);
   green += green >> 5;
    blue = ((buf1[x*2] << 3) & 0xf8);
   blue += blue >> 5;
   
    buf2[x*3] = red; buf2[(x*3)+1] = green; buf2[(x*3)+2] = blue;
}
Title: Re: New Picture Datatypes
Post by: miker1264 on June 02, 2021, 01:03:52 AM
Small update for datatypes.

A while ago I started writing save functions for Targa and PCX datatypes. Seems odd to start at the end and work forward. Sometimes I read novels like that.  :)

Recently I've been writing an entirely new Targa Datatype complete with Load and Save functions for 8bit, 16bit, 24bit and 32bit images. It's almost finished. I'm just finishing up 16bit.

I've started writing a new PCX Datatype as well that will support Loading and Saving 8bit and 24bit with PCX RLE compression. It will be couple weeks till it is finished. RLE compression is tricky to implement for PCX. So I have to be very cautious about it.

I recently wrote a new TIFF Datatype that actually works using LibTiff. But so far it only supports Loading and Saving 24bit. I'd like to write an internal decoder for Tiff images to remove dependency on LibTiff. That will require a major re-write and the LZW codec will be needed. It is also used in GIF datatype.

I finished the revisions for Jpeg datatype to support loading and saving 8bit bw images. But I haven't uploaded it yet.  :D

So, we should have three new dataypes soon to play with.
Title: Re: New Picture Datatypes
Post by: salvo on June 02, 2021, 09:57:01 PM
thank you miker :)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 04, 2021, 12:10:51 AM
Hmm...

WriteScanlineRLE for Targa Datatype is a bit challenging.

But I suppose that's what makes all of this so interesting.

Luckily I already have ReadScanlineRLE & WriteScanlineRLE for the PCX Datatype. Writing the rest should be relatively easy! 😊
Title: Re: New Picture Datatypes
Post by: miker1264 on June 05, 2021, 05:52:06 AM
I was working on the Targa Datatype, more specifically the WriteRGB16 function that saves 16bit images.

As you can see it's kinda working! Oooops! Probably a wrong conversion formula.  8)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 05, 2021, 03:53:09 PM
Verify well, try a Targa image saved by another program, I noticed that some programs save a non-standard format.
Title: Re: New Picture Datatypes
Post by: miker1264 on June 05, 2021, 05:56:26 PM
Verify well, try a Targa image saved by another program, I noticed that some programs save a non-standard format.

I have several test images that I've created from a 24bit BMP using PixelFormer in Windows and ImageMagick in Linux to create 16bit BMP and TGA files in rgb555 format. GIMP is also good for creating and viewing Targa images. But PaintDotNet is nearly useless for Targa. It forgets to swap bgr to rgb pixels.

I saw a documentary recently about code breakers in WWII, although I'm not that old.  ;)

Secret messages were being intercepted that had to be decoded. The encoded messages were generated by the Enigma Machine which was a box that consisted of 12 cylinders that could be arranged for encoding messages. It was the job of some highly skilled mathematicians to use the messages to work out the internal arrangements of the Enigma Machine.

I'm trying to break the code to come up with a formula involving bitwise operations such as bit masking and bit shifting to convert 3 bytes of 24bit rgb888 into 2 bytes of 16bit rgb555.

The scattered image you see is because my formula for conversion is only half correct. For the 2 byte values for 16bit the first byte is almost correct but my formula isn't including the 5bits from the blue element. So for example what should be 0xE3 0x3C becomes 0xE0 0x3C. All the second bytes are good.

Hehehe! I'm using an online Hex to Binary converter and online Bit Shift calculator and my favorite Hex Editor. I'm converting three bytes to binary then writing it out to get the formula. Once I get the correct formula to convert 24bit to 16bit pixels I can use it for any dataype that supports 16bit images. After Targa Datatype I may have to revise BMP Datatype to save 16bit also.

Happy Decoding! (But in this case Encoding).  8)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 05, 2021, 07:53:09 PM
@AMIGASYSTEM

I know you are fond of blue. I have a blue problem...

I believe I found the problem with my formula. It seems to be a transliteration problem due to user error!  8) 8) 8)
Isn't it always user error!?  :D

            BYTE red, green, blue;

            /* Collect 24bit pixel elements */
            red = (buf2[x*3]);
            green = (buf2[(x*3)+1]);
            blue = (buf2[(x*3)+2]);

Everything looks good so far...but then what should be '11100011' is instead '11100000' because it isn't picking up 5bits of blue. But Why??

            linebuf[x*2] = ((green & 0xF8) << 2) | ((b & 0xF8) >> 3); // Take remaining 3 Bits of G component and 5 bits of Blue component E3 rgb555
            linebuf[(x*2)+1] = ((red & 0xF8) >> 1) | (green >> 6); // Take 5 bits of Red component and 2 bits of G component 3C rgb555

See this part: | ((b & 0xF8) >> 3); That is probably because I inadvertently used 'b' instead of 'blue'.
So the right side of the first conversion should be: | ((blue & 0xF8) >> 3); or just (blue >> 3);

Title: Re: New Picture Datatypes
Post by: miker1264 on June 07, 2021, 02:14:01 AM
Kitty looks pretty in pink!

But that also indicates a slight problem with my 24bit to 16bit conversion code.
Light blue gets washed out and there is too much red tint.

Notice the wine and bread image on top which is the original, if you look at the wine bottle label on bottom...
it is losing blue and gaining red.
Title: Re: New Picture Datatypes
Post by: miker1264 on June 07, 2021, 03:47:14 AM
After three days of experimentation & testing I have a working WriteRGB16 code that converts
24bit rgb888 to 16bit rgb555 or '5 bits per pixel". Orininal 24bit on left, new 16bit on the right.
There is only a slight perceived difference between them. The original is slightly darker overall.
I could use post processing to darken each pixel or simply leave it the way it is. It's working!

I had to tweak the conversion formula several times in different masking configurations to get
the correct color fidelity. It seems that different bit masking yields different results. So there is
still room to tweak it a little more if needed. Here's the working code if anyone is interested...

Only the working code is good. Everything behind '//' slashes is just old experimental code.



           /* Collect 24bit pixel elements */
            red = (buf2[x*3]);
            green = (buf2[(x*3)+1]);
            blue = (buf2[(x*3)+2]);

         //linebuf[x*2] = ((green & 0xF8) << 2) | ((blue & 0xF8) >> 3); //Causes light blue -> pink.
         //linebuf[(x*2)+1] = ((red & 0xF8) >> 1) | (green >> 6);

            //Working code. Good quality images. Blues still not dark enough.
         linebuf[x*2] = ((green & 0xF8) << 2) | ((blue & 0xF8) >> 3); // Take remaining 3 Bits of G component and 5 bits of Blue component E3 rgb555
            linebuf[(x*2)+1] = ((red & 0xF8) >> 1) | ((green & 0xC0) >> 6); // Take 5 bits of Red component and 2 bits of G component 3C rgb555

         //linebuf[x*2] = ((green & 0x38) << 2) | (blue >> 3);
         //linebuf[(x*2)+1] = ((red & 0xF8) >> 1) | ((green & 0xC0) >> 6);

            //rgb555 = (((blue) >> 3) | (((green) >> 3) << 5) | (((red) >> 3) << 10)); //Blue Washout.
         //linebuf[x*2] = (rgb555 & 0xFF);
         //linebuf[(x*2)+1] = (rgb555 >> 8) & 0xFF;
Title: Re: New Picture Datatypes
Post by: salvo on June 07, 2021, 02:10:06 PM
very impressive miker 8)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 07, 2021, 03:44:18 PM
very impressive miker 8)

salvo

I'm very impressed with the quality of the output 16bit image.

I will have to compare the same input and output images in other graphics programs that deal with 16bit images such as GIMP and ImageMagick in Ubuntu and Pixelformer in Windows.
Title: Re: New Picture Datatypes
Post by: salvo on June 08, 2021, 12:09:48 AM
i understand miker
Title: Re: New Picture Datatypes
Post by: miker1264 on June 08, 2021, 09:03:07 PM
After two weeks of intense effort here is the completed Targa Datatype. It is currently compiled as x86-64.
But the x86 and 68k versions will follow soon.

Reading and writing 16bit images was tricky at first. But it works reaaly well now! Next on my list is a new PCX Datatype.

I have to hurry to produce new dataypes before @paolone releases a new version of IcarosDesktop! Wow! He is fast.  :D

It can read RLE Compressed Images, 8bit, 16bit, 24bit, 32bit. It can save 8bit, 16bit, 24bit, 32bit targa images.
Title: Re: New Picture Datatypes
Post by: paolone on June 09, 2021, 04:30:57 PM


I have to hurry to produce new dataypes before @paolone releases a new version of IcarosDesktop! Wow! He is fast.  :D


well, not so fast, lately. :-)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 09, 2021, 08:07:08 PM
Proposed new AROS Picture Datatypes.

Mng, Jng, Pict, Dcx, Pcx, Tga, Tiff, Heic

I'm working on Pcx, Tga and Tiff. Others to follow.  :D

Modifications:

Added Load/Save 8bit to Jpeg Datatype.

Need to add WriteRGB16 for BMP Datatype to save 16bit.

I'd like to add SaveHamPic to ILBM Datatype to save Ham.
Title: Re: New Picture Datatypes
Post by: salvo on June 09, 2021, 08:09:15 PM
great miker :)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 09, 2021, 11:14:20 PM
Hmmm...

We have an HEIC Datatype Descriptor but no datatype.

Unless someone beats me to it maybe I'll write one.  8)

It's also not fair that Amiga OS has a JNG datatype & we don't.

I should write that one also. Unless someone else does.

Anyone...??
Title: Re: New Picture Datatypes
Post by: miker1264 on June 10, 2021, 04:00:21 AM
Here you will find a zip archive with the compiled versions of Targa Datatype & DT Descriptor for x86, x86_64, & 68k.

The source code will follow after a little cleanup & addition of some meaningful comments.

It can load 8bit, 16bit, 24bit, & 32bit Targa Images. They can be Uncompressed or RLE Compressed.
It can save Uncompressed 8bit, 16bit, 24bit, & 32bit Targa Images.

( I haven't written WriteScanlineRLE yet but I will need it for TIFF Datatype ).

If anyone would like to test the new datatype on x86 & 68k you can make Targa Images for testing with GIMP, ImageMagick
or Photoshop, among other graphics programs. There are probably many more that can Load & Save Targa Files.
Title: Re: New Picture Datatypes
Post by: salvo on June 10, 2021, 12:51:00 PM
thank you miker :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 11, 2021, 03:37:40 PM
miker is there any way to convert an OS3 datatypes for AROS x86?

It would be very useful to port the midi.datatypes to AROS, on OS3 it works fine, midi.datatypes allows the MultiView to play Midi format music.

Unfortunately on AROS x86 "Wanderer" there are no Players to play Midi files except, "wildmidi" which is a DOS Player, on AROS it is not possible to associate a Payer on Icon, on OS3 instead the Dos commands can be associated on Icon.

Did my Dopus4 config work? Dopus4 on AROS x86 has a lot of limitations compared to the OS3 version where thanks to XAD you can open archives as folders, you can click on files without extension, on AROS x86 you can't do that because all files are seen as if they were executable !!!
Title: Re: New Picture Datatypes
Post by: miker1264 on June 11, 2021, 06:01:25 PM
AMIGASYSTEM

I haven't tried the Dopus4 config yet. Certainly Dopus4 could benefit from a few improvements for AROS x86 & x86-64.  ;)

As far as using OS3 datatypes they would need to be re-written for AROS. That's not so much a problem if the sources are available. Are there any source files for midi datatype?

In the AROS Contrib Repository I found "CAMD Toolkit" with a midi music player based on camd.library so now we have to verify if we have the library, shared library or link library.

After doing some searching I found that we do indeed have a camd shared library in our sources. So getting PlayMF to work for Midi music is quite possible.

I eventually have to look into learning about AHI sound so I suppose investigating Midi music is along the same path.  :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 11, 2021, 06:22:30 PM
Yes there are sources you can find them on MidiDT, there is also a recent program of preferences made by another author but without sources I attach links:

http://aminet.net/package/util/dtype/MidiDT

http://aminet.net/package/util/dtype/MidiDTPrefs
Title: Re: New Picture Datatypes
Post by: miker1264 on June 11, 2021, 06:39:45 PM
Yes. I found the midi datatype. Interesting that is based in part on Camd Toolkit & PlayMF.

It certainly looks like an interesting project. I have been thinking about branching off from picture datatypes to binary, text & sound classes. Just to keep the momentum going.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 11, 2021, 07:19:05 PM
Yes I think it's an important project that enriches AROS, I'm ready to test it on AROS One, the next release will have many news based on datatypes, now Wanderer supports all Audio, video and Graphic formats.

Today I've added 2 more archive formats LZH and TGZ, for the Video now are recognized MP4 files, the Audio formats will be completed with Mid, Midi and KAR extension files, even if Karaoke I don't think is supported, but I think they will work as sound.
Title: Re: New Picture Datatypes
Post by: miker1264 on June 11, 2021, 07:52:52 PM
AMIGASYSTEM

Since you are working with datatype descriptors when you have finished compiling them for x86 maybe you could post them as a zip file so we can use them for IcarosDesktop x86 ?

If you also include the binaries and the .dtd text files we can compile them for IcarosDesktop x86-64.

I know it involves effort but what you do will be greatly appreciated.

I'm sure @paolone would ask if he could include them with Icaros.  :)

Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 11, 2021, 08:56:56 PM
No problem my work even if not professional is for everyone, AROS One x86/68k is for everyone and no permission is required to use its parts, in fact I'm happy that someone would use them, AROS is a free system and all its users.

I will also add an archive with my def_icons, then everyone can change them to their liking.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 12, 2021, 10:25:30 AM
Finished also the Graphic Descriptors, now each phrasal format has its own Icon.

There are only 2 problems.

- TIF/TIFF Descriptor can't work because Tif.datatypes doesn't exist.

- IFF/ILBM (image created by Windows with XnView) Descriptor doesn't work with Multiview, but works fine with PicShow (not datatype fault).

With native Amiga IFF/ILBM images no problem for Multiview
Title: Re: New Picture Datatypes
Post by: miker1264 on June 13, 2021, 05:33:52 PM
Small update.

I've started writing the internal decoder for TIFF Datatype to read & decode tiff images which removes the dependency on LibTIFF.

The source code for Targa Datatype is almost ready to upload. But I suspect a few updates to BMP Datatype will be done first.

Also, I've started writing PCX Datatype but still much work to do.
Title: Re: New Picture Datatypes
Post by: salvo on June 13, 2021, 09:17:33 PM
great miker thank you :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 13, 2021, 09:18:41 PM
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
Title: Re: New Picture Datatypes
Post by: miker1264 on June 13, 2021, 10:06:35 PM
I'm sure x86 was set up to use def_Picture.info.

But you can certainly customize it how you'd like.  :)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 13, 2021, 11:04:36 PM
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.
Title: Re: New Picture Datatypes
Post by: miker1264 on June 15, 2021, 01:49:51 AM
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!
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 15, 2021, 09:06:20 AM
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:
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 15, 2021, 12:00:50 PM
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.
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 17, 2021, 11:06:28 PM
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 ;D

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

Title: Re: New Picture Datatypes
Post by: miker1264 on June 19, 2021, 12:55:52 AM
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.  8)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 19, 2021, 08:28:20 AM
Saving my first 8bit PCX image with my new RLE Compression Algorithm.

It may be small but it's very significant.  8)
Title: Re: New Picture Datatypes
Post by: salvo on June 19, 2021, 12:07:16 PM
great miker  :)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 20, 2021, 02:59:28 AM
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.  8)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 20, 2021, 09:25:30 AM
Ah! Success at last.

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

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!  8)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 20, 2021, 10:27:52 AM
In the end you always find the right way when you have a lot of will and passion !
Title: Re: New Picture Datatypes
Post by: miker1264 on June 20, 2021, 07:24:41 PM
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.  :)
Title: Re: New Picture Datatypes
Post by: salvo on June 20, 2021, 08:01:15 PM
Miker When will it be always possible if you want to do Raystorm's porting? :-\
Title: Re: New Picture Datatypes
Post by: miker1264 on June 20, 2021, 09:33:25 PM
Miker When will it be always possible if you want to do Raystorm's porting? :-\

After I finish this set of updates for picture datatypes then I will have some time to work with RayStorm again. Maybe two weeks from now I will be able to start on it again.

Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 20, 2021, 10:12:15 PM
Yes I think it's very important to have all the Datatypes that are very important and not only the graphic ones but also other file types.

I'm in contact with my friend PeterK to get an Icon.library for AROS 68k that supports Datatypes.

At the moment on AROS 68k I use his icon.library but through the OS3 Deficons Tool that I would like to eliminate because it doesn't belong to the AROS world.

The native AROS 68k icon.library works fine with my Descriptors but does not support icons DualPNG, OS4 and many other icons.

If Peter will create this new icon also OS3.0 and 3.1 will be able to recognize the files, these OS don't have the Tool Deficons

I attach link of my discussion with the good Peter:

http://eab.abime.net/showthread.php?t=64079&page=185&highlight=iconedit

Title: Re: New Picture Datatypes
Post by: salvo on June 21, 2021, 12:32:32 PM
Miker you will make a good part of the Aros community, a program for a long time like Raystorm, I thank you Meanwhile I proceed with my humble collaboration projects :)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 22, 2021, 05:36:19 PM
Miker you will make a good part of the Aros community, a program for a long time like Raystorm, I thank you Meanwhile I proceed with my humble collaboration projects :)

Thank you for your support.

As I finish up modifications to TGA, PCX and BMP Datatypes I'm doing a study of compression schemes used in datatypes.  :)

These include ByteRun, RLE, LZW, Huffman and CCIT. I just finished writing a version of PCX RLE encoding that is currently working to compress scanlines for PCX Datatype. The datatype can save 8bit and 24bit PCX files. RLE isn't required for TGA but I'd like to experiment with WriteRLE for Targa Datatype as well.

Of course, in time, I will need working versions of RLE and LZW compression for use with TIFF Datatype. The first version of the datatype will use LibTiff. The updated version will have an internal decoder for loading and saving. Multi-Image Tiff Files.
Title: Re: New Picture Datatypes
Post by: salvo on June 22, 2021, 07:08:06 PM
Great Miker very well ;)
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 24, 2021, 10:18:14 AM

Of course, in time, I will need working versions of RLE and LZW compression for use with TIFF Datatype. The first version of the datatype will use LibTiff. The updated version will have an internal decoder for loading and saving. Multi-Image Tiff Files.

Yes they are fundamental things for an operating system, as are Driver Audio, Video and WiFi , the lack of these things leads to the abandonment of AROS by all those users who want to try AROS.

In my opinion we should focus on this and leave duplicate programs, porting or little used software.
Title: Re: New Picture Datatypes
Post by: miker1264 on June 24, 2021, 09:01:45 PM
By focusing my attention on updating datatypes and even MultiView I feel that my changes will benefit a greater number of people rather than just minor fixes here and there?
Title: Re: New Picture Datatypes
Post by: AMIGASYSTEM on June 24, 2021, 09:58:48 PM
Yes they will be a benefit this is for sure, thanks miker
Title: Re: New Picture Datatypes
Post by: salvo on June 25, 2021, 12:14:39 PM
By focusing my attention on updating datatypes and even MultiView I feel that my changes will benefit a greater number of people rather than just minor fixes here and there?

Certainly Miker
Title: Re: New Picture Datatypes
Post by: salvo on June 25, 2021, 01:48:35 PM
Miker also benefits the software on Aros, I think Raystorm's porting will be greatly appreciated :D
Title: Re: New Picture Datatypes
Post by: miker1264 on June 26, 2021, 08:21:21 AM
Yay!  :)

After five long days of intense research and experimentation I have written a working RLE Compression Algorithm for Targa Datatype. RLE Compression also works for PCX Datatype.

The Targa RLE Compression code can be re-used for Tiff Datatype along with LZW Compression when I get to it.  8)
Title: Re: New Picture Datatypes
Post by: miker1264 on June 26, 2021, 08:22:57 AM
Here is the code for Targa RLE Compression.
Title: Re: New Picture Datatypes
Post by: salvo on June 26, 2021, 07:13:21 PM
good miker :)
Title: Re: New Picture Datatypes
Post by: serk118uk on June 27, 2021, 02:01:36 PM
I am actualy working on a new native meteDiskRecovery Program and TIFF.Datatype was missing so thanks ,
Title: Re: New Picture Datatypes
Post by: miker1264 on June 27, 2021, 02:57:10 PM
I am actualy working on a new native meteDiskRecovery Program and TIFF.Datatype was missing so thanks ,

I've written a working TIFF Datatype based on LibTiff. I've compiled the Link Library for x86-64.

If we can compile LibTiff for x86 then it may work till the new version is available with intetnal tiff decoder.