[Decapod] Image scaling and transformation of mixed content

Jonathan Hung jonathan.hung at utoronto.ca
Mon Mar 1 16:18:21 UTC 2010


My comments and questions inline.

On Mon, Mar 1, 2010 at 8:33 AM, Boyan Sheytanov <
boyan.sheytanov at asteasolutions.com> wrote:

> Hi all!
>
> My comments are inline below.
>
> On 26 February 2010 16:56, Thomas Breuel <tmbdev at gmail.com> wrote:
>
>> Hi,
>>
>> > Image 1: 1200x2000 (content area: 1100x1900)
>> > Image 2: 1300x1700 (content area: 1200x1600)
>>
>> I don't see how this can occur with our current use cases.  Neither
>> Book Liberator nor stereo generate these kinds of images.  It also
>> doesn't happen with flatbed scanners or common book scanners, if
>> people used those to generate the original scans.  And it doesn't
>> generally happen with the scanned books people can download from
>> Google or the Internet Archive.
>>
>
> I guess that the two images will always be the same size, but after
> cropping the resulting images might be different sizes (that will differ
> with several pixels in the general case). At least these are my impressions
> after doing automatic cropping with BookLiberator software on some sample
> images found on their site.
>

This case can happen if importing a directory from the local file system
where images can be taken from various sources.

I agree that out output should be uniform (like with IA and Google's books),
but to get a uniform output we need to figure out what to do in this case.



>
>
>>
>> > What if the user imports 100 pages. Page 1 is 800x600. Page 2 is
>> 1000x2000,
>> > 3 to 99 are 1200x2500, and the last one is 3000x5000.
>>
>> Dealing with mixed size originals is out of scope for the entire
>> project and it is far more complex than the simple image editing
>> operations we need for books (where all pages are the same size).
>>
>
> I agree with Thomas. If the user imports images with different sizes, it's
> his problem. We only need to clearly document this.
>

I agree as well that this is outside the scope of the project. However, if
it is feasible to have such functionality (i.e. Decapod being able to
support multiple aspect ratios and output a uniform book), then I think it's
something worth investigating as it would make the use case of importing
from a local disk much better.


This brings up some other questions:

1. What if a user captures with the camera, and then imports some images
from disk. This may result in different image sizes. In this case should we
disable importing from disk if capturing from cameras?

2. If a user imports from disk and images are different sizes, and we import
anyway and warn the user that some photos were stretched / scaled to fit.
What is the page dimensions we are scaling to?

Judging by this discussion, we should be restricting Decapod software to use
a pair of cameras of the same model or image resolution. We will need to
enforce this through the UI and document it.



>
>
>>
>> > Do we apply the dimension transformation to ALL images, or do
>> > transformations apply to just a pair/spread?
>>
>> Approach 3: return an error message.
>>
>
> We only do the dimension transformation because we want to stitch to
> equally sized images. There's no point in applying in to all images.
>

But if we want export results that is uniform across all pages, we'll need
to normalize page dimensions across the whole book. After auto-crop and
stitch, it's possible that dimensions are different from spread to spread?


>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20100301/a4920c86/attachment.html>


More information about the fluid-work mailing list