Blender Kitsu: Incorrect end frame information push to kistu database #162

Open
opened 2023-11-17 17:14:14 +01:00 by Corrado Piscitelli · 11 comments

When pushing sequence data from a metastrip to kitsu the addon uses 3 timeline values:
shot start
shot end
shot duration

The shot start and shot duration values are correctly pushed to kitsu, while the shot end is always 1 frame more than it should be.

This issue becomes more clear if you have 2 consecutive shots and look at blender's VSE.
The first shot starts at frame 1, the second one starts at frame 100.
In Blender's VSE it might seem that the first shot ends at frame 100, but it actually ends at frame 99.

vse_screenshot.png

As you can see, blender correctly displays the shot duration of 99 frames.

When pushing to kitsu you get this:

kitsu_screenshot.png
As you can see frame start and duration are correct, while frame end of both shots is 1 frame more that it should.

For what it's worth, I saw that other parts of the addon tend to use shot duration and generally ignore shot frame end parameters for shot builder, so this is probably why this wasn't an issue. The same can be said for kitsu's internal statistics, however that is still an incorrect information that should be stored correctly.

I have included an example file
kitsu_test_frames.blend

When pushing sequence data from a metastrip to kitsu the addon uses 3 timeline values: shot start shot end shot duration The shot start and shot duration values are correctly pushed to kitsu, while the shot end is always 1 frame more than it should be. This issue becomes more clear if you have 2 consecutive shots and look at blender's VSE. The first shot starts at frame 1, the second one starts at frame 100. In Blender's VSE it might seem that the first shot ends at frame 100, but it actually ends at frame 99. ![vse_screenshot.png](/attachments/e63dcfa3-645b-4ca0-abd6-90cf7d772e10) As you can see, blender correctly displays the shot duration of 99 frames. When pushing to kitsu you get this: ![kitsu_screenshot.png](/attachments/33645706-27e5-45d0-bb53-914d864f3a82) As you can see frame start and duration are correct, while frame end of both shots is 1 frame more that it should. For what it's worth, I saw that other parts of the addon tend to use shot duration and generally ignore shot frame end parameters for shot builder, so this is probably why this wasn't an issue. The same can be said for kitsu's internal statistics, however that is still an incorrect information that should be stored correctly. I have included an example file [kitsu_test_frames.blend](/attachments/553182fe-0c98-499a-9f5d-99340ad3b37f)
Corrado Piscitelli changed title from Incorrect end frame information push to kistu database to Blender Kitsu: Incorrect end frame information push to kistu database 2023-11-17 17:16:17 +01:00
Nick Alberelli added the
Kind
Bug
Kind: Community
labels 2023-11-17 17:19:00 +01:00
Member

Hello @CorradoPiscitelli

Thank you for your report, I am looking into the issue now. I will note that this appears to be how Blender's VSE reports the frame end.

So a clip that has 99 Frames, starting on frame 1 reports it's end frame as 100 per the VSE's logic, it's not a bug in the Blender Kitsu Add-On.

Now that I look into this further, it also appears that other video editing software like Davinci Resolve also report the Frame Out the same as how Blender reports it, meaning it is 1 frame beyond the final Frame, I will confirm with the team but it appears that this isn't a bug and is intended to be consistent with the conventions most Video Editors/Production Houses use.

image

Hello @CorradoPiscitelli Thank you for your report, I am looking into the issue now. I will note that this appears to be how Blender's VSE reports the frame end. So a clip that has 99 Frames, starting on frame 1 reports it's end frame as 100 per the VSE's logic, it's not a bug in the Blender Kitsu Add-On. Now that I look into this further, it also appears that other video editing software like Davinci Resolve also report the Frame Out the same as how Blender reports it, meaning it is 1 frame beyond the final Frame, I will confirm with the team but it appears that this isn't a bug and is intended to be consistent with the conventions most Video Editors/Production Houses use. ![image](/attachments/2ac650f1-eb3d-488d-8b15-19af99d43c92)
110 KiB
Member

Hello @CorradoPiscitelli

After checking with the team I can confirm that this is not a bug and is intended. The End frame of a clip displayed in Kitsu, matches the End Frame Blender shows in the VSE and this is an industry standard consistent with other common editing applications.

Hello @CorradoPiscitelli After checking with the team I can confirm that this is not a bug and is intended. The End frame of a clip displayed in Kitsu, matches the End Frame Blender shows in the VSE and this is an industry standard consistent with other common editing applications.

Hi @TinyNick , thank you for looking into this.

I understand this position, however, kitsu itself doesn't treat this information this way.

You can see this by trying to manually input a frame start and a frame end on kitsu and letting kitsu do its calculations.

how blender kitsu addon inputs these values:
Screenshot 2023-11-21 alle 16.24.39.png

versus how kitsu handles this information if you input manually:
Screenshot 2023-11-21 alle 16.24.59.png

This is because Kitsu is not an editing software, it's a "management one", this means that the frame start and frame end are there to make calculations on "how many frames I have to render", not how my software should interpret those informations.

So, what I'm trying to say here, is that from a "management" standpoint this is an incorrectly stored information, and it should be evaluated (and adapted accordingly) by blender and not on the database.

Hi @TinyNick , thank you for looking into this. I understand this position, however, kitsu itself doesn't treat this information this way. You can see this by trying to manually input a frame start and a frame end on kitsu and letting kitsu do its calculations. how blender kitsu addon inputs these values: ![Screenshot 2023-11-21 alle 16.24.39.png](/attachments/a30a9e55-b1c4-4603-857b-f7f535d242c0) versus how kitsu handles this information if you input manually: ![Screenshot 2023-11-21 alle 16.24.59.png](/attachments/33111490-c2f0-48cb-bda5-8a7c7654f45e) This is because Kitsu is not an editing software, it's a "management one", this means that the frame start and frame end are there to make calculations on "how many frames I have to render", not how my software should interpret those informations. So, what I'm trying to say here, is that from a "management" standpoint this is an incorrectly stored information, and it should be evaluated (and adapted accordingly) by blender and not on the database.
Member

Hey @CorradoPiscitelli

I don't understand the point about how Kitsu handles the data. In my experince when using Kitsu, you can input the 'Shot In' 'Shot Out' and 'Shot Frames' values can all be set manually, and there is no automatic calculation done by Kitsu.

Example of Manual Kitsu Shot Data Input

Because the input is manual you can set each value arbitrarily without relation to the other values. What is the case where kitsu handles this information differently then how Blender's VSE does? Is there a shot input method where kitsu automatically calulates the End frame or Duration?

Hey @CorradoPiscitelli I don't understand the point about how Kitsu handles the data. In my experince when using Kitsu, you can input the 'Shot In' 'Shot Out' and 'Shot Frames' values can all be set manually, and there is no automatic calculation done by Kitsu. ### Example of Manual Kitsu Shot Data Input <video src="/attachments/d5af4b34-80d1-4da5-b6a1-a134da3fe52b" title="2023-11-21 10-46-10.mp4" controls></video> Because the input is manual you can set each value arbitrarily without relation to the other values. What is the case where kitsu handles this information differently then how Blender's VSE does? Is there a shot input method where kitsu automatically calulates the End frame or Duration?
Member

Ok I now found the case where Kitsu does this automatic calculation. I will look into this more, but it may be a bug in Kitsu that we need to report to CGWire guys.

Ok I now found the case where Kitsu does this automatic calculation. I will look into this more, but it may be a bug in Kitsu that we need to report to CGWire guys. <video src="/attachments/631b01ce-f36a-483d-b655-3ec4f6d6d487" title="2023-11-21 10-56-10.mp4" controls></video>

Kitsu can and does this calculation automatically (with no way to disable it), I've made a short video to show it

So, what I'm trying to say is that I understand that if you don't touch those values, kitsu treats them as independent values.
But I still consider them as "faulty" information.
And I think that everything in blender, except for the VSE treats this information differently.

For example, as I undestand how the shot builder works, (please, correct me if I'm wrong) if you create a shot using the information the addon stored on kitsu, it creates a file starting at a certain frame (using the pre-roll value and not the actual frame start) and it sets the end frame by adding the shot duration taken from kitsu.

This means that if I have a shot starting at frame 101 and ending at frame 200 (99 frame duration) on kitsu (info pushed by the addon and not manually) and I recreate it on blender using the blender-kitsu addon, by, lets say, using 100 frames of preroll, thus starting actually at frame 101, I will have a shot starting at frame 101 and ending at frame 199 (99 frame duration).

So, I understand why you chose to store it that way, from a "blender studio" oriented standpoint, but I don't think this is a VSE oriented information, and should be more "universal", letting the addon translate this information by adding that one frame if there is a duration mismatch in the vse.

Kitsu can and does this calculation automatically (with no way to disable it), I've made a short video to show it <video src="/attachments/84c9fef7-2c78-410e-bd25-df8255359ee8" title="Registrazione schermo 2023-11-21 alle 16.52.20.mov" controls></video> So, what I'm trying to say is that I understand that if you don't touch those values, kitsu treats them as independent values. But I still consider them as "faulty" information. And I think that everything in blender, except for the VSE treats this information differently. For example, as I undestand how the shot builder works, (please, correct me if I'm wrong) if you create a shot using the information the addon stored on kitsu, it creates a file starting at a certain frame (using the pre-roll value and not the actual frame start) and it sets the end frame by adding the shot duration taken from kitsu. This means that if I have a shot starting at frame 101 and ending at frame 200 (99 frame duration) on kitsu (info pushed by the addon and not manually) and I recreate it on blender using the blender-kitsu addon, by, lets say, using 100 frames of preroll, thus starting actually at frame 101, I will have a shot starting at frame 101 and ending at frame 199 (99 frame duration). So, I understand why you chose to store it that way, from a "blender studio" oriented standpoint, but I don't think this is a VSE oriented information, and should be more "universal", letting the addon translate this information by adding that one frame if there is a duration mismatch in the vse.
Member

Hey @CorradoPiscitelli

So this appears to be a matter of perspectives, Kitsu server in theory supports both methods, there is now some discussion on if this should be an option exposed in Kitsu when calculating duration on the shots page.

Counting non-inclusively for video

If you import that video into Blender's VSE it will appear in Blender's VSE as a 2 Frame video, but now it will be described as IN:1 OUT:3 with DURATION:2. This is because in Video Editing the OUT frame is the frame where that strip no longer appears (how most video editors work)

Counting inclusively for animation

If you have a Blender Animation that is IN:1 OUT:2 DURATION:2 then the video will last 2 frames because when rendering an animation out of Blender we hold the last frame and render it (how most animation works)

At the Blender Studio we count using the frame duration of the rendered video (non-inclusively), and that is what we report to Kitsu, that is why this data is not faulty or incorrect. It is a matter of perspective, but I do appreciate your input.

Fence Post Error

What we are seeing here is this problem called the Fence Post Error. To learn more about this topic see this wiki article

  • Counting the posts is how Video Clips in/out are counted in video (non-inclusively)
  • Counting the sections between the posts are how in/out for animation is counted (inclusively)

image

Hey @CorradoPiscitelli So this appears to be a matter of perspectives, Kitsu server in theory supports both methods, there is now some discussion on if this should be an option exposed in Kitsu when calculating duration on the shots page. ### Counting non-inclusively for video If you import that video into Blender's VSE it will appear in Blender's VSE as a 2 Frame video, but now it will be described as IN:1 OUT:3 with DURATION:2. This is because in Video Editing the OUT frame is the frame where that strip no longer appears (how most video editors work) ### Counting inclusively for animation If you have a Blender Animation that is IN:1 OUT:2 DURATION:2 then the video will last 2 frames because when rendering an animation out of Blender we hold the last frame and render it (how most animation works) At the Blender Studio we count using the frame duration of the rendered video (non-inclusively), and that is what we report to Kitsu, that is why this data is not faulty or incorrect. It is a matter of perspective, but I do appreciate your input. ## Fence Post Error What we are seeing here is this problem called the Fence Post Error. To learn more about this topic see [this wiki article](https://en.wikipedia.org/wiki/Off-by-one_error#:~:text=the%20problem%20domain.-,Fencepost%20error,-%5Bedit%5D]https://en.wikipedia.org/wiki/Off-by-one_error#:~:text=the%20problem%20domain.-,Fencepost%20error,-%5Bedit%5D "https://en.wikipedia.org/wiki/Off-by-one_error#:~:text=the%20problem%20domain.-,Fencepost%20error,-%5Bedit%5D") - Counting the posts is how Video Clips in/out are counted in video (non-inclusively) - Counting the sections between the posts are how in/out for animation is counted (inclusively) ![image](/attachments/81407d4f-5bf9-491c-9523-47a609cc0ffd)

Thank you again for the time you spent on this.

As I said before, I completely understand why it is used this way in your production pipeline, however I think not every production has the same needs, so it would be nice to expose this option as a flag in the addon preferences.

Something like this so that it can be accessed only in advanced preferences and basically leave everithing like it is now
Screenshot 2023-11-22 alle 12.06.48.png

but giving the user the option to decide if they want the data to be pushed to kitsu non-inclusively or inclusively.

Thank you again for the time you spent on this. As I said before, I completely understand why it is used this way in your production pipeline, however I think not every production has the same needs, so it would be nice to expose this option as a flag in the addon preferences. Something like this so that it can be accessed only in advanced preferences and basically leave everithing like it is now ![Screenshot 2023-11-22 alle 12.06.48.png](/attachments/a8a11ce8-98b9-42a7-8fa1-3d7205b140a6) but giving the user the option to decide if they want the data to be pushed to kitsu non-inclusively or inclusively.
Nick Alberelli added
Kind
Feature
and removed
Kind
Bug
labels 2023-11-22 16:21:01 +01:00
Member

Firstly this is a good suggestion to consider, I appreciate you taking the time to discuss this with me.

My concern with the feature, is that this property; if stored at the add-on level, means its actually set on a per users basis. Introducing the risk of mulitple people on the same production push/pulling conflicting frame ranges.

If I am able to get approval to include the feature from the stakeholders then I need to sort that out first so it's configured on a per production basis instead of a per user basis

Firstly this is a good suggestion to consider, I appreciate you taking the time to discuss this with me. My concern with the feature, is that this property; if stored at the add-on level, means its actually set on a per users basis. Introducing the risk of mulitple people on the same production push/pulling conflicting frame ranges. **_If_** I am able to get approval to include the feature from the stakeholders then I need to sort that out first so it's configured on a per production basis instead of a per user basis

While, as far as I recall, only users with "production manager" or "studio manager" credentials should be able to create new shots on kitsu, narrowing this kind of issue a little, I think your take on this is spot on.

This should be a project property on the kitsu database and the blender kitsu addon should interact accordingly to that.

While, as far as I recall, only users with "production manager" or "studio manager" credentials should be able to create new shots on kitsu, narrowing this kind of issue a little, I think your take on this is spot on. This should be a project property on the kitsu database and the blender kitsu addon should interact accordingly to that.
Member

Sorry for the large delay in reply, I am leaving this response here for posterity.

In the future we could consider adding a feature that allows for non-inclusive counting, I was able to get a response from the decision maker @fsiddi here at Blender and for now we are not going to take action on this. We will leave this issue open and feel free to add additional comments/details but for now we are not developing a solution for this. PRs are also welcome. But it is a known issue that Blender Studio should address. Ideally we could store both values in kitsu metadata, inclusively and non-inclusively.

Thank you for reporting.

Sorry for the large delay in reply, I am leaving this response here for posterity. In the future we could consider adding a feature that allows for non-inclusive counting, I was able to get a response from the decision maker @fsiddi here at Blender and for now we are not going to take action on this. We will leave this issue open and feel free to add additional comments/details but for now we are not developing a solution for this. PRs are also welcome. But it is a known issue that Blender Studio should address. Ideally we could store both values in kitsu metadata, inclusively and non-inclusively. Thank you for reporting.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: studio/blender-studio-tools#162
No description provided.