PureBasic Forums - English

It would be useful to have a function: which returns a code corresponding to the Image Decoder used in LoadImage or CatchImage, or -1 if the image was created by CreateImage. The purpose of this is to enable SaveImage to be called with an encoder that matches the decoder if known. CopyImage and GrabImage could inherit the image format of the source image.

I do believe when you Load/CatchImage, the image format will be converted into a OS common format, so the only way to carry its original format 'index' would require the compiler to allocate more data to the PB instance of the image. This would affect all loaded images from the program amounting to more memory being used for a feature that will only be specifically used in such a way.

Strangely I thought exactly the same (even if we are talking about a byte).

Adding an optional param to load/catchimage to store the type would be nice but we already have a ghost param there, so the call would look weird.

Probably could be better a stand alone function like loadimage that instead of loading the image returns its actual type.

Or maybe an internal volatile var, overwritten every time you load/catch an image, to look upon just after the load.

LoadImage("foo.jpg")

Debug LastImageFormat() ; jpeg code

LoadImage("foo.png")

Debug LastImageFormat() ; png code


Not many chances

Env wrote:I do believe when you Load/CatchImage, the image format will be converted into a OS common format, so the only way to carry its original format 'index' would require the compiler to allocate more data to the PB instance of the image. This would affect all loaded images from the program amounting to more memory being used for a feature that will only be specifically used in such a way.

I wouldn't have thought that one byte extra per stored image, or at most one .i variable extra per stored image, was a big deal.

Shouldn't the app's author already know what filetype was loaded, and then just store it in a var themself?

Only by checking the file extension or something like that. My users can browse for any image of a format supported by the program (.bmp, .jpg, .png, .jp2, .jpx), then rotate the image and save the rotated image. I know I can use the file extension as my check - it's just that since PB has already determined which decoder to use it would be nice if I can find out which decoder was used. It seems cleaner than checking the file extension.

I really dont know how much this would help. It is easy to find out the image type by checking the file content anyway.

But how much is that of use with JPG or PNG files if you dont know if it is a b/w image, 2 bit, 16-bit, 24bit, 32bit with alpha informations, which compression level was used or if it isnt even compressed.

ozzie wrote: I wouldn't have thought that one byte extra per stored image, or at most one .i variable extra per stored image, was a big deal.

One byte saved is a byte not wasted you (or someone else) can use for something else.

Anyway, as Ramihyn_ noted, a byte would be not enough.

Ramihyn_ wrote: But how much is that of use with JPG or PNG files if you dont know if it is a b/w image, 2 bit, 16-bit, 24bit, 32bit with alpha informations, which compression level was used or if it isnt even compressed.

LastImageFormat() could return a pointer to a structure with all that informations instead of an integer then.
Again a temp structure overwritten after each load/catch.
Load/catch image routines should know all that to work.

What about user-made decoders such as the OLE Image Decoder that was floating around a couple of years ago... Essentially this function would be suitable only for the native PureBasic image codecs...

If you need the functionality, you could always just declare a global Map which stores the #Image as the key (Using Str(#Image)) and do it from there...

Remember, some of the codecs support multiple format extensions, so you would essentially have to identify the file yourself for this anyway, as I would presume PureBasic does a trial-error method to load the image by passing it through each of the decoders until it loads... (I could be wrong).

OR you could use FreeImage which detects the image format from the file signature, and use that to get the reference for it.. you could also have support for many more formats.

I'm currently using the file extension and am content to stay with that solution.

It's great because we are content too !