XnView Software

Do you have any idea what could be happenning? Updating the SDK could solve this? could the users update their SDK without installing again the program?

Strange, the crash occurs in GetPicture? If you update the SDK, you need to rebuild your app

Hi Pierre, I cannot know the exact line at which ...

Hi Pierre and all,

A couple users of one on my programs ( Histogrammar ), using GFL SDK VERSION 2.70, are recently experiencing problems after their XP machines seem to have been updated .

I attach 2 of these screens since I have no means to know the exact Sdk function that crashes, but seems to ...

Anyway I would like to report this minor BUG to the author of GflSDK, just a 1:1 aspect ratio by default on GIFs would be appreciated.

Strange, i use 1:1 ratio, could you send me a gif sample?

Sure, here you are: http://www.guillermoluijk.com/article/superccd/histosuperccd.gif

It displays OK ...

As there is nothing in GFLSDK you can modify your file after the save operation and change the corresponding value in the file's header :
http://www.u229.no/stuff/GIFFormat/
I try to change this value in your file then the file is directly well displayed in photoshop.

Cool, right what I needed ...

dominique wrote:In photoshop, you have an option : Image > Pixel Aspect Ratio > Square

Dominique, that is exactly what I did to obtain the former image correctly displayed.
My qestion is: is there anything that can be done in the Gfl SDK to obtain .GIF files straight in a correct 1:1 aspect ratio?

BR

So what could be the solution? this is how GIF files look when opened in Photoshop (up straight from GflSDK, bottom after correcting aspect ratio to sqare):

http://img79.imageshack.us/img79/9670/dibujogh3.jpg

The original GIF can be found here: http://www.guillermoluijk.com/article/superccd ...

When I save a GIF file using GflAx from VB, I get images that have a pixel aspect ratio of 0.250 instead of being square pixels. This is no problem in Windows browsers that ignore the ratio tag, but Photoshop recognizes it and open the images stretched in the horizontal direction.

By simply ...

Hi all,

I am reading a gray scale TIFF, i.e. an image where each pixel value just appears once and all pixels should be interpreted as R=G=B.

I am using 16-bit GflSDK from VB with this code to read it:


Dim GflParams As GFL_LOAD_PARAMS
Dim PtrBitmap As Long
Dim GflInfo As GFL_FILE_INFORMATION ...

I use it a lot. In all my particular experiments regarding image processing. I have also developed some pieces of software for image processing where I use it:

Tone Hacker : a program to rip tones from B&W toned pictures:
http://www.guillermoluijk.com/software/tonehacker/index.htm

Histogrammar ...

that happens to me with the GIF files generated by the xnview library, while other GIF are correctly open.

did you experience that problem with GIF generated by xnview?

Great Pierre!!! I have finally managed to load two 16-bit TIFFs, process them in the range 0..65535 and put them back into a 16-bit TIFF file, all from VB.
I am really very happy :)

I have written a program to generate virtually noise free images from two shots and it processes two 8Mpx 16-bit TIFF ...

Unfortunately not.

But I have seen that the signed/unsigned controversia is quite common when dealing with DLL's from VB and can be solved using simple functions as:

Option Explicit

Private Const OFFSET_2 = 65536
Private Const MAXINT_2 = 32767

' Converts from what Color.Red produces into ...

Perfect, at last I could read 16-bit TIFF files in their original range!!!

Problem: the The GFL_COLOR structure is defined in C as unsigned int (0..65535) but when called from VB values greater than 32767 are returned as negative, forcing some additional uncomfortable checking.

For instance ...

ok I will try that "GFL_LOAD_ORIGINAL_DEPTH" flag.
I am calling your functions from VB, but I was already using the C libraries according to your examples. Not using the activex component.

Or you mean from VB is absolutely impossible to get the image data in its original 0..65535 range?

Thanks

Yes, here the data will be in the range 0-65535

Hi Pierre, I am sorry to take this again but this is critical to me and after trying I can't manage to read the colour values of 16-bit TIFF files in their original 0..65535 range. Here is a sample of 16-bit TIFF with all 3 channels set to 31612 ...