XMP, Krita, KFileMetaInfo and Strigi

Ingo Klöcker kloecker at kde.org
Sat Jun 23 21:11:08 BST 2007


On Friday 22 June 2007 23:44, Cyrille Berger wrote:
> > > > > But the biggest problems and limitations comes from
> > > > > KFileMetaInfoItem - QVariant is not good enought:
> > > > >  - it lacks some important types like rationals
> > > >
> > > > a double is not a rational? QVariant::Double
> > >
> > > Yes it is, but a rational isn't a double, it's a division between
> > > two integers.
> > > For instance, there is no double representation of the rational 2
> > > / 3 (0.66666666666666666666666666666666 is just an approximation,
> > > even if the mathematical theory says that 0.666 followed only by
> > > 6 is equal to 2 / 3, but there is no way to represent such a
> > > thing in double, 2/3 is represented by 0.666..67 in a double
> > > anyway).
> >
> > It is very simple and not expensive to find a nice rational from a
> > double.
>
> Is it ?

Yes, it is.

> Good luck on finding the original rational for this one 
> 3.52548656163114 (it's a real life example taken out of the exif tag
> of my camera) or 8.45121765136719 (ShutterSpeed taken from
> http://exif.org/samples/canon-ixus.html).

A fifth or sixth grade with a calculator should be able to do this. The 
key word is "continued fractions" (cf. the link in Evgeny's message) 
and the algorithm is dead simple.

All you have to do in each step is cut off the number before the decimal 
point and then calculate the reciprocal of the remaining number. Let's 
take 3.52548656163114.

cutting off 3 we get 0.52548656163114 with reciprocal 1.90299823633157
cutting off 1 we get 0.90299823633157 with reciprocal 1.10742187500000
cutting off 1 we get 0.10742187500000 with reciprocal 9.30909090909083
cutting off 9 we get 0.30909090909083 with reciprocal 3.23529411764786
cutting off 3 we get 0.23529411764786 with reciprocal 4.24999999998547
cutting off 4 we get 0.24999999998547 with reciprocal 4.00000000023245
cutting off 4 we get 0.00000000023245

Now we put everything together:

3.52548656163114 = 3 + 1/( 1 + 1/( 1 + 1/( 9 + 1/( 3 + 1/( 4 + 1/4 )))))
                 = 3804 / 1079

And for 8.45121765136719 we get
8.45121765136719 = 8 + 1/( 2 + 1/( 4 + 1/( 1 + 1/( 1 + 1/( 1 + 1/( 1 + 
1/( 1 + 1/( 79 + 1/( 3 + 1/3 )))))))))
                 = 553859 / 65536

Also see the attached spreadsheet.

> The goal isn't to find "a" 
> rational, which rules out 352548656163114/100...00, the goal is to
> find "the" rational (and multiplying 8.45121765136719 by 65536 isn't
> good enought has there is no way to know that this was the
> denumenator in the first place). You might say who cares ? Yes who
> cares about data lost. There is one specific reason why the people
> behind exif have choosed to use rationals and not double, it's to
> avoid the lost of precision.

Do you have a reference for your claim?

The great thing about the KDE project is that there are people who know 
all about color spaces and there are people who know math. The bad 
thing is that sometimes people can't resist talking about stuff they do 
not know (like me in the color blending thread).


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: double2rational.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 16045 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070623/dd1ab248/attachment.ods>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070623/dd1ab248/attachment.sig>


More information about the kde-core-devel mailing list