GFL SDK and Nikon RAW Format (NEF D200 Body Camera)

[nicephore]

Hi
Did GFL SDK work with RAW image ?

[xnview]

Yes, why?

[nicephore]

Yes, why?

I'v look GflSDK.20100321 (in http://newsgroup.xnview.com/viewtopic.p ... 530#p83064), compil the DPR with Delphi7 and opening Nikon D200 NEF file i get error like

FR - "Opération en virgule flottante incorrecte"
EN - "Floating-point operation error"

No pb with Nikon jpeg file format.
I need help for opening Nikon RAW format

[xnview]

Could you send me the RAW file to test?

[AmigoJack]

Now I also have something similar:

• I open a jpeg-file with gflLoadBitmap() with no problems at all,
• can assign that to be displayed and also read dimensions, format... everything.
• When calling gflBitmapHasEXIF() it gives GFL_TRUE, so my next call is:
• gflBitmapGetEXIF() - and while calling this an exception of type EOverflow occurs: "Floating point overflow".
• GFL does not have to be re-initialized to load another image. Only the image's EXIF-data is causing this error and luckily not affecting any main handle of the image itself.

I will send you the image, Pierre.

[AmigoJack]

I found a cure - and there are at least two things which cause this misbehaviour:

1. Delphi turns ON floating point division errors, while Visual or Borland C++ turns them OFF. I suspect Pierre compiles the DLLs with some C++ compiler. This is the reason why we have a different behaviour between Delphi and (all?) others.
2. When loading the .NEF-files there does occur a division by zero somewhere - but due to the compiler settings those have been silently ignored all the time! Do we really want this?

I added two files for the demo application - they include a new function which is used to turn off FPU exception. Just replace the latest GflSDK for Delphi (version 20100321) and then overwrite with the two files from the attachment on this post. I tried it with Delphi 5 and nicephore's two .NEF-files - works flawlessly!

The topics I found on the net were http://www.pascalgamedevelopment.com/fo ... 845.0;wap2 and http://www.ghisler.ch/board/viewtopic.p ... 775#180775 and http://books.google.com/books?id=Wu4hhG ... &q&f=false. The third one is from a book, where an example is very well pictured:

The problem here is: EDivByZero only occurs if both dividend and divisor are integers. As soon as one of them is a floating point number an exception EInvalidOp ("invalid floating point operation") will occur:

0 / 0 = EDivByZero
0.0 / 0 = EInvalidOp
0 / 0.0 = EInvalidOp
0.0 / 0.0 = EInvalidOp

So Pierre - while my approach is only a workaround - could you please trace down the division by zero error? I'm very sure it occurs somewhere. You should also see it immediatly when adjusting the compiler settings likewise...

[nicephore]

AmigoJack
Thank's for help, this work good.

[AmigoJack]

I was asked how to revert from calling my MungeFPCW() function back to the state it was before - it should be as easy as

Code: Select all

asm
  fldcw   pwOldCW
end;