Relational modeled design to store versioned files
Your Altered_Files design is absolutely fine.  In fact I would award bonus points for separating the files per se from the hierarchy.  @chillworld's suggestion is workable and very common but yours is better because of the NULL issues you mention.  I can't think of any update which is better in one schema or the other.  Change a single row - either the file data or the files' relationship - and you have a single update on a single table.  No risk to integrity there.  Altered_files contains only primary keys (PK) and pointers to PKs.  By definition these should never change.  On the off chance you should have to change one then, yes, you have to be very, very careful to maintain consistency.  For INSERTs and DELETEs wrap the statements in a transaction.  This is precisely why transactions exist.

I would suggest you store the full directory path for an altered image, not just its new sub-folder.  What happens if you derive image 4 from image 3, from image2, from image 1?  Will contact('-') handle that?  Will the continuous constructing of image 4's ancestry be a burden on the system?  You know your data, workflow and hardware best.  If the volumes are small this may not be an issue.

The file-in-database-or folder is an age-old one.  SQL Server has functionality called FILESTREAM where the image passes through the database on the way to the file system.  It is held on disk as a JPG or PNG or whatever and can be read by normal applications.  The database retains ownership of it and its related data.  The best of both worlds.  I don't think MySQL has anything similar, however.  I think you may want to grant other applications read access to the image filestore and reserve write access for the DB.