PureBasic Forums - English

Thorium wrote: The project is not dead it's just delayed, i promise.

Just to let you guys know: I am back on the project.

I think it takes 2 weeks to get the new version ready for release.

Goodie!

Hey Thorium,

I was just interested in this thread and in you great lib. Sounds great.
Well, to let the cat out of the bag: I've never used your lib yet. But I would like to, if you consider fusioning your lib with the native PB commands. For example, that yu can use the native LoadImage() or CatchImage() commands, supporting the native and your format.
Then I could install it as a lib and use the known, familiar commands for a better convenience.

AND51 wrote:Hey Thorium,

I was just interested in this thread and in you great lib. Sounds great.
Well, to let the cat out of the bag: I've never used your lib yet. But I would like to, if you consider fusioning your lib with the native PB commands. For example, that yu can use the native LoadImage() or CatchImage() commands, supporting the native and your format.
Then I could install it as a lib and use the known, familiar commands for a better convenience.

Hey AND51,
it isn't a lib.
It's a include including the complete source code for decoding and encoding.
To get TSI into the native PB functions it need to be a image plugin. But i don't wanted to make it as a PB plugin for more than one reason. First i think the plugin interface is not very good documented and i don't realy got how to make it as a plugin. Second having it as pure source code makes it possible to be as much cross platform as possible with PB, without the need for me to compile it for every platform. And users can do very easy changes to the source if needed and can use all it's internal procedures to be in 100% control of whats going on. They are all commented at least with text what they do and what they return.

But i guess it's possible to create a macro to merge the TSI-include procedures with the PB-native ones.

btw. crossplatform, the current version dont work on PPC because of the byte order and for Linux and MacOS X x86 the ZLib import is wrong. I allready fixed that issues in the new include i am currently working on. So it will be truly crossplatform (as far as it's possible with PB). And i hope some people will test it, especially on MacOS PPC, because i don't have a Mac. ^^

go on, very good work !

But no libs, don't do libs that will break someday in the future, keep it as an include please...

blueznl wrote:But no libs, don't do libs that will break someday in the future, keep it as an include please...

Don't worry. Even if i would make a lib of it (which i am not planning), there will be allways the include version available. I will definitely not close the source, there is nothing super secret about the source.

Very excellent! Do you plan to implement animated images with frame differential compression Thorium? If so, this would seriously 0wn!

PrincieD wrote:Very excellent! Do you plan to implement animated images with frame differential compression Thorium? If so, this would seriously 0wn!

Thorium wrote:

klaver wrote:Great work, Thorium.
It beats PNG (optimized) in size on all files I tried! And the speed - simply ownage!
Hope you will improve it even more (more pixel data formats).

PS Ever though about improving TSI even more (TSI2 or something) sometime in future by adding animation support?
Nowadays there's no modern image format supporting it (GIF is old shit). APNG is some alternative, but sadly it's not widely supported. TSI would be better as FASTER and possibly SMALLER.

Thanks
and yes it will be called TSA and will have a special compression that saves differences between the frames. A alpha version of a TSA encoder and decoder allready works but missing some important features. I want to concentrate on the more simple TSI first.

Thorium wrote:

klaver wrote:Great work, Thorium.
It beats PNG (optimized) in size on all files I tried! And the speed - simply ownage!
Hope you will improve it even more (more pixel data formats).

PS Ever though about improving TSI even more (TSI2 or something) sometime in future by adding animation support?
Nowadays there's no modern image format supporting it (GIF is old shit). APNG is some alternative, but sadly it's not widely supported. TSI would be better as FASTER and possibly SMALLER.

Thanks
and yes it will be called TSA and will have a special compression that saves differences between the frames. A alpha version of a TSA encoder and decoder allready works but missing some important features. I want to concentrate on the more simple TSI first.

Verrry nice! keep up the good work!

Hey,
project is still not dead, even if it looks like it. The problem is, i totaly underestimated how much work it is to include all the stuff i wanted, plus i have to work a lot at my job lately. So less time for coding.

But i am still working on it, slow, every day a bit. ^^

I will not post a release date anymore because i likely will not hold it anyway. So it's done when it's done.

Anyway i just wanted to let you know that the project is still alive, current status is:
-core decoder and encoder are complete
-facilitys for encoding PB images and decoding into PB images are complete
-replacement procedures for LoadImage, CatchImage and SaveImage are complete (for better integration in PB)

Still to do:
-facilitys for encoding PB sprites and decoding into PB sprites have to reworked to fit the new include structure
-replacement procedures for LoadSprite, CatchSprite, SaveSprite
-a ton of converting procedures have to be written to make all the different pixel formats and storing options interchangeable (thats what i have totaly underestimated ^^)
-viewer have to be reworked
-converter have to be reworked
-XnView plugin have to be reworked

To give you a impression why the converting procedures are a ton of work:
TSI2 supports 25 different pixel formats
every channel format supports 4 different channel orders
every pixel format supports Y-reversed storage of image data
every 16bit and 32bit channel format supports little endian and big endian byte order

That are exactly 112 ways image data can be stored in a TSI. Funny if you think about it, TSI 1 can just store image data in 1 way only.

Why TSI should support storing of image data in so many ways is simple. Best performance on every possible plattform if software or hardware. TSI 2 aims not to be a PB include only, my goal is to make it available to many plattforms like iPhone. And one big secret TSI gets is awesome performance from is that it skips a pricey decoding step necessary on most image formats: The pixel convertion. By storing the image data in the nativ way your target plattform uses it you dont need to convert the pixel format and load the decompressed image data strait into the graphics card or whereever it is needed.

Ah and one more thing i devided the 16bit pixel format into 3 different formats
-16bit 4444 (4bit red, 4bit green, 4bit blue, 4 bit alpha)
-16bit 5551 (5bit red, 5bit green, 5bit blue, 1 bit alpha)
-16bit 565 (5bit red, 6bit green, 5bit blue)

While these formats are pretty outdated for displaying they are usefull if you need smaler files.
With the new TSI include it will be no problem to save a TSI as 16bit 4444 from a 32bit image and later load it back to a 32bit image. Of course with a loss of colors but no need for a palette. However TSI 2 will also support indexed images with palettes.

Not to undermine your progress, but wouldn't it make sense to build a TSI 2.0 which would support only 1 or a few formats, allowing some acceptance in the wild, whilst giving you all the peace to go completely bananas over the rest?

blueznl wrote:Not to undermine your progress, but wouldn't it make sense to build a TSI 2.0 which would support only 1 or a few formats, allowing some acceptance in the wild, whilst giving you all the peace to go completely bananas over the rest?

Well there is still TSI 1 available and i see nobody using it. But i got a lot of requests to include more formats. So it's a big load of work but i think it's just needed. But i will release a version in which not all formats are interchangeable. For example you can't directly convert a 4bit indexed image into a 16bit image. You first need to convert the 4bit indexed into a 32bit or 24bit image. But it's needed that at least every format can be converted to 24 and 32 bit and vice versa.

Thorium wrote:Well there is still TSI 1 available and i see nobody using it.

I'm pretty sure it's being used (well I'm using it anyway), and thanks for the post. It's nice to see some details about the mountain of work needed for such features.

Thorium, the TSI format would probably rarely be used for format to format conversion, that takes away some of its essence, I guess most apps are more than happy to use a single format