Re: Comparing two images
Re: Comparing two images
- Subject: Re: Comparing two images
- From: Lorenzo <email@hidden>
- Date: Fri, 28 Nov 2003 16:44:49 +0100
Thank you Alastair,
I understand, the image could be the same, and the fields could be writtend
in different order, so, which is the best way to compare two (large) images?
Should I use some QT routine?
Anyway, I realized that the concept of "equal" could vary so much.
A photograper could say that two images are equal only if more that the
images, the EXIF values are equal. Another user can say that if the
compressions values is different, the images are not equal, and so forth.
So let's consider the files are not images, but simple files, and I would
like to compare them byte by byte. So I will consider equal only the images
that have been duplicated by the Finder only.
Best Regards
--
Lorenzo
email: email@hidden
>
From: Alastair Houghton <email@hidden>
>
Date: Fri, 28 Nov 2003 10:47:48 +0000
>
To: Lorenzo <email@hidden>
>
Cc: email@hidden
>
Subject: Re: Comparing two images
>
>
On 28 Nov 2003, at 10:25, Lorenzo wrote:
>
>
> When I met the first different byte I close the routine and say: they
>
> are
>
> not equal. Correct?
>
>
Not necessarily. It is possible to have the same image saved in the
>
same format but in files that differ(!) This is true for a variety of
>
reasons, including:
>
>
* Padding or "reserved" fields in some file formats, the contents of
>
which are not always defined (so some of them might not be explicitly
>
initialised by software that writes the files).
>
>
* Different choices re. compression. Even with the same compression
>
method (and some formats support multiple compression methods), it's
>
possible in some file formats to specify parameters for the compression
>
technique, in which case different software is free to choose different
>
parameters.
>
>
* Ordering of elements. In formats like TIFF and PNG, the file
>
consists of a sequence of tagged records; these records won't
>
necessarily occur in the same order, for example because different
>
programs write them out in a different order.
>
>
* Fields that inherently differ. Save count, or timestamp fields, for
>
example.
>
>
Are you trying to compare the *image*, or the file? Can you guarantee
>
that the same image will be in an identical file (for your
>
application)? (Hint: you'll need to check the specs for the image
>
format you're using; even something as simple as a timestamp field
>
could mess-up this assumption.)
>
>
> I have some Carbon code somewhere that opens files and read them chunk
>
> by
>
> chunk using FSpOpenRF, GetEOF, SetFPos, FSRead. Do you think it can
>
> still
>
> work well on MacOS X?
>
>
Probably, but see below.
>
>
> I know they cannot manage data or resource forks > 2GB. Or, how to do
>
> that with Cocoa? With NSFileWrapper?
>
>
No, no, *no*! NSFileWrapper isn't there for you to use for loading
>
files. It's there so you can embed a file in an NSTextView.
>
>
NSFileHandle is the Cocoa way to access files.
>
>
You could also consider the BSD functions, which will work just fine
>
for this application. (BTW, if you want to open a resource fork using
>
Cocoa or BSD APIs, you can just open "<filename>/..namedfork/rsrc".)
>
>
Kind regards,
>
>
Alastair.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.