Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Working with PSD's too destructive #654

Closed
daledesilva opened this issue Sep 13, 2017 · 9 comments
Closed

Working with PSD's too destructive #654

daledesilva opened this issue Sep 13, 2017 · 9 comments
Assignees

Comments

@daledesilva
Copy link

If you click the export to PSD button it creates a PSD with a separate layer for notes, main, and reference. If you save that PSD it automatically updates in storyboarder (merging any new layers down into the main layer in storyboarder).
There are two issues though:

  • If you close either of the programs the live link is lost, which means that even though the psd still exists with all your layers, it's useless if you want to do more edits.
  • If you do try and jump back into photoshop by clicking the "edit in photoshop" button, without warning it will overwrite your PSD file.

Suggestions:

  • At the very least, it should warn you that it's going to delete an existing PSD.
  • If storyboarder can read and write PSD's, why is it's native file format png? - why not just use PSD's so jumping between programs would have no loss and a default live connection?

I'm on Windows 10.

@SafariMonkey
Copy link

SafariMonkey commented Sep 13, 2017

Regarding your last point, does it really make sense to use .psd (a closed format) as the native format for a piece of open source software? I understand that it would make interoperability with Photoshop easier, but it could be at the expense of extensibility, as well as interoperability with other (open and closed source) software.

@CuberToy
Copy link

And I would also add that some storyboarder don't use .psd in the first place and could do the whole work right in Storyboarder. And I really think it's the core of Storyboarder, being this simple tool to just draw, one panel at a time, without going back and forth between softwares and tool (as it can be useless). Then .psd would be unusable for them in a sense.

@Banbury
Copy link

Banbury commented Sep 13, 2017

I'm agreeing with @daledesilva. I'm trying to get support for OpenRaster into Storyboarder. This is, as the name says, an open format and would be ideal to replace the mess of PNGs.
The use of PSD or OpenRaster wouldn't force the user to use an external program. Storyboarder already can read and write PSD. So why use PNG?

@setpixel
Copy link
Collaborator

@daledesilva 👍

We need to associate the board with the PSD file.

@daledesilva
Copy link
Author

@SafariMonkey
That it's a closed format is certainly something to consider, but simply using png's provides no additional functionality in any program and using any format, open or closed, still limits usability to programs that have implemented that format.
As @Banbury mentioned, the format used doesn't affect use within Storyboarder, so it's all about added functionality when working externally while preserving backward compatibility into Storyboarder.
Since any app can implement PSD read/write, I don't see the issue as being whether the format is open or closed, but rather, which format adds functionality and is more widely supported by other apps.

@SafariMonkey
Copy link

simply using png's provides no additional functionality in any program

I would disagree here. If you simply have PNG images, those can easily be imported (programatically or manually) into most software that deals with images. PSD can only be opened by software that has implemented specific support for it, which is a more limited set.

However, if Storyboarder plans to use features of PSD, I can certainly see the appeal. My preference would be to use OpenRaster natively and support PSD import/export, but the inverse would also be acceptable. PNG export would also be nice.

I just think it would be a bit strange to use PSD as the primary (or even only!) supported format. A bit like if Blender used .3ds or .fbx as its native format.

@daledesilva
Copy link
Author

That's a good point @SafariMonkey
It's kind of a balancing act between the wider compatibility of png's vs the increased functionality of a layered file.
From discussions in #655 , though, the devs aren't wanting the PNG's in the images folder to be relied on in external programs - they'd prefer users focussed on exporting for that. So I'm not sure the wider compatibility of png's matters in this instance.

Regardless of what the format is, If the export to PSD function was able to maintain a reliable link (like it almost does - until you close either app), we'd have the best of PSD bidirectional compatibility as well as whatever format they went with.
ie. native might be Open Raster but once you click "convert to PSD" than that storyboard frame is now linked to the PSD instead - kind of a choose the format you want I guess.

@Banbury
Copy link

Banbury commented Sep 15, 2017

@SafariMonkey You can still export to PNG. So there isn't really a problem.

@audionerd
Copy link
Member

audionerd commented Sep 21, 2017

Here's our current plan:

  • Storyboarder should know what source is linked per board (e.g.: file path to PSD)
  • cleanup tasks shouldn't delete PSD files if they are actively linked
  • If artist begins to draw on a linked board (pointerdown), warn first about link being broken.
  • If artist continues drawing, remove linkage in board JSON, PSD file remains on filesystem until cleanup task is run.

Also, as a fix for this issue:

If you do try and jump back into photoshop by clicking the "edit in photoshop" button, without warning it will overwrite your PSD file.

  • If "link" is already present, don't overwrite the PSD, just open Photoshop with existing
  • If "link" is not present, write the PSD and open Photoshop (current behavior)

@audionerd audionerd self-assigned this Sep 21, 2017
@audionerd audionerd moved this from Beta 13 to IN PROGRESS in Features for RC1 Sep 21, 2017
@audionerd audionerd moved this from IN PROGRESS to DONE in Features for RC1 Sep 26, 2017
@audionerd audionerd removed this from DONE in Features for RC1 Oct 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants