tannerhelland / photodemon Goto Github PK

With the recent rewrite of the viewport code, it should be relatively simple to add support for custom image borders. The plan is to include a color selector (like the current canvas background selector) in Edit -> Preferences, with support for light and dark colors based off the current system theme.

I have tested this with the newly added grayscale previewing (see b303e91 and 5218ab1) and it works very well.

This will be a massive undertaking that requires the rewrite of hundreds of functions... but the end result should be worth it as it will allow any image filter to be applied anywhere in the program - not just to the standard user interface forms. It also reduces total code size and maintenance by not requiring duplicate functions (one for previewing, one for running the actual effect).

This is also a prerequisite for an interactive macro editor capable of previewing any effect.

At present, PhotoDemon only saves to 24 or 32bpp files. It determines the proper depth automatically, based on the format being used (e.g. JPEG vs PNG) and the color-depth of the present image.

That said, the user may want to export to some other depth (such as saving a 32bpp PNG to 24bpp, which is not possible at present). The program also supports the importing of 8bpp images, so it stands to reason that there should also be a way to save those 8bpp images post-editing.

FreeImage provides mechanisms for all this, but what is needed is an interface to present the user at save-time. For some formats (such as JPEG) this is irrelevant, but for others it makes sense.

Most users won't give a shit about color depth, as they'll be using PhotoDemon for its intended purpose - photos - so there should be a preference for this, namely: "when saving, prompt for desired color depth" vs "always save to original color depth" vs "save non-alpha images to 24bpp, and alpha images to 32bpp".

PhotoDemon uses an older version of the grayscale conversion algorithms in this article:

http://www.tannerhelland.com/3643/grayscale-image-algorithm-vb6/

The UI needs an overhaul to support some of the new features.

It bloats the repo history, of which you have limited storage space on github, and it makes things hard for those submitting patches / pull requests &c. because I don't know if I should be including a freshly compiled exe or not and it greatly confuses matters when it comes to branches / merging.

This will also require some re-engineering to make sure that options are only set when OK or Apply is pressed, and that Cancel ignores all changes from that session.

Per the suggestion from PSC user Achmad - "I suggest you add function to duplicate the image. I usually make a duplicate and work with them, so that the original image intact."

Per Herman:

"-- Run program

-- Load an invalid GIF (or other invalid file) Program would flag a msg.

-- Click "X" at top right screen to leave program.

-- Program would flag a save prompt and the "Save" button is lit up,
though no file is loaded there."

As a sort of "quick list" feature for Macros. The problem with this solution is if the user decides to create TONS of macros... in that case it would be nice to do the last 10 or something, but that's a bit messier to code.

For now, let's just go with the entire contents of the folder.

Not sure what the intended behaviour is supposed to be. Currently, when menus are disabled, no menu icon appears, except when hovering the mouse over the menu, where upon it appears ghosted.

To make it easier to start a selection from a corner, it should be possible to begin drawing the selection from outside the image. Clicking and dragging inwards from outside the image should begin the selection in the nearest corner.

This is especially obnoxious when the program is first loaded, as the whole interface will seize and Windows will gray out the main window as if the program has frozen. This is a problem with the wininet.dll functions I'm using... but there must be a way to either perform the check asynchronously (messy in VB) or to set an automatic timeout of a few seconds.

At present, PhotoDemon defaults the file format of the Save dialog to whatever format you saved last. This is my preferred behavior, as I tend to work exclusively with JPEG files, and I want to save everything as JPEGs.

For other users, this may not be the case. So there should be an option for the Save common dialog to automatically select either:

1. the last-used save format
2. the format of the image-to-be-saved

Rectangular selections come first. Once that full framework is in place, other selection tools can be added.

At present, image loading is deeply integrated with the creation of a new MDI child form. This was intentional - images are only loaded as part of the primary interface, and it takes a lot of work to get an image on-screen and ready for editing.

Unfortunately, this tight integration has hampered the development of other features, including an "image preview" in the planned batch conversion wizard. One solution is to use the current code but render each image to an invisible MDI child as necessary. I don't like this solution - it's hackish, and overkill, because most of the UI integration is unnecessary if all we need to do is get an image loaded into memory.

So my proposal is to rewrite each format-specific load routine to be independent of a destination picture box. The current PreLoadImage routine will need to be modified to request rendering to FormMain.ActiveForm. A new routine will need to be built that mimicks the format detection capabilities of PreLoadImage, but then requests loading to an invisible picture box. That box could then be used to populate a batch conversion preview or even an image browser.

Right now, PhotoDemon's software processor deals only in numerical constants. It has no way of knowing that process command #416 is "Gaussian Blur", for example. The plan is to implement a "GetNameOfProcess" function; pass it the numerical constant of a Process call, and it returns a string describing that action. That string could then be used to populate all sorts of things - like the Undo/Redo/Repeat Last Action/Fade Last Filter commands.

Note that this feature is a prerequisite for the planned visual macro editor.

Proposed solution: track window state in pdImages(). When leaving .Maximized, call PrepareViewport on all windows. (This is especially important if the images were loaded in the .Maximized state, as the new window size assigned to them by VB is likely to be too small for the viewport size.)

You cannot drag file(s) from explorer and drop them into PhotoDemon.
There is a way to receive drop handlers in VB, but I've never used them myself.

To test: load one image. Maximize the form. Load many images. Leave maximized state.

I thought I was tracking this already (via pdImages), but it must be getting missed or ignored under certain conditions. Further investigation needed.

Equalization is more useful when you can see the results. A new form will allow for previewing.

Similar to how Undo and Redo currently work.

Per Herman:

"I have a series of small 32 BPP files of various file formats, used
to test the effectiveness of a program on loading 32 BPP files. I
use these files because more often than not the ordinary ones do not
easily reflect the defect, if any, of the program [because (i) defect
is hidden in a black ground used and/or (ii) the alpha is not strong
enough as to be seen with naked eyes]. Attached are two of such
"Test32x32x32" files which I use, one is PNG and the other TIFF.

In PhotoDemon, you wouldn't see the alpha effects of the said files
when you load them, this means the program is not quite yet in
handling 32BPP stuff. (However, if you test them on my
FreeImageTest, you would see the alpha effect clearly)."

PhotoDemon has a fairly robust central error handler. I'd like to link that error handler to this issues page, so if an error does occur the user is only two clicks away from submitting an issue report. A link in the "Help" menu would also be appropriate IMO.

When there are no documents loaded the Window menu has enabled a number of items that do not apply, and should be disabled:

• Arrange Icons
• Cascade
• Tile Horizontally
• Tile Vertically
• Minimise all Windows
• Restore all Windows

Right now, batch conversion always assumes that the user wants to convert mixed-format lists to a single destination format. This may not always be the case. In the current save options, there needs to be a "use original format" option.

Per Herman:

"...if you set screen DPI to 120, the image on the Splash and on the About
screens will dislocate, per screenshot attached."

For some reason, intrinsic VB accelerators (like Ctrl+O or Ctrl+S) fail to fire at unpredictable times. It makes sense to have all hotkeys on the same system, so all intrinsic hotkeys should be moved over to the user control.

Per Herman:

"In Alfred Koppold's project (attached), if I change "On Error Resume
Next" in "Sub SortPlans" of LoadPCX.cls to "On Error Goto
allesfertig", then the crash on loading the file which Robert sent you
(being resent here) is avoided."

Per RR on PSC:

"Failed to load large jpeg 3408x4960 even though it said it was loaded but comes out all white."

I'm already generating these icons for use on the MDI child forms - so why not save them and use them in the Recent Files list? I'd need a place to save the icon files, but the current icon-to-menu code should work just fine...

1. Automatically change selection to "highlight" mode when "select all" is used
2. Automatically clear selection after Crop-to-Selection is applied

Right now, image resizing only works on fixed image sizes. It has no respect for aspect ratios - for example, if you tell it to convert a set of photographs to 800x600, it will force all images to that regardless of whether they're in portrait or landscape mode. This is how most image resize tools work - and it's not incorrect - but macros require something more nuanced.

The current plan is a "smart resize" that compares an image's aspect ratio to the requested size, and automatically determines whether the user means (for example) 800x600 or 600x800. This will allow for conversion of photographs from mixed aspect ratios.

Additionally, it might be nice for the smart resize to offer some standard image sizes for the user to choose from, alongside custom size text boxes.

Finally, while recording macros it would be nice to warn the user that "smart resize" is more appropriate then just "image resize." (This may not appear in the initial implementation.)

Child form icons should be a miniature version of the current image.

Implementing this requires some caution - in theory, the icon should update whenever 1) an image is loaded 2) Undo is created (because that means the image is changing in some way, right?) 3) Undo is clicked.

Also, I haven't made up my mind as to whether or not the main PhotoDemon title bar (and/or the start bar icon) should also be updated with the active image. Right now I'm leaning toward updating the child form's icon only, though I'm open to outside input.

Per Herman:

"Attached is a PNG which is an animated PNG (as you know, animated PNG can be
displayed as a normal single frame PNG or a series of PNG frames).

I found that PhotoDemon does not seem to show a correct image of this
file, despite FreeImage is capable of displaying it correctly (you can
test it usng the FreeImageTest project which I sent you in my previous
mail)."

Import menu - if eztw32.dll isn't found, PhotoDemon automatically disables the scanner option (as it should). But because the menu icons are generated programmatically, this misaligns the import menu icons.

I wrote a real-time curves dialog several years ago:

http://www.tannerhelland.com/336/image-curves-vb6/

...but have yet to import it to PhotoDemon.

Namely:

1. Resize should resize the selection to match the new image
2. Rotation should also rotate the selection
3. Flip / Mirror should Flip / Mirror the selection
4. Isometric... can just remove the selection. There's not a good way to make that happen until pixmap selections are implemented.
5. Duplicate should duplicate the selection as well.

Color reduction is another problem. Manual color reduction obeys the selection, but automatic does not. This needs to be changed - but it present a problem for 32bpp images, because the transformation will only return 24bpp data. So... I think we'll need to make a temporary copy of the alpha data, reduce the colors, merge the alpha data back in, then apply the selection.

Or, just force color reduction to operate on the whole image.

When you move your mouse over the image, and then out in to the background, the coords remain at the last location. Perhaps they should disappear, when the mouse is not over the image.

I don't like "you haven't saved this image" prompts, but if others are going to use PhotoDemon, it probably needs this option. Implementing a .HasBeenSaved property and checking it upon image and/or program close should be trivial; the Undo handler already tracks this as part of enabling/disabling the Undo/Redo buttons, so I should be able to tap into that.

The current plan for the unused space on the left-hand bar is to dynamically populate it with buttons for the user's most-used commands. This isn't especially difficult to implement, since PhotoDemon can track commands through its software processor. The problem is storing this information in a safe, private way. Key features include:

• There has to be a way to turn on/off the feature, and to clear any existing data
• Per PhotoDemon's portability requirements, all command tracking needs to be done in the INI. This could get messy quickly, as there are a LOT of commands.
• Does it make sense to populate the INI dynamically as commands are used...? This would mean a smaller INI size, but it will also require some unique code to read from the INI file (since the current functions assume that Get requests always exist).
• For performance reasons, it would be better to track the most-used commands in their own array, rather than scanning the full list of commands every time the program is loaded.
• Regardless of the tracking system, a sorting algorithm will be needed to sort commands from most- to least-used.

Right now, the checkerboard pattern is determined by the image's source size - not the destination size - which means that certain conditions (zooming in, previews) shows different sizes of checkerboard.

I need a system for preventing this.

Strangely, converting to 24bpp in advance doesn't seem to help. Need to track down why.

I am using Windows 7 with the classic (Windows 2K-like) desktop theme.
The status bar shows with a white background, but when applying effects, the progress is also white (so not visible, except when covering over the status text)

Per RR on PSC:

"Minor Quibble- if I don't allow the connection to your website it hangs in the IDE or gives RTE 13(Type mismatch) for the EXE file."

When an image is maximised, the "Fit Viewport Around Image" function is undefined. It should either be disabled (because it is no use when maximised), or should first restore the window (unmaximise), then fit it to size.

...this is going to take awhile, but it needs to be done.