Lossless image editing

[dmoore]

In recent commits, I have started the fairly complicated process of adding lossless image editing support to picty.

What does this mean? You can straighten, crop and enhance a photo and save those changes as metadata to the image. The edits you save aren't overwriting the orignal image, you are just writing a Xmp tag that describes the editing steps into the image file. (For the technically minded, the image editing steps are stored in the xmp tag 'Xmp.picty.ImageTransforms')

You can flip between the original and edited image by selecting which you want from the picty image viewer popup toolbar. You can completely revert your image edits by clicking on the "Remove edits" toolbar button on the popup toolbar. Dragging edited images from the browser to a file manager of the desktop will write a jpeg copy of the image with the image edits applied. Ditto uploading images transferred to a flickr collection using the transfer interface.

What's to come? The user interface is a mess. This will get better. The user interface for the image will be gradually overhauled.

[Dariusz Duma]

Will this affect RAW files? (dcraw parameteres in xmp?). I'm sure, RAW files need other edit window (white balance, demosaic, highlights and so on). Will edits respect color profiles (system default or set manually)?

And the xmp files will be saved next to original file? I mean - what if somebody will move original photos (included in collection) from original destination to another place?

[dmoore]

Good questions. As a preface, I would definitely be cautious with this for now. In particular, be careful about saving any changes to images that haven't been backed up. It should be fine because the only thing that is written to the file is metadata and at least for now I am not touching any of the original metadata except for the orientation flag and some of the descriptive tags, but I really don't know how well tested the writing of custom namespaces in exiv2 is. picty can be configured to write to an xmp sidecar, but currently this only happens for images it fails to write to. I guess i could add a feature to always use sidecars on a per mime type basis.

On Saturday, June 1, 2013 12:08:52 AM UTC-4, Dariusz Duma wrote:
> Will this affect RAW files?

Yes and no. The current editing plugins are (a) really basic and (b) apply transforms to whatever image types PIL supports. The default dcraw command that picty uses generates 8 bit images, so your edits will be applied to the 8bit image, which you could export to a jpeg or png. If you hit the save metadata option, picty will attempt to write the transform instructions to the original image, falling back to an xmp sidecar if that option is enabled.

Anyway, if you need powerful editing, picty is not the solution. Picty's editing features will probably always be targeted toward the quick and dirty

> I'm sure, RAW files need other edit window (white balance,
>demosaic, highlights and so on). Will edits respect color
>profiles (system default or set manually)?
>

I am looking into some of this stuff. PIL doesn't really support any of it (well in theory it supports 16bpp images, which is something) and raw processors are a pain to work with so this involves quite a bit of work. At a minimum I want to add 16 bit support, correctly translate colorspaces and add some basic demosaicing options, then some basic per channel curve/level options.

> And the xmp files will be saved next to original file? I
>mean - what if somebody will move original photos (included
>in collection) from original destination to another place?

exiv2 can write to some raw image types, so in those cases the metadata description of the image edits will be written into the image as an xmp tag: xmp.picty.ImageTransforms

In the cases where writing to the image is not supported, you can enable sidecar support. If enabled, Picty looks for a file with the same name plus '.xmp' in the same folder. For example,if the image file is img111.nef, then picty looks for img111.nef.xmp when reading metadata and, I think, writes to that file (a) if it already exists or (b) if exiv2 cannot write to the original. It has been a while since I looked at this part ofthe code, so I may be misremembering exactly how it works and it definitely needs some more testing.

I should also add that on a low end system the lossless editing can be painfully slow to process. Each time the image is loaded from disk each transform is manually applied.

Also bear in mind that there is currently no standard way of writing image edits to metadata. That makes the current implementation a bit of a hack.

Sorry if this isn't clear. It's late...