Well maybe I don’t understand then. For Scrivener to do the same it would become an HTML editor.
You say that…
And when we compile to epub, i.e. use Scrivener as “an ePub creation program”, as you phrase it, why can’t Scrivener behave like one and when it “allows - - visual resizing - -, is going to be doing so with a simple floating point calculation on pixel dimensions directly” and hence use “the same technology that the reader or browser will be using”?
This must be where I don’t understand.Isn’t Scrivener in a sense an HTML editor when it compiles an epub?
Hey I’m done. I’ll let you guys carry on. We are obviously not going to convince each other. You think that it is OK for the GUI to say 346 x 259 points and produce compiled code that says 346 x 259 pixels. I think that is wrong. You think that other compilers are wrong for coding 346 x 259 points to an HTML statement that says 346 x 259 points. Please excuse me while I step out of this debate, You have surrounded this discussion in the deepest detailed science around CSS, Typesetting, DPI etc. If you cannot acknowledge that the GUI is not doing what it displays, then I cannot spend anymore time on this. Never before have I felt so unable to form an agreement with someone on such a basic point. I have my work around, the GUI can be ignored. I regret that so many people have spend so much time on the detailed analysis of this subject and not been able to agree that Scrivener does not produce code that honors what the GUI says. I will post no further comment on this subject. You guys carry on the madness if you wish
I don’t think it’s madness. My guess there is some fundamental core principle that is so obvious to each one of us that we don’t realise that it exists, or that others don’t see it the same way.
My core principles:
For printing on paper, images must have a physical size.
For displaing in an epub reader, images need a relative size, relative to the size of the reader.
When writing in Scrivener I should be able to size images the way I want, without it having an effect on how they appear when I compile, because in Scrivener writing and compiling are two separate things and the way it looks in one doesn’t affect the other.
To me it seems that AmberV for some reason doesn’t see it this way.
So where do I fail to understand?
Like I said, you can discuss endlessly the science of this. The compiled code does not honor the setting in the GUI, this whole lengthy and painful conversation seems like smoke and mirrors. If I use any other EPub creator and specify that an image is X pixels I get X pixels, if I specify 100% I get 100%, if I specify X Ems I get X Ems. In Scrivener if the slider says X points I get X pixels. That is just wrong.
That would be a pretty loose interpretation. It is an RTF editor that calls upon a system library to convert RTF → HTML, or upon MultiMarkdown to generate HTML5 for ePub 3 / KF8. But that’s almost beside the point, what really matters is that in RTF an image is stored, displayed and has its size changed purely through manipulation of the image’s print settings, settings that are invisible (discarded, as I perhaps confusingly put it before) to actual HTML editors and viewers (from the very start to the very end). When you change the size of an image in Scrivener, it does not use pixels to do so, it strictly adjusts the print width/height setting.
When you compile, it uses these print settings to derive the number of pixels the image should be displayed at. It does this by calculating off of the visual size provided by the user’s adjustment of the image’s print settings. Go back a bit and look at my screenshot of how the result in iBooks is identical to the original image in the editor—that’s it working the way it should be, and if Calibre had a slider and you used it to make the image that small in its editor, you would get the same result in pixels I’m sure.
So in a roundabout way, it does do what you are saying: the image is ultimately adjusted via pixels and its final size is expressed in the correct number of pixels it takes to display the image at the requested size (which might not be the expected size thanks to differences in screen display technology—but that’s why we should not use print settings for ePublishing in the first place, and why all of this is, as I referred to earlier, mitigation).
Well that on that point I would agree! 
Unfortunately that’s not how it works however. In fact I wrote a post-processing script that strips all of Scrivener’s resizing information out of the MultiMarkdown file because I don’t care one bit how big the image is in the editor. I only change that to make it convenient for how I work.
But—that’s not how it is programmed to work and that is I don’t think how most people would expect it to work. I am positive most people think that the image they see in the editor is representative of how it will print or be displayed on the screen, and so in every method that Scrivener produces images into the output—even to formats like LaTeX—it strives to replicate the editor settings.
I think this is the crux of the matter, because this means that if one alternate between different platforms and screen sizes (I run Scrivener on a 27" iMac, a 12" Macbook, a big iPad Pro and an iPhone 8) and resize one image on one device, another image on another device, and so on, the output will be completely screwed up because Scrivener strives “to replicate the editor settings”.
I think the initial assumption, that “most people think that the image they see in the editor is representative of how it will print or be displayed on the screen”, is both correct and incorrect. Most newbies think that is the way the editor should work for text because they are used to wysiwyg editors like Word, so for newbies the assumption is correct. But sooner or later they understand that the text in the editor is one thing and the compiled output something else, and by then they have understood that Scrivener is NOT a wysiwyg editor and hence the compiled output does NOT reflect how things look in the editor (unless you explicitly tell the compiler to compile ‘as-is’). At that point the initial assumption becomes totally illogical and incorrect, and creates confusion.
I think KB should really think a bit about this. Scrivener can’t be a wysiwyg editor for images when it isn’t for the text.
Well, I think at this point you’re talking about something entirely different than the OP though. They don’t agree with how Scrivener measures images, but they obviously rather strongly want those numbers used for something rather than ignored entirely!
But yes, for ePublishing specifically, the problems you point out with using fixed units of measurement like points and inches is that these things are visually different depending on the device. That is why a general statement of “75% of the virtual page” is usually going to be a better approach. Go for it—you have the tools available to do that.
Something like you’re talking about is probably better put as a new feature request—I’d suggest a checkbox because ignoring image size definitely shouldn’t be default behaviour!
Maybe the whole thread can be summarized as: Using images is tricky because there is no general simple solution that fits all alternative outputs.
I’m been following the discussion without really following it (if you know what I mean) as I haven’t used Scriv to embed images yet, however that’s not entirely tracking with my understanding of the OP’s complaint. They’re complaining about the unit labelling of the numbers (e.g. it says they’re points when they’re not) – and surely, if that’s the case, that’s a valid complaint?
I mean, I get that it’s complex and there are multiple ways to do things, but if there is behavior that is objectively wrong, that should still qualify as a bug, yes? Even if in this case it is wrong because Scrivener is assuming 72DPI which is the magic point where pixels = points…isn’t the fix simply to change the label?
…but, but, but, but the points are accurate/carried through in other compiles. If the unit labelling was changed to pixels, wouldn’t it then be “wrong” in those other compiles?
This is interesting…
It would all perhaps be less confusing if CSS used a different word for its unit of measurement here, like ponies, instead of pixels (which aren’t the same as pixels in a raster). If we compiled and got an image 246 ponies wide, some people might giggle, but I think we’d all better understand it is a conversion to a different display system meant to produce a visually similar result from the source. 
As noted in this thread over here, there is a good point in that Scrivener may be using the wrong (PostScript vs CSS) conversion formula for converting print sizes to HTML sizes, but even with that tweak made to the software, the confusion above would still exist. After all the UI will now state the image is 1080 pixels wide, 249 points wide and then export the graphic to 346px in the CSS. Is that more or less confusing than 249px?
Yeah, I like ponies better I think.
You know what a pony (and trap) is in Cockney slang? 
So why not say “CSS pixels” – which seems to be the most accurate term for now and is specific enough that “pixels vs. CSS pixels” could be a FAQ entry – and make it clear that the DPI stuff is distraction? Using “points” when that is not accurate to all compile targets (and if I understand correctly, this setting is there long before Scrivener knows which compile target is going to be used) is misleading.
Sometimes I think I have finally understood it all, and then someone enters a new post just to make it absolutely clear that My understanding was an illusion…
PS. Pony in cockney… now THAT really aroused my curiosity 
Where would it say “CSS pixels”, as a read-only label below the image scale info? That’s a possibility I suppose, and perhaps more interesting with 96ppi math than it would be currently. But why the continued assertion that points are inaccurate? They are accurate, important, and DPI is not a distraction if you are compiling to a word processing or print-based workflow.
Wherever it comes to Cockney slang, I’m afraid to search the the Internet!
(I am sure I do not fully grasp all the ins-and-outs here. But that never stopped me from jumping in before!)
If rendering intent is naturally (or necessarily) specified differently depending on compile destination, perhaps settings for how images should be rendered should be a part of compile formats.
To keep things simple on the surface, these settings would have to by default be tied to the visual display of images in Scriv – to “preserve visual intent” as Scriv means to do now. But the settings would now enable one to uncouple those two things and tweak rendering intent separately. The info in the Edit Image panel would then be reduced to simply expressing adjustments to the in-house display of the image.
(Doing things this way would only make sense if it makes good sense to make rendering intent settings per project instead of per image.)
Alternatively, if there are not too many different categories of output that potentially want to be separately treated, one could expand the Edit Image dialogue box accordingly – with separate sliders for different output categories: for pinrt & pdf, for ebook, for docs – and expressing these in the relevant unit of scale.
-gr
P.S. Is it just me or is Scrivener’s dream of separating writing from typesetting getting harder and harder to maintain.
A pony by itself is £25. But a pony and trap (you only need to get to the third letter of the alphabet to know what it rhymes with), often shortened in appropriate contexts to just pony, is…well…um…well, it gives a whole new meaning to My Little Pony.
After that light relief, back to the topic…
I opened up a sample image and read back through this thread a couple of times to make sure I was grokking what was going on, so apologies if I do not communicate my confusion clearly.
The problem as I see it at this point is that the Edit Image/Scale Image dialogue is confusing. I loaded a 1000x1000 image of my smiling mug into my document. Apparently, I do not have any DPI metadata in it, as when I open the Scale Image dialog I see it reporting 1000 x 1000 pixels (96 DPI), and it is currently set to scale at 750x750 points.
Okay, open up the calculator and do the math: 1000 / 96 * 72 = 750. So that explains where 750 x 750 points is coming from.
So now I move the sliders so that it’s 375 x 375 points. It now says 1000 x 1000 pixels (192) DPI, which makes sense – half the physical size = twice the physical density. If I compile this to RTF or DOCX my image will still be there as a 1000 x 1000 pixel image but set to scale as 375 x 375 points (or 5.21 inches which is the corresponding size), correct?
What I am seeing in Word 2016 for DOCX and RTF is that the image in the file is now physically a 781 x 781 pixel image. 5.21" x 5.21" is the 100% size for this picture, now. Okay, not what I was expecting – it’s the intended target size, but the image has been downsampled, so I have to fix the scaling in Scrivener and recompile if I change my mind on the size.
Okay, so on to ePub3 (had to download Sigil and learn how to use it).
What I am expecting is that the file will be inserted as a 1000 x 1000 pixel image but set to scale as 375 points, or 500 pixels. Why 500 pixels? I don’t expect DPI to matter because this is HTML/CSS, but I do expect that since I scaled the image down 50% from its starting point, Scrivener will pass that same scaling ratio through as it did with DOCX and RTF formats.
What I get is a 1000 x 1000 pixel image (yeah!) with height: 375px; width: 375px; which gives me an image that doesn’t match to any size relationship I can figure out. 375 / 72 * 96 = 500 px ; 375 / 72 * 192 = 1000 px. I’ve used the slider to scale this image to 50% of its physical size, but what I end up with in my ePub CSS is 37.5% of the size.
At least the full image is there so I can fix the height and width and use percentage…
Since Scrivener is ignoring the DPI information, shouldn’t it be doing the math conversion so that the same amount of scaling is happening regardless of my compile format?