I am planning to do some stuff using PNG Files.
Whats the easiest and fastest way to handle them?
Its for a non-commercial Freewareproject.
Has anybody Tipps on how to go?
FreeImage is a good start.
http://freeimage.sourceforge.net
And without external Components?
Lets see ...
Quote from: Theo Gottwald on July 31, 2013, 08:23:11 PM
And without external Components?
Lets see ...
If you don't want to use a DLL, then you could always find a language that has decent image handling built in. However, some of the languages that have decent image handling built in are using FreeImage internally. FreeImage is
almost an industry standard.
Hi Theo,
GDIplus will do the job, if you don't want to use FreeImage, (which is a 2.5 meg dll).
I would not describe it as easy to use, but then graphics is always challenging.
GDIplus uses GUIDs to select CODECs for saving jpeg, png,tiff,gif images, but these types are automatically recognised when loading.
Perhaps Patrice can recommend a higher level layer in Windows.
Patrice posted already plainty of examples, but Theo qualified them of Deluxe solution :)
Which is the maximum resolution that can be handled, using the DeLuxe Sollution, Patrice?
Using PB 32-bit?
Actually, as i need to handle VERY LARGE PNG's (smallest 17000*10000) and possibly multiple of these,
i just thought that 32 bit is eventually not a good choice in this case.
What do you think?
Just seen that PureBasic has PNG Support since 2010.
Enumeration
#Image
#ClipImage
EndEnumeration
UsePNGImageDecoder()
UsePNGImageEncoder()
If LoadImage(#Image, FileName$) ; 512x512
If GrabImage(#Image, #ClipImage, 0, 0, 256, 256)
SaveImage(#ClipImage, ClipFileName$, #PB_ImagePlugin_PNG) ; 256x256
EndIf
EndIf
As this looks like a small project, this would be one way to go.
Is it a builtin "Freeimage" version?
I have attached 4 PNG Files as example. Imagine they would not have this small size of 640x400 but a huge size of up to 300 MP. And imagine it will not be just 4 parts but several parts, possibly ... 100 parts.
They will need to be concatenated to a single picture as efficient as possible.
They are rendered using POV-Ray 3.7 beta (http://www.povray.org/) as Partial Renders.
Imagine they are rendered on several computers, then collected and should finally be concatenated to the ready-image.
I've done this in the past for BMP-files in PowerBasic, but as it had to use the Harddisk heavily,
this was not really that much efficient for very large files.
Now i am designing a sollution to concat PNG Files.
@Charles, could the 64 bit version of OB be used for this? Maybe we can do it together?
Quote from: Theo Gottwald
Just seen that PureBasic has PNG Support since 2010.
I
think it has been there longer than 2010.
Quote from: Theo GottwaldIs it a builtin "Freeimage" version?
AFAIK, no.
I have asked Fred, the creator of PureBasic, he said
QuoteHi Theo,
PB uses DIB internally, so you are limited to DIB limit (2GB even on 64bit machine).
Yet after looking closer at Purebasic, aside from this limitation, it has the best support for graphics..
Quote from: Theo Gottwald on August 02, 2013, 09:15:19 AM
Yet after looking closer at Purebasic, aside from this limitation, it has the best support for graphics..
It is the most well-rounded BASIC out there and what I generally recommend to most people when they are looking for a BASIC.
GDImage, since version 1.0, is using DIB thus it can handle large picture.
But to say the truth, i realy can not understand the purpose of dealing with such large large image.
A size of 17000 x 10000 just doesn't make sence to me, at least on a PC.
...
In the consumer market its of no use, Patrice.
But thats just the place where all people are, even with freeware programs.
There are bussiness markets out there, that need larger resolutions, for Posters, or architects.
Photoshop since version 13.1 has a limit of 64kx64k.
Another example:
Cinema 4D has a Render-Resolution limit of 128kx128k.
Even POV-Ray can render nearly as large images as it can hold in memory.
I have rendered 16000x12000 with no problems (64 bit).
This is for special needs.