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

[Bug] Partial Export 'Expression' Ignores Custom Frame Order, Affecting Thumbnail Selection #1367

Open
wenual opened this issue Jan 26, 2025 · 1 comment
Assignees
Labels
🔷 Bug 🐛 Type • An undesired situation happens. ⬜ Pending Status • This issue stills needs to be analyzed.

Comments

@wenual
Copy link

wenual commented Jan 26, 2025

Describe the bug
When the "Export partially" option is selected during the save process, the custom frame order provided in the "Expression" field is ignored. For example, an input such as 50-100,0-49 is rendered sequentially as 0-100, disregarding the specified swapped order.

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'Save as'
  2. Click on 'Export partially'
  3. Scroll down to 'Partial export'
  4. Select 'Expression' under the dropdown menu
  5. Type a custom frame order, e.g., 50-100,0-49
  6. Click on Save
  7. Observe that the output GIF renders sequentially (0-100), ignoring the custom frame order.

Expected behavior
The exported GIF should respect the custom frame order specified in the "Expression" field. For example:

  • Start with frame 50
  • End with frame 49
  • Jump in the middle as specified

This behavior is especially important when the thumbnail (derived from the first frame of the GIF) should represent a visually appealing frame located later in the sequence.

Desktop (please complete the following information):

  • OS: [e.g. Windows 10 PRO]
  • Version: [e.g. 2.41.1]

Additional context
This feature is important for workflows where the thumbnail of a GIF (derived from the first frame) should represent a visually appealing frame located later in the sequence.

Attempts to reproduce this behavior using custom FFmpeg parameters have shown that frames are united in sequential order regardless of the input, potentially overridden by ScreenToGif.

My ffmpeg param for example:

-vsync passthrough 
{I} 
-loop 0 
-lavfi "select='between(n\,1319\,1346)+between(n\,1300\,1318)',setpts=N/FRAME_RATE/TB,scale=1000:-1,split[scaled][palette];[palette]palettegen=stats_mode=diff:max_colors=256[pal];[scaled][pal]paletteuse=new=1:dither=floyd_steinberg:diff_mode=rectangle,fps=24" 
-f gif 
{O}
@wenual wenual added ⬜ Pending Status • This issue stills needs to be analyzed. 🔷 Bug 🐛 Type • An undesired situation happens. labels Jan 26, 2025
@wenual wenual closed this as not planned Won't fix, can't repro, duplicate, stale Jan 26, 2025
@wenual
Copy link
Author

wenual commented Jan 26, 2025

The workaround could be implemented in various ways, potentially offering better flexibility than directly fixing this bug. For example:

  1. Option to select a split frame: Allow users to define a specific point where the sequence is divided.
  2. Option to select a specific frame for the thumbnail: Enable users to choose a specific frame to be copied and used as the first frame, ensuring the desired thumbnail is delivered.

@wenual wenual reopened this Jan 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔷 Bug 🐛 Type • An undesired situation happens. ⬜ Pending Status • This issue stills needs to be analyzed.
Projects
None yet
Development

No branches or pull requests

2 participants