Re: images that play nicely with revision control?
On Sun, 09 Feb 2014 08:07:57 -0500, Henning Follmann wrote:
> On Sun, Feb 09, 2014 at 12:28:45PM +0000, Hendrik Boom wrote:
>> I'm looking for a file format for images that plays nicely with
>> revision control. Ideally I'd like to edit them while seeing what I'm
>> editing, whether it's a line drawing (like inkscape) or a pixel map.
>>
>>
> I think that doesn't exist.
That's what I suspected. But I asked in the hope that there was
something I hadn't heard of yet.
> At least not for all kind of images.
> SVG is basically an XML file. There you can at least compare the xml
> content. But that however is also very tricky, you might need something
> which converts it first into canonical xml and the compare/store it.
> But that is only efficient for vector images. For bitmap images that
> wouldn't work.
And XML can be difficult to do revision-merging on, even if furnished
with lots of newlines -- what the merge algorithm considers a perfectly
acceptable merge may end up violating XML's large-scale bracket matching.
Which means the user gets to worry about how his picture is coded, in
exasperating detail. But with some restricted limited-nesting XML files
it might be made to work.
But I can imagine bitmaps to be mergable, if not compressed, and if enouth
newlines are inserted in standard places, such as between scan lines.
Still, better techniques ought to be possible.
>
>> And I'd like to keep the whole thing under revision control (like
>> monotone, or git, or such. Currently I use monotone).
>>
>> But any kind of compressed file format is probably not going to cut it.
>> Revision control seems to be designed for program text, with lots of
>> newlines in stable places.
>>
>> If all else fails, and I get desperate I could even store my images as
>> programs in, say, Scheme or C or some such, and run the code to see the
>> image. But that would make editing difficult. And in that case, I'd
>> like recommendations to graphics libraries that can output to a variety
>> of formats, such as onto the screen, into a jpeg file, to svg or html
>> format, or some such.
>>
>>
> That approach is close to what adobe does. They basically have a master
> image. They store with that image every change. That is how Lightroom
> handles changes. This of course can be very demanding on cpu/gpu.
> Because everytime you load the picture you have to apply all the changes
> to the master, render it and display it.
So the change could sconsist of adding a bunch of code into the existing
file. And theh reverse change would consist of deleting it. Maybe non-
conflicting merging would even work. But the proper test for conflicts
would be whether the two changesets affected the same part of the image.
Unless someone comes up with something else, it looks like a topic for
further research.
And about compression? It may turn out that the space saved by not
duplicating parts of an image that didn't change may outweigh the space
lost by not compressing.
-- hendrik
>
>
>> I would definitely prefer not to write a whole new image editor from
>> scratch.
>
>
> -H
Reply to: