[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need advice on 1) binary files, 2) locking

From: Eric Siegerman
Subject: Re: Need advice on 1) binary files, 2) locking
Date: Tue, 9 Oct 2001 21:00:27 -0400
User-agent: Mutt/1.2.5i

On Thu, Oct 04, 2001 at 02:05:46AM +0400, Tobias Brox wrote:
> There are three classes of picture formats:
> - Bitmaps (a picture, as it is displayed to the screen).  Perhaps
> practically impossible, but if you had one line for one pixel, you would
> actually get text files that easily can be diff'ed and merged.

Not meaningfully -- unless the user can make sense of the
resulting CVS-style conflict indicators, an impossible task for
more than the most trivial of changes.  So there's little to be
gained from doing something this bizarre.  (It would help reduce
the size of the ,v file, but that's probably the *least*
important issue in all of this).

Slightly (but only *very* slightly :-) better would be to convert
the bitmap to some text format with one line per bitmap row, so
that merge output would be at least a bit meaningful to the human

What's needed is a GUI-based interactive bitmap-merge tool.

> - Vector/object data - that can be rendered into a picture.  Such data
> should be perfectly possible to represent through text files, and those text
> files can be under good version control.

Again, will this text representation be *meaningfully* mergeable?

Turning a binary file format into some text representation per se
doesn't help much.

> - Compressed bitmaps - and then I'm talking of lossy compression
> [...]
> I guess (correct me
> if I'm wrong) the only way a compressed image can be edited is through
> converting it to a bitmap, and then back to a compressed image.  I would
> daresay that quality is lost every time the edited bitmap is compressed

Stands to reason.  This issue is orthogonal to version control,
though.  People working with JPEG files straight, without any
version-control tools at all, will face the same problem (however
large or small it really is).

> I think it
> would make more sense to store the uncompressed bitmap in CVS, and rather
> have a tool (typically a Makefile) to create the compressed images.

Indeed.  Or save the file in a non- or losslessly-compressed
format while you're working on it (e.g. TIFF or PhotoShop's
native format), and export it as JPEG or whatever only when
you've finished (at the point when, if your final product had
been hard copy, you would have sent the file to the printer).
Admittedly this is error-prone, but it's probably the standard
approach in pure graphics shops, if they can't completely avoid
lossy compression in the first place.


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
The world has been attacked.  The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short run.
        - Jean Chr├ętien, Prime Minister of Canada

reply via email to

[Prev in Thread] Current Thread [Next in Thread]