# Can we get rid of Image Span? **URL:** \ **Category:** Coding synfig\ **Created:** [July 10, 2019, 12:09pm UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962 "2019-07-10T12:09:43Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![rodolforg](https://forums.synfig.org/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@rodolforg](https://forums.synfig.org/u/rodolforg)\ **Post date:** [July 10, 2019, 12:09pm UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/1 "2019-07-10T12:09:43Z")
First, I can’t find anywhere that uses this term “`image span`”, and I just can remember TV (screen) size that is measured by the diagonal of the image rectangle. However, even in this application, the diagonal value is measured in inches not in a peculiar ‘unit’ (1 ‘unit’ = 60 pixels). At least in USA, Brazil, France and Spain. Furthermore, Synfig uses “`image span`” basically for image resize constraints. I wonder who actually resizes a project trying to keep the diagonal size (the `image span`) instead of the keeping either image or display `aspect ratio`. By the code side, I ran `git grep get_span` and got: synfig-core/src/synfig/renddesc.cpp: float old\_span=get\_span(); synfig-core/src/synfig/renddesc.cpp: float old\_span=get\_span(); synfig-core/src/synfig/renddesc.cpp:RendDesc::get\_span()const synfig-core/src/synfig/renddesc.cpp: Vector::value\_type ratio=x/get\_span(); synfig-core/src/synfig/renddesc.h: Real get\_span()const; synfig-core/src/tool/joblistprocessor.cpp: job.desc.get\_pixel\_aspect(), job.desc.get\_image\_aspect(), job.desc.get\_span()); synfig-core/src/tool/joblistprocessor.cpp: % job.desc.get\_span() synfig-core/src/tool/printing\_functions.cpp: cout \<\< “span” \<\< “=” \<\< rend\_desc.get\_span() \<\< endl; synfig-studio/src/gui/renddesc.cpp: adjustment\_span-\>set\_value(rend\_desc\_.get\_span()); Therefore, we can see that, besides `synfig-core/src/synfig/renddesc.{h,cpp}`, `RendDesc::get_span()` is only used for printing `RendDesc` info. Similar analysis can be made for `set_span()` : synfig-core/src/synfig/renddesc.cpp: set\_span(old\_span); synfig-core/src/synfig/renddesc.cpp: set\_span(old\_span); synfig-core/src/synfig/renddesc.cpp:RendDesc::set\_span(const Real &x) synfig-core/src/synfig/renddesc.h: RendDesc& set\_span(const Real &x); synfig-core/src/tool/optionsprocessor.cpp: set\_span(), synfig-core/src/tool/optionsprocessor.cpp: add\_option(og\_set, “span”, ‘s’, set\_span, _(“Set the diagonal size of image window (Span)”), “NUM”); synfig-core/src/tool/optionsprocessor.cpp: if (set\_span \> 0) synfig-core/src/tool/optionsprocessor.cpp: span = set\_span; synfig-core/src/tool/optionsprocessor.cpp: desc.set\_span(span); synfig-core/src/tool/optionsprocessor.h: int set\_span; synfig-studio/src/gui/renddesc.cpp: rend\_desc_.set\_span(adjustment\_span-\>get\_value()); Can we get rid of Image Span (and the image span resizing-lock feature)? Maybe replace by “[display aspect ratio](https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Introduction)”? ---
**Author:** ![bazza](https://forums.synfig.org/user_avatar/forums.synfig.org/bazza/32/3852_2.png) [@bazza](https://forums.synfig.org/u/bazza)\ **Post date:** [July 10, 2019, 2:47pm UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/2 "2019-07-10T14:47:59Z")
Because it may not be important in rendering the television standard. Preferable raw image. You could work with ffmpeg rescaling video to pixel 1:1 -\> 2:1 It is the solution that I used even with proprietary software. ``` ffmpeg .... -vf "setsar=1:1" ... ffmpeg .... -vf "setsar=2:1" ... ``` [https://ffmpeg.org/ffmpeg-all.html#setdar\_002c-setsar](https://ffmpeg.org/ffmpeg-all.html#setdar_002c-setsar) ---
**Author:** ![rodolforg](https://forums.synfig.org/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@rodolforg](https://forums.synfig.org/u/rodolforg)\ **Post date:** [July 10, 2019, 11:16pm UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/3 "2019-07-10T23:16:36Z")
Sorry I didn’t understand. Are you ok to remove the `image span` locking? `Pixel aspect ratio` (and locking) would still exist. ---
**Author:** ![bazza](https://forums.synfig.org/user_avatar/forums.synfig.org/bazza/32/3852_2.png) [@bazza](https://forums.synfig.org/u/bazza)\ **Post date:** [July 11, 2019, 1:38am UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/4 "2019-07-11T01:38:38Z")
> [@rodolforg](#): > > Are you ok to remove the `image span` locking? No, I’m sorry only it commented. I exported in sequence of images and transcodificaba to pixel 2:1 of PAL-N ---
**Author:** ![rodolforg](https://forums.synfig.org/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@rodolforg](https://forums.synfig.org/u/rodolforg)\ **Post date:** [July 11, 2019, 2:34am UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/5 "2019-07-11T02:34:35Z")
So you like a `pixel size`. Wouldn’t it be better to set the pixel dimensions/pixel aspect ratio instead of setting how long is the pixel diagonal length? It could have any angle in this last case… ---
**Author:** ![BobSynfig](https://forums.synfig.org/user_avatar/forums.synfig.org/bobsynfig/32/175_2.png) [@BobSynfig](https://forums.synfig.org/u/BobSynfig)\ **Post date:** [July 11, 2019, 8:17am UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/6 "2019-07-11T08:17:01Z")
> [@rodolforg](#): > > Sorry I didn’t understand. > Are you ok to remove the `image span` locking? > > `Pixel aspect ratio` (and locking) would still exist. The topic of default options has been treated in this GitHub issue: [Lock ratio button unexpectedly crops the canvas · Issue #771 · synfig/synfig · GitHub](https://github.com/synfig/synfig/issues/771) Such modifications will always do happy and unhappy people. The best is to understand how Synfig works. I will not add anything as I expressed my point of vue in the GitHub issue already 😉 ---
**Author:** ![bazza](https://forums.synfig.org/user_avatar/forums.synfig.org/bazza/32/3852_2.png) [@bazza](https://forums.synfig.org/u/bazza)\ **Post date:** [July 11, 2019, 11:05pm UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/7 "2019-07-11T23:05:23Z")
More simple example: ``` synfig file.sif -t ppm -o - | ppmtoy4m | y4mscaler -I sar=1:1 -O sar=NTSC > NTSC.mpeg synfig file.sif -t ppm -o - | ppmtoy4m | y4mscaler -I sar=1:1 -O sar=PAL > PAL.mpeg ``` ---
**Author:** ![rodolforg](https://forums.synfig.org/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@rodolforg](https://forums.synfig.org/u/rodolforg)\ **Post date:** [July 12, 2019, 11:20pm UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/8 "2019-07-12T23:20:16Z")
Hey, BobSynfig. I already had seen that issue. AFAIK, your point of view is just let it the way it is, right? I think that, as can be seen, it is very confusing for most people - and [wiki even says](https://wiki.synfig.org/Canvas_Properties_Dialog): > Please note that since this dialog caused confusion, even among some very experienced people, here are some unofficial [thoughts](https://wiki.synfig.org/Image_Dimensions) about image dimensions. How about at least change/improve the terms? - **Image** → _ **Canvas** _ (or just keep **image** ) - **Image area** → _ **Viewport** _ / camera ? ¹ but we can help user by letting him translate and scale viewport besides setting viewport rectangle coordinates This way, I believe the [wiki page about image resizing](https://wiki.synfig.org/Canvas_Properties_Dialog#Resizing_the_Canvas) could be clearer: **Resizing the Canvas** - Current: unlock everything and just set image width & height. - Proposal: diddo **Resizing the Canvas and keep aspect** - Current: Lock “Image Aspect”, “Image Span”, “Pixel Aspect” and then set image width & height. - Proposal: Lock “image aspect ratio” and then set image width or height (they’re automatically linked). **Expanding the Canvas** - Current: Lock “Pixel Aspect” and then set image width & height. - Proposal: Lock “viewport aspect ratio” and then set viewport width or height (they’re automatically linked). Viewport data (top-left, bottom-right coordinates) would be set in pixel, not 1/60 pixels. ---
**Author:** ![BobSynfig](https://forums.synfig.org/user_avatar/forums.synfig.org/bobsynfig/32/175_2.png) [@BobSynfig](https://forums.synfig.org/u/BobSynfig)\ **Post date:** [July 13, 2019, 10:19am UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/9 "2019-07-13T10:19:25Z")
The problem is that Synfig is historicaly a vector software. Canvas, image, viewport are different notions. The image is the result if the canvas, but it can be rendered independantly, in any size. No matter the original canvas size. The origin of coordinate system is the centt of the canvas, should it be also transformed as cartesian system? ---
**Author:** ![rodolforg](https://forums.synfig.org/letter_avatar_proxy/v4/letter/r/c68b51/32.png) [@rodolforg](https://forums.synfig.org/u/rodolforg)\ **Post date:** [July 13, 2019, 7:20pm UTC](https://forums.synfig.org/t/can-we-get-rid-of-image-span/9962/10 "2019-07-13T19:20:57Z")
I know it’s a vector software 🙂 I’m used to Inkscape and Blender too. By your definition of `image`, `image span` (a term that I only can see in Synfig) makes no sense. It is the image diagonal length - and that should “equivalent” (actually, directly related/coupled) to `image aspect ratio`, since both refers to `image` word. By “equivalent” I mean: if an image is 480x300px, its image span should be sqrt(480² + 300²), or, in strange `unit` thing, sqrt(8² + 5²). If I resize `image`, the image span changes too - mandatory. But no, we can choose (thank you, Synfig 🙂 ). The viewport definition I was using is the same for 3D CG and webbrowsers, as described in last paragraphs in [Wikipedia article](https://en.wikipedia.org/wiki/Viewport). Regarding your definition of canvas, it has infinity size in Synfig and Inkscape. User can draw anywhere he wants, including outside of that chess-pattern rectangle in Synfig (and outside page in Inkscape). This off-“main region” stuff wouldn’t be rendered/rasterized, though, because it will be clipped by a “camera” (that I wrongly called ‘viewport’ ¹, Synfig uses `image area`) and will be projected in `image`. ¹ it should be ‘world window’ I, and many users, think these terms are really confusing: `image` and `image area` don’t use “image” in the same concept/definition. This [presentation](http://www.tecgraf.puc-rio.br/ftp_pub/lfm/L1J_WindowViewport.pdf) explains well these terms (look slides #3 and #5). Regarding your question about coordinate system, nothing would change. Why would it?