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

Ability to use the current mask but "inverted" #221

Open
QuietMonkey opened this issue Nov 16, 2022 · 4 comments
Open

Ability to use the current mask but "inverted" #221

QuietMonkey opened this issue Nov 16, 2022 · 4 comments

Comments

@QuietMonkey
Copy link

Mode

Storybook

Feature description

Use Case: Same type of use as the current mask but "reversed".

In a capture of a storybook component or a page I want to be able to isolate only the element on which I perform the visual non-regression test. Ideally by cropping everything that is outside the selector given in the config.
This would allow to compare only what is necessary to compare, and thus to gain in performance by limiting the writing and the comparison of the pixels which do not interest us, to limit the false positives, to have a finer adjustment of the threshold and to move less data each time we push or pull.

As I tend to try to have the screenshots unified in their size. I'd find this solution more elegant than having the same size for every component screenshots. Some component have a width of 200px, others have a width of 1080px, I don't think it makes sense to use the same viewport for everyone.

@chriskalmar
Copy link
Collaborator

This is an interesting use case for masks.
We do have element shots on our Roadmap, which will allow you to use the selector the same way as for the mask to define an element that will be used for the screenshot.
It would be more efficient as it would need the whole masked area to be part of the image.
Would this be a viable option for you?

@QuietMonkey
Copy link
Author

The elements shots as you describe them seems to be exactly what I originally had in mind!
With this kind of tool I'll be able to create container component with a fixed size and unique selector that I could use to wrap any component from my storybook, and set this only class as my element shot selector in lost-pixel config file or have a perfect shot of the component only.

English is not my native language and I'm not sure what you mean by It would be more efficient as it would need the whole masked area to be part of the image. though.

And this raises an additional question for me: do lost-pixel makes any kind of resize or treatment on screenshots before doing the pixel comparison? If so wouldn't it be dangerous to use an element shot? As if the whole element change from 200px width to 300px while keeping the exact same ratio, if resized to compare images they will match almost perfectly, or within the threshold, and therefore will not raise any error?

And sorry for the long message but while I'm on it about threshold param and the reliability of comparisons, do you intend to add some others params for this purposes? (Ability to ignore antialiasing, ignore colors, set our own diff colors and transparency, those kind of things)

@chriskalmar
Copy link
Collaborator

Great, we will try to ship this feature as soon as possible.

No worries, your English is great!
Let me just explain with a drawing. Let's assume there's a component (green area) within a full page (blue area):
image
With a mask, you would take a full screenshot (the size of the page, e.g. 800x600) where the blue area is covered in pink color.
Only the component would be visible.

With element shots, only the component itself (e.g. 100x50) will be used for the screenshot. There's no mask, just the component that you target.

Now the efficiency is in regards to having to take a screenshot of 800x600 versus 100x50 pixels.
The result for the visual regression test is the same, but the size of the stored image is obviously smaller for the element shot.
Especially for big pages, this would make a big difference.

Regarding the resizing:
Lost Pixel doesn't resize shots. This would defeat the idea of having pixel-by-pixel comparisons.
I uses the defined browser window size to take the screenshot. You can define the size by setting the viewport.
At the moment we don't support multiple viewports for the same shot (e.g. to test various resolutions of your components) but will soon have it.
So, if you define a fixed size for your component, you should always get the same result. Otherwise, it will adapt to the size of the viewport that you define.

The threshold param works on the global and individual story level. For now, it's the only param that allows for flexibility of differences in shots.
We are still looking for ideas and use cases before we introduce more params (like ignoring colors and similar).
If you have ideas, feel free to list them here or create an issue. We don't see much value in building a feature that nobody's asking for. We are looking for people that have use cases and would test-drive such new features and give us feedback on how to improve them. 👍

@QuietMonkey
Copy link
Author

Oh yes, I see the difference between masking a whole area and taking screenshots of what we want only thanks! For what I'm trying to achieve the elements shots seems to be the most useful with better performance.

Thanks for the better understanding of how lost-pixel comparison works.

I totally have missed the possibility to define threshold for individual stories and will have to look into it, it will permit to have really trustworthy comparison tests for all components.

As for the refining ideas (like ignoring colors etc), it's just some features I saw in others visual regression testing frameworks and found the idea interesting, but I don't have a real need for it at the moment. I'll may open an issue in the future with precise use cases.

Thanks a lot for your time and all your explanations. I'm eager to see this new feature at work 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants