Does it has to be HIRES?
If you can afford to have a repeating pattern, you can do some fancy things, like the wobble effect in Barbitoric which is 100% TEXT mode.
Also using TEXT mode you can use double size characters, which half the requirements for the storage.

What I want to do right now is just scroll the top 64 lines of a HIRES screen, plain ol' demo style.. actually I've changed up the 'requirements' a bit too and really its just about applying any kind of effects of a 240x64 line of graphics, which serve as the header of a text-file that fills the rest of the screen .. I've been grok'ing and grep'ing around a bit of the code of the pro's, and its really interesting the plethora of techniques for doing things.

Are there attribute changes on that HIRES image? Because if so, as DBug alluded to in an earlier post, your image will have to respect some constraints to ensure there are no attribute clashes.

One such constraint is that if you want to scroll by one pixel, you must ensure that every 6 pixels wide window contains maximum two colors (including colors induced by attribute changes such as inversion). The reason is simply that the Oric cannot display more than two colors per byte (=6 pixels) so every scrolled version of the image between 0 and 5 pixels of scroll value must also satisfy this constraint.

Also, modifying attributes on the fly as a function of the scroll value is likely to be quite complex.
An effect I coded for the Barbitoric demo actually illustrates how complex attribute handling can be when trying to manipulate images pixel by pixel:

This effect does not scroll anything, it just copies new pixels column by column from an offscreen image and spreads them (via attribute changes) to the end of the line.
Even then, just computing the proper attributes for every possible combination of pixels requires a branching tree of about 60 lines of C (*).

I coded that at the SOTA party and still remember arguing with JeDe and DBug about whether this was actually possible or not and we were all not quite sure it was until I finally managed to code all possible combinations.

To get familiarized with the Oric graphic system I would recommend to start with images which do not contain attribute changes (two colors), then start tackling attribute changes with images artificially restrained to two pixels per byte, that is with always three consecutive pixels of the same color. This allows to worry about scrolling attributes only every three scroll units.

Then when you are at ease with that, go for complex images with the "two colors per six pixels wide window" constraint which require dynamic attribute changes possibly at any scroll unit.

I would imagine that scrolling an HIRES image with attributes would be similarly complex to the above mentioned effect and thus very slow since the operation would have to be done for every byte of the screen as compared to just a column of two bytes as was needed for the effect.

(*) I have examined these sources recently and realized that this code could be massively simplified by using tables.
Also note that the version in the video is an assembly version debugged and optimized by DBug. I tried to code an assembly version after the C version proved it could work but never managed to make it work .

I totally get it that scrolling attributes on the Oric is hard .. I've boned up on AIC and read every bit of assembly I can find on the subject, and yes - it is very complex, with a myriad of approaches out there .. Nevertheless, I'm still working out how to achieve the effect I want ..

So, there are two projects on my plate - one, a "Demo / Log Book" application for the Atmos that I will take to the next RetroSession I'm organising (https://metalab.at/wiki/RetroSessions) .. for this, I just want the top 1/4 of the screen to be in HIRES mode, with the rest TEXT mode .. the HIRES area will function as the 'banner' for the rest of the screen in TEXT mode, which purpose is to provide a schedule for the workshop, as well as a way for people to 'log their presence and activity' in the app, which will save the data for the next event, and thus the app will give us a running log of the RetroSessions, hosted on my Oric Atmos and available to other participants as a .DSK file for Oricutron, at their discretion. These images are all created with pictconv, so some of them use AIC mode and others do not. Either way, if you load the .DSK and run FLIP.COM, you can see where I'm at so far - the next step is to write some code, either in C or Assembly, that will load these HRS files elsewhere and then flip them into the display address, either to scroll, or some other effect - byte-fade, etc. I think doing a fade from one of these images to another would be an interesting effect, and I at least am exploring this with an open mind as to how crap it may, or may not, end up looking.

These graphics are just the first attempt - I will refine them a little over the next day or so, such that they all have the same physical geometry (at the moment there are offsets) so that I can wipe/fade between them, or - as discussed - scroll them onto the screen from left or right. Anyway for those interested, you can see that the banner is just there for a bit of flash trickery. I'll load a custom CHARSET for the text area of the log book, and write some fancy code for inputting name/handle, event log message, for each date in the Log. I'm working on that code now, ignoring the flashy effects until later...

The second project I want to use my new-found knowledge on, is a bit tricky .. basically, I want to have scrolling banners that serve as "selection fields" for parameters for the Oric sound engine - so there would be a long 'strip' image that contains all the envelope settings, described graphically, and when the user selects a different envelope - by way of example - the strip scrolls to the selected part of the image for the index of their setting. This way, I can build a synth with easily scrollable regions for selecting basic parameters. The idea is then, to adopt what I learn from the RetroSession logbook, and generalise it for all the parameters of the Oric synth section ..

So you can see, I'm curious about the techniques. Of course the easiest thing to do is scroll on 8-bit boundaries, and this would suffice for my needs - but in case someone had figured out how to do smooth pixel-level scrolling, while still maintaining AIC mode limits, it would have been interesting .. Anyway, after I get the boring Logbook functionality written, I'll have another look at the code for doing swipes/fades/scrolls of these sub-regions in HIRES, and maybe come up with a small set of functions, perhaps in C, that can be used elsewhere too ..

Based on your description, the easiest would be to scroll vertically, maybe something like barrel rolls, like the old style dispensing machine in gas stations: You can easily smooth scroll vertically at full speed, without much memory overhead, something that is hardly doable horizontally.

That would even work in AIC, just scroll by two scanlines at a time so you keep the odd/even offsets matching between the bitmap and the colormap.

Now, if you really want to do left/right scroll, the "I" part of AIC is going to be a problem: The color changes in AIC are all on the left column, so that's ok from a scroll point of view, except the INVERSE bit which always apply to a full column, these can't be scrolled: Either you have the entire scanline inverted or not at all. I don't see how that could be achieved differently.

Another possibility would be to have your logo zoom: You could precompute it in various sizes, loaded from disk, and display the right one, complete with the right set of attributes, and with a bit of tweaking you can use all the sizes at the same time to give a 3D effect like a flag moving from the back to the front of the screen.

Regarding transitions/fade, in all cases that will only work if you have full control/compatibility between the color changes of the source and target pictures.