Tuesday, February 16, 2016

Post-Picasa Replacements - Followup Notes #1

As a followup from yesterday's post/rant about Picasa things, I've started doing some digging around about ways to achieve the "Fill Light" technique, as well as started the process of auditioning potential replacement systems.

This will probably be the first of several post about this topic (though how many there will be I don't know yet), and will just be a way for me to keep track of my notes and findings about what works, what doesn't, and what may potentially be useful information.

Criteria/Wishlist for Ultimate Picasa Replacement
While Picasa is not 100% perfect, it does a lot more stuff right than it does wrong, especially after seeing all the alternatives that other packages are serving up. Here's my list of the core things that I like about Picasa (or actually, these are like 95% of my standard photo management + editing workflow today), in rough order of importance.

1. A simple "Fill Light" slider that works exactly the same. Brightness/Gamma/Lightness/Midtones don't really cut it, as I've already discussed.

2. A "Shadows" and "Highlights" slider - to compliment the "Fill Light" slider. Fill Light by itself is not usually enough; Shadows helps push back a bit of the darkness (i.e. widening the dynamic range back again), while Highlights adds a little bit of extra punch to, well, the highlights.

3. Non-Destructive Editing Workflow - To save on disk space and avoid the potential for nasty f***-ups where I accidentally overwrite the original, it's important that the tool works with a non-destructive editing workflow, where all edits are applied dynamically as filters (or equivalent) to the original file, and the edited file only gets saved when I explicitly export it for use in other places.  (Sure, this carries the same risk of vendor lock-in as now, but at least I have the option now of doing a batch export of everything baking in whatever editing I've done).

4. A "Straighten" tool that's simple to use (e.g. single slider, no need for pivot positioning really), and which will not leave behind any triangular black regions while maintaining the same aspect ratio as originally. (I only really realised the importance of this during my DigiKam stint on Linux Mint 3 years ago)

5. A "Crop" tool that allows dragging on the canvas what to crop - defaults to freeform, but can also be set to only work in particular ratios (including custom ones) as needed

6. A simple equivalent to the "Starring" system in Picasa. Fortunately, many of the things on the market have this; the big question is how I can import all the existing starring data into whatever new app I use.

7. Easily browsable interface. Folder hierarchies MUST be flattened (I've written many many pages of text about why this should be the case.... and read further more, as part of my previous research work), allowing smooth browsing from album/folder to folder, from oldest to newest. Furthermore, images + videos must be viewable in the same gallery views, and can be previewed in the same ways (without needing external tools).  (Thumbnail loading time should also be minimal)

8. Convenient UI Design/Workflow. All the technical prowess in the world will be useless if it's a bloody pain to work with. This includes stuff like how easy it is to go between looking at the gallery, to viewing the image in more detail, and then applying some basic edits (with subtle adjustments for per-shot specifics) to that one and the following set of 80-200 other shots quite quickly. Some allowance will be given to systems where the default UI may be a pain, but with a bit of customisation, it can be hacked into a form where all the stuff I use is easily accessible/able to be applied, and everything else can continue to live in the background.

Nice to Haves/Not deal breakers, but are things I'm very interested in having:
9. Supports (or can be extended to support) a way to convert all existing Picasa-based effects over to the new system. This is important if I don't want to have to first do an export of all Picasa-created edits. If I do that, I might as well go ahead and set up that new photo storage + editing beast I've been starting to plan for a few years down the track...

10. Camera Lens Distortion Correction - I played with this in DigiKam a few years ago, and it is one of the few things I miss about that thing. There are a good handful of shots I've got which could really benefit from having this applied to them, but the logistics of getting it through such a tool have proved to be a bit too much trouble so far.

11. Some good ways to boost "richness of colour" - Anyone who's seen what I like doing will know that I have a bit of disdain for greyish/blue-grey-haze making stuff look drab. Specifically, sometimes you want a "saturation" like effect, except it doesn't blow out the red/orange/yellows and/or RGB Blue (like on the round blue streetsigns here in NZ). Basically, it should make yellows more orange, greens richer, and browns more red/orange (vs grey-brown).  From my tests so far, "vibrance" doesn't quite do the trick...

12. A way to direct colour tweaks (fill, shadow, highlights, richness) to specific parts of the image only, but without causing harsh shadows or "halos".  Perhaps the only downside of Picasa is that sometimes, you know that a particular amount of Fill Light will fix a specific part of your image (e.g. a face, or building, or thing in the foreground), but you can't use it because of a bloody famous landmark in the background that is a white marble building and in full sunlight (as that would instantly blow out).

13. Open Source (or made by a sufficiently big company that won't go under or axe the product anytime soon, has a decent/humane licensing scheme, and doesn't charge insane prices).  I'm sure the reasons for this are all pretty self evident, I'd like to thing :)

14. Adjust all timestamps (by a delta). Would be useful for fixing the discreptancies I've got between image times and video times, and also when changing timezones (having forgotten to properly fix that on arrival)

15. White Balance Tweaks (working on JPEG's) - Key targets here are to fix 3 particularly hard-to-fix-in-camera issues: a) "Normal" warm indoor incandescent lighting, b) Lantern/Street/Candle Lighting (where warmness is to be kept), c) Automobile glass "sickly green tint"

Nice to Have - I could very well do without these, but having these would be nice too:

16. Annotation Tools - Easy Text Placement + Adjustment, and Freehand Annotations

17. A "smudge out" paint tool to get rid of unsightly stuff - (This is best if it draws on stuff like the recent research to resize the canvas while keeping everything in frame, and stuff like that...)

Dreamtime - "Magical 'Make Image Better' Tools" That Require Serious Research:
18. Reflection + Glare Removal  - Basically, this thing built into the photo editing tool, except that it would work with maybe just 1 image (optimal situation), or 2-3 (usual situation for an "out the window" shoot, where there may be some general commonalities to be isolated).

19. "Blur/Shake Be Gone" - A tool that, given a single image input, can completely eliminate camera shake (by tracing the ghosty streaks, eliminating their contributions, and correcting for loss of contrast arising from that). This would save countless family photos.  If anyone wants samples for development, I've got heaps from the crappy old Point 'N Shoot (and can create heaps more on command if needed) ;)

20. "Correct Minor Missed Focus Errors" - A tool that takes those shots where you were "almost" focussed on the right place, but just missed by a hair. Often, there are many images that look fine in zoomed out and scaled down, but when zooming in a bit, are tragically ruined. Again, to be done from a single image input.

21. Denoise - Imaging noise is the bane of every visual artist. 'Nuff said.

22. Dynamically Relight the Scene - Well, maybe this is possible with all the other tools, but imagine being able to just grab the estimated physical light sources, move them around, and see the image adjusted...

Assessment of These Goals
From initial assessments of the photo editing landscape, the likelihood of meeting even a fraction of these (especially some of the more important ones) is quite low (if not zero). There are a few promising tools, but they all seem to fall down on one or more fronts :(

In many ways, the only/best solutions to actually get what I want here may be:
1) Get Picasa Open Sourced

2) Write my own. Maybe by taking the best parts of the existing open-source ones, and binding them together with some of my own magic, within a UI design that was built my way, for my needs first (and anyone else whose needs/tastes suitably align).  Perhaps this one might work out... I do have a bit of a track record on this sort of thing I guess... though that time would have to come out of somewhere, which I don't have right now!

Finding Picasa's "Fill Light" Algorithm
As one of the first steps, a key objective is finding a good replacement for this important tool.

In yesterday's post, I mentioned a forum post/thread about something a random guy on the internet had been working on for a while that seemed impressive - producing equal if not better results to the Picasa algorithm.  For reference, the thread is here.

Reading it in more detail today (and perhaps another source too), I finally understood a bit more about the general approach that may be being used here. Apparently, it's one of a class of "tone mapping" algorithms, that may be operating on Lab colours instead of doing the histogram shifting tricks that most of the "fill" and so forth controls are doing now.

In particular, while checking the literature and web afterwards, several thing started popping out after finding this "magic terminology" used to describe the stuff (and really, that's a real problem we have in many disciplines today.... competing researchers, many in different fields altogether, are actually focussing on the same bloody problems, making different levels of progress in their own ways, but each cluster being completely unaware of the findings of the others, or the fact that those findings could be cross-pollinated to plug gaps in each set of attempts, and all because each cluster of researchers uses a completely different set of terminology, that the others wouldn't think to use...  GAH! The reality of my current PhD project...)

Several of the most salient entries here are:
1) Bilateral Tone Mapping - See Durand and Dorsey's paper from Siggraph 2002 - https://people.csail.mit.edu/fredo/PUBLI/Siggraph2002/ 

This seems to be one of the important papers in this area (from my initial investigations at least), especially with regard to working with HDR's (in particular, stacked HDR's). Whether it's so useful for single images though is something I'd still have to look into.

2) LDR Tonemapping - A technique/utility by Nasca Octavian PAUL, released under GPL for Windows + Linux

I've had a play around with this, and it appears promising. In one of my test files, it was giving a good result. More testing still required to figure out how to really best use it though...

What I'm not sure about (nay, downright confused about) currently is what  the whole point of the "stages" stuff is, and/or how I'm supposed to make use of that.

2.5) Digikam - Local Contrast
DigiKam has a tool built in which has basically taken the LDR Tonemapping code, and ported it over. I've had a play around, and while it does make things better (mainly since this is integrated into a tool with access to the rest of the library, along with other editing tools), working with Digikam as a whole is a pretty dismal experience (more on this later).

So, in conclusion, we're starting to get somewhere with this I think. Hopefully someone can connect up the rest of the dots on this...  (or maybe I will eventually, in which case, I'll likely end up building some tool to patch up the difference between the two models)

Deciphering Picasa's Metadata Storage
Another important step in migrating my library/workflow from Picasa to another tool is finding a way to take advantage of all the existing stuff I've got in Picasa (in particular, the edits made, and what has been starred).

Fortunately, with a bit of digging, it looks like someone has been doing some digging into the format of the Picasa .ini files. Full link here.

From my perspective, here are the key points:
1) star=yes   <--- under metadata per photo. Self explanatory this...

2)  Filter Strings - This is how all the edits are described

# all applied filters per photo are recorded to .picasa.ini
# to provide an editing history and/or an easier undo facility.

# Basic filter key format:
# the filters key of each photo stores a semicolon-separated list of filter entries:


# each entry follows the format
# <filter identifier>=1,<filter value 1>,<filter value 2>,<..filter value n>;

# Here is a list of valid filter identifiers
#| crop64      |  CROP_RECTANGLE*                    |   crop filter, crops the image | crop64=1,30a730d2bf1ab897     |
#|             |                                     |    according to crop rectangle |                               |
#| tilt        | !TILT_ANGLE,!SCALE                  |  tilts and scales image        | tilt=1,0.280632,0.000000      |
#| redeye      |                                     |  redeye removal                | redeye=1                      |
#| enhance     |                                     | "I'm feeling lucky" enhancement| enhance=1                     |
#| autolight   |                                     | automatic contrast correction  | autolight=1                   |
#| autocolor   |                                     | automatic color correction     | autocolor=1                   |
#| retouch     |                                     | retouch                        | retouch=1                     |
#| finetune2   | (unidentified params)               | finetuning (brightness,        | finetune2=1,0.000000,0.000000,|
#|             |                                     |highlights, shadows,color temp) | 0.000000,fff7f5f3,0.000000;   |
#| unsharp2    | !AMOUNT                             | unsharp mask filter            | unsharp2=1,0.600000;          |
#| sepia       |                                     | sepia filter (no params)       | sepia=1                       |
#| bw          |                                     | black/white filter (no params) | bw=1                          |
#| warm        |                                     | warming filter (no params)     | bw=1                          |
#| grain2      |                                     | film grain filter (no params)  | grain2=1                      |
#| tint        |!!PRESERVE_COLOR ,#TINT COLOR        | tint filter                    | tint=1,79.842102,ffff         |
#| sat         |!SATURATION                          | saturation filter              | sat=1,0.161800;               |
#| radblur     |!MOUSE_X,!MOUSE_Y,!SIZE,!AMOUNT      | radial blur                    | radblur=1,0.500000,0.500000,  |
#|             |                                     |                                | 0.239766,0.146199;            | 
#| glow2       |!INTENSITY,!!RADIUS                  | glow effect                    | glow2=1,0.650000,3.000000;    |
#| ansel       |#COLOR                               | filtered black/white           | ansel=1,ffffffff;             |
#| radsat      |!MOUSE_X,!MOUSE_Y,!RADIUS,!SHARPNESS | radial saturation              | radsat=1,0.421652,0.594697,   |
#|             |                                     |                                | 0.333333,0.309942;            | 
#| dir_tint    |!MOUSE_X,!MOUSE_Y,!GRADIENT,!SHADOW  | directed gradient              | dir_tint=1,0.306743,0.401515, |
#|             |                                     |                                | 0.250000,0.250000,ff5bfff3;   |
# ! = float between 0 and 1, precision:6
# !! = float with arbitrary range, precision:6
# # = 32-bit color in hex notation, e.g.: fff7f5f3
# [] = crop rectangle


text=1;136;11;sample text;Aharoni;0.279301,0.503929,0.033333,0.000000;v1,4294967295,4278190080,128.000000,1.000000,0.364486,0.878906,700,258,49152;;

3) Crop Rectangle Description  - 64-bit string, divide into 4 16-bit strings -> each is a float giving proportion along x/y axes from min/max crop coordinates relative to image bounds



# Picasa uses a special string format to store crop boxes of
# detected faces and from an applied crop filters. The number encased 
# in the rect64() statement is a 64 bit hexadecimal number:

#     rect64(3f845bcb59418507)

# break this number into 4 16-bit numbers by using substrings:

# '3f845bcb59418507'.substring(0,4) //"3f84"
# '3f845bcb59418507'.substring(4,8) //"5bcb"
# '3f845bcb59418507'.substring(8,12) // "5941"
# '3f845bcb59418507'.substring(12,16) // "8507"  

# convert each obtained substring to an integer and divide it
# by the highest 16-bit number (2^16 = 65536), which should give 0 < results < 1.
# these are the relative coordinates of the crop rectangle (left,top,right,bottom):

# parseInt("3f84",16)/65536 //0.24810791015625  - left
# parseInt("5bcb",16)/65536 //0.3585662841796875 - top
# parseInt("5941",16)/65536 //0.3486480712890625 - right
# parseInt("8507",16)/65536 //0.5196380615234375 - bottom

# for absolute coordinates, multiply the left/right coordinates with  
# the image width and the top/bottom coordinates with the image height

Auditioning Replacement Apps
As of today, I've ended up testing two apps so far.
1) Digikam - Windows Port
2) PT Photo Toolbox - http://www.photo-toolbox.com/product/photo-editor/

And have begun pondering two others:
3) Darktable
4) Lightroom


1) Digikam
I've used DigiKam before, last time on Linux, under a dual-boot machine. So, I kindof knew what I was getting myself into here. In this case, I just wanted to test the Local Contrast tool, to see how well it worked, and also to check whether DigiKam is feasible under Windows, when faced with my full collection.

The first major black marks against it were:
- Importing the library took a good 2 hours or so, and for those two hours, it thrashed the disk so badly, that my machine was all but unusable (i.e. as if the CPU's were maxed out, yet only < 3% was being used)

- Immediately after importing had finished, it crashed. I had to start it again for things to load.

- When trying to load some images for testing, it promptly reminded me of some of the reasons why I'd gotten so frustrated with it 3 years ago, and given up trying to use it back then (as one of the reasons which prompted a return to Windows, ending m grand Linux experiment)

So, what's so bad about Digikam's interface. Heaps, it seems. Especially when measured against the criteria listed at the top. Specifically:
  - Destructive Workflow - Every time you tweak a file, it'll create a new file, unless you're asking it to overwrite your originals!  When it does start filling your folder with duplicate edit versions, it then becomes hard to tell which version is which (made all the worse when you view it outside Digikam, and find a folder polluted with extra temp files)
  - Straighten tool - leaves behind triangular "dead zones" around the image, where stuff got moved. So, you then have to try and painstakingly find a way to crop it, while maintaining the old aspect ratio while trying to fit everything in that's wnated (and keep out everything else)
  - Browsing through the collection is a pain - It it goes through folder by folder (and you have to expand/collapse/navigate to each to do this), or it sticks everything in a big mushy folder where it's unclear what's directly in the folder and what's a child, while taking ages to load snapshots everytime you change the view. Furthermore, there are no thumbnails for videos, which can't be played in the same app either...
 - General UI Nastiness - There are a lot of features, scattered all over. Trying to edit an image though means that you get this new window opening up, but on each new restart of the app, this window will be far too small (i.e. it's always a narrow 300-400 px high window, 900-px wide, and with the image displayed tiny in the middle. And that's not to mention the confusing nature of trying to update settings of tools...  Also nasty is the fact that all the tooltips only have light-on-light text, making them impossible to read (it's worse that despite several theme styles, there is no way to fix specifically the colours there!)
 - General Slowness - For the record, this doesn't seem to be just a problem with the Windows build, but with the flagship Linux builds too!  This app is just all round slow and sluggish to respond to inputs. A click is often undetected/unhandled for a second or two, even for UI components. All in all, it reeks of really bad UI event programming - like they're doing heaving lifting computations in the MAIN UI THREAD!!! It's atrocious!

But, at least it contains all of the powerful tools in one package (assuming you can access them, and put up with the bugs to get some use out of them)!

2) PT Photo Editor
This one popped up in one thread at some point, and I decided to give it a quick go. Here's my verdict from playing around with it for a few minutes so far:
   - First, the general UI stuff (widgets, styling, placement) is generally ok, and quite novel in some ways. On that level, it seems to work fine enough.
   - The image editing options for adjusting exposure (in the ways I'm talking about) though leave a bit to be desired. In particular, the "Fill Light" doesn't work that great IMO, while the inverted "Shadow" slider direction was driving me crazy.
   - Perhaps the real deal breaker here is that horrid, horrid way of browsing through your photo collection. It's a single-row strip across the bottom of the screen, which requires you to double click to navigate in and out of each folder, and to view different images.
  - It's made worse by the fact that this app uses a destructive workflow (it prompts you to save edits made, before allowing you to switch images!)


3) Darktable
I haven't been able to try this one again yet. Which is a pity, as I'd briefly played around with it on Linux and been quite impressed at the time (despite a critical bug at the time which made it unfeasible, and not having that big a collection to try with it).

At least from their documentation and gallery and other materials, they've got some really good stuff going on here...

The downside is that they have a rather hostile position towards Windows (and to a lesser extent, to MacOSX, from what I could tell). As it stands, the lead developer's stance towards even admitting that the thing can be compiled and run on/for Windows (and of providing a well documented way of trying to do it) is rather hostile.

From a quality-control/tracker triage management perspective, I do understand the distaste for providing "official" builds if they're not going to be able to properly maintain/support it. But, that is also not quite an excuse for not accepting/allowing any Windows builds to show up on their site at all - even if they are labelled as strictly unsupported/experimental things, and that they may be several version out of date if no-one steps up to the plate to provide new builds that are supported.

In the meantime, I'll only be able to report back on this after rebuilding a VM to run it in. After my last one got hosed by a combination of Windows Updates + an ill-advised "apt-get dist update" to try and fix the blasted sound + internet troubles post WU + VBox Update + Buggy VM Functioning... I'll have to start all over from scratch there before I can do anything about it

4) Lightroom
It looks like if all else fails, I'll have to try and secure a standalone copy of this thing if I can, and get used to tolerating it... Maybe there will be some good stuff there (heaps of people use it, so there must be some worth), but, gah!  It doesn't really work like I'd like it to!

No comments:

Post a Comment