Commits on Aug 29, 2016
  1. Batch processor: continue overhaul

    The "add files to batch list" panel is being completely reworked.  Given
    the huge feature set of a standard common dialog window (the full power
    of Windows Explorer, basically), it doesn't make sense for us to try and
    manually mimic that level of functionality.
    Instead, the new dialog is built around adding images and/or entire
    folders from standard Windows dialogs.  The ability to add whole folders
    is much more elegant than the old solution, anyway, and this approach
    significantly streamlines the dialog, and greatly improves performance
    as the process list grows.
    (Note that not all options on the new panel are implemented yet.)
    committed Aug 29, 2016
Commits on Aug 25, 2016
  1. Start overhauling the Batch Process wizard

    As part of migrating PD to its own custom resource file format, I'm
    gonna be bulk-optimizing a ton of UI images (mostly PNGs).  The current
    batch processor is a mess, so it's time to get it fixed up, and
    integrate support for all of PD's new image export features.
    Note that this is a WIP, so you *still* need to avoid the batch
    processor for now.  I'll remove the warning window when the dialog has
    been thoroughly overhauled and tested.
    committed Aug 25, 2016
  2. Fix dark theme issues on PNG export dialog

    A few old picture boxes hadn't been converted to pdContainer
    committed Aug 25, 2016
  3. Fix premultiplication of images coming from GDI+ loader

    This primarily affects metafiles, as their alpha channels are calculated
    "on the fly" using new EMF+ features.
    committed Aug 25, 2016
  4. Fix handling of images with only one metadata group

    The sort function was failing on these images; oops!
    committed Aug 25, 2016
  5. Fix alpha glitches on modern EMF files

    Thank you to Zhu JY for catching and reporting.
    committed Aug 25, 2016
Commits on Aug 24, 2016
  1. Start work on theme resource editor

    This is one of the last big theming items still on the to-do list.
    Separating theme resources (like UI images) into their own custom
    resource file, which can be updated independently of PD's exe, will be a
    huge improvement over the current system.  It will also make it much
    easier for the program to do things like auto-select the best image
    resource for a given screen DPI.
    committed Aug 24, 2016
  2. Remove API scrollbar class

    No longer needed, since we have our own owner-drawn solution
    committed Aug 24, 2016
Commits on Aug 19, 2016
  1. pdCrypto: new API-based hash and crypto solution

    PD uses hashes in a lot of random places.  As one example: File > Open
    Recent caches recent file thumbnails using hashes of the original
    filenames (which may be very long, resulting in problematically huge
    file paths).
    Historically, I've used a manual implementation of SHA-256 hashing by
    Phil Fresle.  His class is very lightweight, but it has some unfortunate
    quirks (like only supporting strings, and even then, only using the
    lower byte of BSTRs, making it broken for Unicode text).  Like you'd
    expect from a native-VB implementation, the class is also quite slow
    when operating on large data.
    Rather than stick with this old-school solution, I've wanted to move to
    a more generic, performance-friendly API crypto solution, which would
    also allow for a lot more than just naive hashing.  This new pdCrypto
    class is the result.
    At present, the class is relatively minimalist, as it's really only
    covering for the old string-hashing functionality it's replacing.  But
    going forward, pdCrypto will be the backbone of all hashing tasks, and
    it will also allow for much simpler functionality of things like
    encrypted PDI or temp files.
    One unfortunate consequence of this switch is that the new,
    Unicode-compliant hash function produces different hashes from the old
    ANSI-only algorithm.  This breaks paths to existing recent file
    thumbnails.  (This proved to be a good thing, as it turned up a bug in
    PD's "purge orphaned thumbnails" function.)  Those thumbnails can be
    regenerated by loading the image in question; for performance reasons,
    PD does not refresh recent file thumbnails passively.  Sorry.  (I
    actually wrote a fallback to work around this, but it took a ton of
    unnecessary code and really cluttered up the MRU interface, so I ended
    up removing it.  The legacy capabilities are still there in pdCrypto if
    you need 'em, however.)
    committed Aug 19, 2016
  2. Fix remaining compile-time subclassing issues

    Also, harden against future errors by disallowing all subclassing
    behavior if the program isn't running.
    committed Aug 19, 2016
Commits on Aug 18, 2016
  1. File > Batch > Repair: add support for video and audio recovery

    Also lots of clean-up, optimization, and UI improvements.
    Video and audio recovery is limited to codecs currently installed on the
    host PC (otherwise we'd have to ship our own, and that's not gonna
    happen).  Also, video/audio recovery is less sophisticated than image
    recovery, but since many recovery targets will be SD cards, flash
    drives, and/or cameras, I figured it makes sense to at least try and fix
    the major formats.
    Testing against a corrupt 32 gb flash drive, I was able to recover 2,000
    valid files, mostly JPEGs and mp4 files.  Pretty neat, and a hell of a
    lot faster than checking each file manually!
    committed Aug 18, 2016
  2. pdImage handler: fix issues with circular references

    This solves a number of problematic memory leaks during batch processing
    committed Aug 18, 2016
Commits on Aug 17, 2016
  1. New File > Batch > Repair option

    After a long holiday, it's good to be back to work on PD!
    This new feature is kind of random, but hopefully useful to others.
    While on holiday, a family member used a thumb drive full of photos in a
    sketchy Internet cafe, and the drive became a corrupted mess.  He ran
    good ol' scandisk on the drive, which generated a list of generic
    "FILE0001.chk", "FILE0002.chk" type files inside a "FOUND.000" folder.
    Some of these files are valid images (mostly JPEGs).  Many are not.
    Manually testing and renaming each file would be a nightmare, and he
    asked if I could help.
    So PD now has a batch recovery tool.  File > Batch > Repair is a
    cleaned-up version of a quick script I wrote to solve his problem.  It
    allows the user to select a source folder (with or without subfolder
    recursion), then have PD test each file in the folder.  PD runs some
    basic heuristics to try and identify valid images, and if one is found,
    the file is copied to a "repaired" folder and renamed according to the
    file's actual type.
    I realize this is a pretty basic "repair" option, but in the future, it
    can always be expanded.
    committed Aug 17, 2016
Commits on Aug 4, 2016
  1. Wrap up this round of dark theme improvements

    Dialogs are now applying their theme settings prior to first display,
    which reduces most flickering when using dark themes.
    committed Aug 4, 2016
Commits on Aug 2, 2016
  1. Continued dark theme improvements

    More of the same: making sure initial dialog rendering happens *before*
    the form is visible, so we don't get nasty flicker when a dark theme is
    active (and the default window background of blinding white is swapped
    with a darker color).
    Some dialogs may require special treatment due to the way VB arbitrary
    decides to show windows (without any obvious way of trapping the show
    event, short of subclassing).  I'm looking into this.
    committed Aug 2, 2016
  2. Adjustments > Photo > Filters: total UI overhaul

    Moving to pd2D and an owner-drawn listbox removes a ton of code, and the
    list box now works better than ever!
    committed Aug 2, 2016
  3. Make changes to ExifTool's startup process

    A recent Windows Defender update causes it to do a deep scan on ExifTool
    whenever it generates its default Perl cache (see,7410.0.html).
    At present, there is no known workaround except for whitelisting
    ExifTool manually, which obviously doesn't work for PD.  The ExifTool
    developers have also contacted Microsoft to initiate an update to their
    database... we'll see if that changes anything.
    In the meantime, we can mitigate some issues by moving ExifTool's temp
    file cache out of the user's default temp folder and into our local PD
    folder.  This data is quite large (~20 mb) because Perl has to extract a
    whole runtime environment for itself, but it only needs to be extracted
    once, when PD is run for the first time.  By maintaining it locally, it
    won't get deleted by externally processes that aggressively clean the
    user's temp cache.
    committed Aug 2, 2016
Commits on Aug 1, 2016
  1. Large patch to improve dark theme behavior

    There are still a number of dialogs that need touch-up (like the Levels
    dialog, which uses some custom UI elements), but I'm now running the
    dark theme full-time locally, and gradually fixing problem spots as they
    The bulk of the work here is fixing dialog startup behavior to apply all
    themes before the dialog first hits the screen, which solves flickering
    issues when a dark theme is in use.
    committed Aug 1, 2016
  2. Update ExifTool build

    ExifTool is now built with a newer version of Perl, and I'm noticing an
    obnoxious delay at first initialization -- workarounds may be required
    if users have trouble editing metadata on first load.
    committed Aug 1, 2016
Commits on Jul 25, 2016
  1. Fix a number of memory leaks; new backend drawing features

    Large cross-patch from pd2D.  I shouldn't need to do many more of these,
    as pd2D has finally stabilized.
    committed Jul 25, 2016
Commits on Jul 13, 2016
  1. Tons of backend fixes and improvements

    Sorry for the vague commit comment; there's a lot happening in parallel
    between this and the pd2D project
    (  I'm slowly moving PD's
    rendering backend over to pd2D, which means that the same rendering
    engine will be used for the UI, paint tools, and any miscellaneous
    rendering involved in various filters and effects.
    pd2D is getting closer to a 1.0 release.  Once that happens, I can start
    dropping some long-awaited functionality into PD.  Thanks for your
    committed Jul 13, 2016
Commits on Jul 6, 2016
Commits on Jul 1, 2016
  1. Image > Straighten: large performance improvements

    pd2D makes it much easier to handle complex transformations like
    "straighten" (where multiple rotation and straighten operations are
    chained together).   I have now migrated the "Straighten" function to
    Previously, the "straighten" function had to apply rotate and scale
    functions in separate steps, for each layer, with two temporary DIB
    allocations in-between.  But no more!
    Migrating the Straighten function to pd2D yielded large speed and
    quality gains: on a 5-layer, 6 megapixel test image, processing time
    went from 21.3 seconds to 4.6 seconds - a nearly 80% reduction.  Also,
    all rotate and scale steps happen simultaneously, so only one temporary
    object is required, improving quality (by not performing two lossy
    operations) and also reducing memory requirements (because we only need
    one temp copy instead of two).  FreeImage has also been removed as a
    Gains like this is why I feel okay taking this momentary "pd2D detour" -
    there are so many benefits to using the same 2D engine throughout PD,
    instead of hand-building every operation from scratch.  By using the
    same engine to drive PD's on-canvas tools, the UI renderer, and its
    filter backends, improvements in one place are shared throughout the
    entire program.
    committed Jul 1, 2016
Commits on Jun 29, 2016
Commits on Jun 26, 2016
  1. Backport a number of pd2D feature improvements

    This includes the groundwork for the forthcoming "shape" tool, which
    will lean heavily on the vector capabilities of pd2D.
    committed Jun 26, 2016
Commits on Jun 23, 2016
  1. Continue migrating UI rendering to pd2D

    This brings significant UI performance improvements to miscellaneous
    places that were manually drawing complex features like gradients (e.g.
    PD's many colored sliders).
    Also, pd2D is now being updated in parallel against the separate pd2D
    repository (which will soon go live).  I'm not quite ready to pull in
    pd2D as its own submodule, as there are still quite a few PD-specific
    edits in modules like the GDI+ wrapper, but the goal is to eventually be
    able to rely on pd2D as a completely standalone library, with no
    PD-specific bits.
    committed Jun 23, 2016
Commits on Jun 22, 2016
  1. pd2DPath: finish (I think?) migration to new engine

    pd2DPath has finally been purged of any GDI+ specific code, and it
    should now be leak-proof (I hope; further testing still ongoing).
    I'm pretty darn close to splitting out the pd2D bits into their own
    repository, so that's exciting.
    committed Jun 22, 2016
Commits on Jun 21, 2016
  1. pd2DPath: migration to pd2D engine about halfway complete

    The class now successfully self-manages its own handle, all the
    requisite pd2D functions have been added, and all internal GDI+
    management functions have been split out into the GDI+ module.
    Still to-do is migrating the various line/shape functions to a
    backend-agnostic solution.
    committed Jun 21, 2016
  2. pd2DTransform: the latest addition to the pd2D family

    The class formerly known as pdGraphicsMatrix has been cleaned up and
    greatly expanded, and it now behaves like the rest of the pd2D library.
    Paths in particular use a lot of transform operations, so this was a
    necessary step on the way toward completing the (incredibly tedious)
    pd2DPath class.
    committed Jun 21, 2016